« Classe abstraite » versus « classe normale » pour une bibliothèque réutilisable

Question

Je développe une bibliothèque réutilisable et ont créé des classes abstraites, de sorte que le client peut alors prolonger de ces.

QUESTION: Y at-il raison en fait, je devrais utiliser une classe abstraite ici par opposition à juste une classe normale

Note -. Ont déjà décidé que je ne veux pas utiliser les interfaces que je veux inclure les méthodes par défaut réelles dans ma bibliothèque afin que le client en utilisant ne pas écrire le code

EDIT: Je suis pour la pêche des avantages que je ne peux pas penser. Par exemple, lorsque la mise à niveau de la bibliothèque utiliserait d'une classe abstraite réduire l'impact sur le code client - je ne vois pas qu'il serait dans ce cas non?

Answer 1

Sauf si vous voulez forcer les utilisateurs finaux d'hériter de vos classes, il devrait y avoir aucune raison d'utiliser abstrait .

Si vous voulez faire vos classes et héritable facilement extensible, utilisez virtuel sur vos méthodes et assurez-vous que vous avez utilisable protégé constructeurs.

Answer 2

La motivation de la classe abstraite est d'exiger que les clients de passer outre la classe. Votre décision de savoir si la classe doit être abstraite ou non dépend surtout si l'abstrait manque un comportement fondamental que seul un utilisateur de la classe peut fournir.

Vous pouvez généralement vous dire besoin de votre classe pour être abstraite si vous utilisez une méthode de modèle de quelque sorte, où « bouchon dans le trou dans ce comportement » vient compléter la logique de classe il. Si votre classe est utile sans une certaine logique fournie par l'utilisateur, vous ne avez probablement pas besoin de la classe pour être abstraite.

À titre d'exemple, les cadres ne peuvent généralement pas prendre des décisions au nom de leurs utilisateurs en termes de choses comme la validation d'état de l'objet, l'impression, l'affichage, etc., et ils devront reporter aux mises en œuvre concrètes par les clients.

Answer 3

On dirait que vous êtes un peu confus au sujet de la différence entre une méthode virtuelle et une classe abstraite. Vous n'avez pas besoin de marquer votre classe comme abstraite, sauf si vous déterminez qu'il n'a pas de sens sur son propre. Ceci est utile dans les zones où vous pourriez avoir des comportements partagés entre plusieurs classes.

Me semble que vous avez juste besoin d'une classe régulière et certaines méthodes qui sont virtuelles.

Answer 4

La différence entre une classe abstraite et une non-abstraite est que vous ne pouvez pas instancier l'ancien et il doit être surchargée. Il est vraiment à vous de déterminer si oui ou non une instance de la classe de base est logique en soi.

Permettez-moi de vous montrer deux cas. L'un est où classe abstraite est logique et celui où il ne fonctionne pas.

public abstract class Animal {
  public string Name {get;set;}
}

public class Dog : Animal {
  public Bark(){}
}

public class Cat : Animal {
  public Meaow(){}
}

Dans ce scénario, nous avons une Animal de base commune qui fournit la mise en œuvre de la propriété de Name. Il ne fait aucun sens instancier animal lui-même car il n'y a pas d'animaux dans le monde qui sont juste des animaux, ce sont des chiens ou des chats Wither ou autre chose.

Voici un cas où il est logique d'avoir une base non abstraite.

class Path {
  public Path(IList<Point> points) {
    this.Points = new ReadOnlyCollection<Point>(points);
  }
  public ReadOnlyCollection<Point> Points {get;}
}

class RectanglePath : Path{
  public SquarePath (Point origin, int height, int width) : 
   base(new List<Point>{origin, new Point(origin.X + width, point.Y}, ....){

  }
}

Chemin qui n'est pas logique sous-classé, nous pouvons créer une forme arbitraire, mais il peut être plus pratique d'utiliser un sublass pour des formes plus spécifiques.