Interface vs classe de base

Quand dois-je utiliser une interface et quand dois-je utiliser une classe de base?

Devrait-il toujours s’agir d’une interface si je ne souhaite pas définir une implémentation de base des méthodes?

Si j’ai un cours de chien et de chat. Pourquoi voudrais-je implémenter IPet au lieu de PetBase? Je peux comprendre avoir des interfaces pour ISheds ou IBarks (IMakesNoise?), Car celles-ci peuvent être placées sur un familier, mais je ne comprends pas lesquelles utiliser pour un Pet générique.

Prenons votre exemple d’une classe Dog et Cat, et illustrons l’utilisation de C #:

Tant le chien que le chat sont des animaux, en particulier des mammifères quadrupèdes (les animaux sont trop généraux). Supposons que vous avez une classe abstraite Mammifère, pour les deux:

public abstract class Mammal 

Cette classe de base aura probablement des méthodes par défaut telles que:

  • Alimentation
  • Camarade

Ce sont tous des comportements qui ont plus ou moins la même implémentation entre les deux espèces. Pour définir cela, vous aurez:

 public class Dog : Mammal public class Cat : Mammal 

Maintenant, supposons qu’il y a d’autres mammifères, que nous verrons habituellement dans un zoo:

 public class Giraffe : Mammal public class Rhinoceros : Mammal public class Hippopotamus : Mammal 

Ce sera toujours valable car au cœur de la fonctionnalité Feed() et Mate() seront toujours les mêmes.

Cependant, les girafes, les rhinocéros et les hippopotames ne sont pas exactement des animaux sur lesquels vous pouvez faire des animaux de compagnie. C’est là qu’une interface sera utile:

 public interface IPettable { IList Tricks{get; set;} void Bathe(); void Train(Trick t); } 

La mise en œuvre du contrat ci-dessus ne sera pas la même entre un chat et un chien; mettre leurs implémentations dans une classe abstraite pour en hériter sera une mauvaise idée.

Vos définitions de chien et de chat devraient maintenant ressembler à ceci:

 public class Dog : Mammal, IPettable public class Cat : Mammal, IPettable 

Théoriquement, vous pouvez les remplacer par une classe de base supérieure, mais essentiellement une interface vous permet d’append uniquement les choses dont vous avez besoin dans une classe sans avoir besoin d’inheritance.

Par conséquent, comme vous ne pouvez généralement hériter que d’une seule classe abstraite (dans la plupart des langages OO statiquement typés, à savoir … les exceptions incluent C ++), mais que vous pouvez implémenter plusieurs interfaces, vous pouvez construire des objects ssortingctement selon les besoins .

Eh bien, Josh Bloch s’est dit dans Effective Java 2d :

Préférez les interfaces sur les classes abstraites

Quelques points principaux:

  • Les classes existantes peuvent être facilement adaptées pour implémenter une nouvelle interface . Tout ce que vous avez à faire est d’append les méthodes requirejses si elles n’existent pas encore et d’append une clause implements à la déclaration de classe.

  • Les interfaces sont idéales pour définir des mixins . En gros, un mixin est un type qu’une classe peut implémenter en plus de son «type primaire» pour déclarer qu’il fournit un comportement facultatif. Par exemple, Comparable est une interface de mixin qui permet à une classe de déclarer que ses instances sont ordonnées par rapport à d’autres objects mutuellement comparables.

  • Les interfaces permettent la construction de frameworks de type non hiérarchique . Les hiérarchies de types sont idéales pour organiser certaines choses, mais d’autres ne tombent pas parfaitement dans une hiérarchie rigide.

  • Les interfaces permettent d’améliorer de manière sûre et puissante les fonctionnalités via l’idiome de classe wrap-per. Si vous utilisez des classes abstraites pour définir des types, vous laissez le programmeur qui souhaite append des fonctionnalités sans autre alternative que d’utiliser l’inheritance.

De plus, vous pouvez combiner les vertus des interfaces et des classes abstraites en fournissant une classe d’implémentation squelettique abstraite pour chaque interface non sortingviale que vous exportez.

En revanche, les interfaces sont très difficiles à évoluer. Si vous ajoutez une méthode à une interface, cela brisera toutes ses implémentations.

PS: Achetez le livre. C’est beaucoup plus détaillé.

Le style moderne consiste à définir IPet et PetBase.

L’avantage de l’interface est que l’autre code peut l’utiliser sans aucun lien avec un autre code exécutable. Complètement “propre” Les interfaces peuvent également être mélangées.

Mais les classes de base sont utiles pour les implémentations simples et les utilitaires courants. Fournissez donc une classe de base abstraite pour gagner du temps et du code.

Les interfaces et les classes de base représentent deux formes de relations différentes.

L’inheritance (classes de base) représente une relation “is-a”. Par exemple, un chien ou un chat “est-un” animal de compagnie. Cette relation représente toujours le but (unique) de la classe (en liaison avec le “principe de responsabilité unique” ).

Les interfaces , par contre, représentent des fonctionnalités supplémentaires d’une classe. Je l’appellerais une relation “est”, comme dans ” Foo est jetable”, d’où l’interface IDisposable en C #.

Interfaces

  • Définit le contrat entre 2 modules. Impossible d’implémenter
  • La plupart des langues vous permettent de mettre en œuvre plusieurs interfaces
  • La modification d’une interface est un changement radical. Toutes les implémentations doivent être recompilées / modifiées.
  • Tous les membres sont publics. Les implémentations doivent implémenter tous les membres.
  • Les interfaces facilitent le découplage. Vous pouvez utiliser des structures simulées pour simuler n’importe quoi derrière une interface
  • Les interfaces indiquent normalement un type de comportement
  • Les implémentations d’interface sont découplées / isolées les unes des autres

Classes de base

  • Vous permet d’append une implémentation par défaut que vous obtenez gratuitement par dérivation
  • Sauf C ++, vous ne pouvez dériver que d’une classe. Même si cela peut provenir de plusieurs classes, c’est généralement une mauvaise idée.
  • Changer la classe de base est relativement facile. Les dérivés n’ont pas besoin de faire quelque chose de spécial
  • Les classes de base peuvent déclarer des fonctions protégées et publiques accessibles via des dérivations
  • Les classes de base abstraites ne peuvent pas être facilement moquées comme les interfaces
  • Les classes de base indiquent normalement la hiérarchie de types (IS A)
  • Les dérivations de classes peuvent dépendre de certains comportements de base (avoir des connaissances complexes sur l’implémentation parente). Les choses peuvent être compliquées si vous modifiez l’implémentation de base pour un gars et brisez les autres.

En général, vous devez privilégier les interfaces sur les classes abstraites. Une des raisons d’utiliser une classe abstraite est si vous avez une implémentation commune entre des classes concrètes. Bien sûr, vous devez toujours déclarer une interface (IPet) et avoir une classe abstraite (PetBase) pour implémenter cette interface. En utilisant de petites interfaces distinctes, vous pouvez utiliser des multiples pour améliorer encore la flexibilité. Les interfaces permettent une flexibilité et une portabilité maximales des types à travers les frontières. Lors du passage de références à travers les frontières, passez toujours l’interface et non le type concret. Cela permet à la réception de déterminer la mise en œuvre concrète et offre une flexibilité maximale. Cela est absolument vrai lors de la programmation en mode TDD / BDD.

Le Gang of Four a déclaré dans son livre “Parce que l’inheritance expose une sous-classe aux détails de l’implémentation de son parent, on dit souvent que” l’inheritance rompt l’encapsulation “. Je crois que c’est vrai.

Ceci est plutôt spécifique à .NET, mais le livre Framework Design Guidelines soutient que dans les classes en général, cela donne plus de flexibilité dans un cadre évolutif. Une fois qu’une interface est livrée, vous n’avez pas la possibilité de la modifier sans casser le code qui a utilisé cette interface. Avec une classe cependant, vous pouvez le modifier et ne pas casser le code qui y est lié. Tant que vous apportez les modifications appropriées, notamment en ajoutant de nouvelles fonctionnalités, vous pourrez étendre et faire évoluer votre code.

Krzysztof Cwalina dit à la page 81:

Au cours des trois versions du .NET Framework, j’ai parlé de cette directive avec plusieurs développeurs de notre équipe. Beaucoup d’entre eux, y compris ceux qui n’étaient pas d’accord avec les directives, ont dit regretter d’avoir livré une API en tant qu’interface. Je n’ai jamais entendu parler d’un seul cas où quelqu’un a regretté d’avoir expédié un cours.

Cela étant dit, il existe certainement une place pour les interfaces. En règle générale, fournissez toujours une implémentation de classe de base abstraite d’une interface pour rien d’autre comme exemple d’implémentation de l’interface. Dans le meilleur des cas, cette classe de base économisera beaucoup de travail.

Juan,

J’aime penser aux interfaces comme moyen de caractériser une classe. Une classe de race de chien particulière, par exemple un YorkshireTerrier, peut être une descendance de la classe de chien parente, mais elle implémente également IFurry, IStubby et IYippieDog. Donc, la classe définit ce qu’est la classe mais l’interface nous dit des choses à ce sujet.

L’avantage est que cela me permet, par exemple, de rassembler tous les IYippieDog et de les lancer dans ma collection Océan. Alors maintenant, je peux atteindre un ensemble d’objects et trouver ceux qui répondent aux critères que je regarde sans inspecter la classe de trop près.

Je trouve que les interfaces devraient vraiment définir un sous-ensemble du comportement public d’une classe. S’il définit tout le comportement public de toutes les classes implémentant, il n’est généralement pas nécessaire qu’il existe. Ils ne me disent rien d’utile.

Cette idée va à l’encontre de l’idée que chaque classe doit avoir une interface et que vous devez coder vers l’interface. C’est bien, mais vous vous retrouvez avec beaucoup d’interfaces un à un avec les classes et cela rend les choses confuses. Je comprends que l’idée est que cela ne coûte pas grand chose à faire et maintenant vous pouvez échanger des choses avec facilité. Cependant, je trouve que je le fais rarement. La plupart du temps, je ne fais que modifier la classe existante et j’ai exactement les mêmes problèmes que si l’interface publique de cette classe devait changer, sauf que je devais maintenant la modifier à deux endroits.

Donc, si vous pensez comme moi, vous diriez certainement que Cat et Dog sont IPables. C’est une caractérisation qui les correspond tous les deux.

L’autre partie de cela est si ils devraient avoir la même classe de base? La question est de savoir si elles doivent être traitées de la même manière. Certes, ils sont tous deux des animaux, mais cela correspond-il à la façon dont nous allons les utiliser ensemble.

Disons que je veux rassembler toutes les classes d’animaux et les mettre dans mon conteneur Ark.

Ou doivent-ils être des mammifères? Peut-être avons-nous besoin d’une sorte de fabrique de traite d’animaux croisés?

Ont-ils même besoin d’être reliés entre eux? Est-ce suffisant de savoir qu’ils sont tous deux IPables?

Je ressens souvent le désir de dériver toute une hiérarchie de classe lorsque je n’ai besoin que d’une classe. Je le fais par anticipation un jour, j’en aurais besoin et d’habitude je ne le fais jamais. Même quand je le fais, je trouve généralement que je dois faire beaucoup pour le réparer. C’est parce que le premier cours que je crée n’est pas le chien, je ne suis pas aussi chanceux, c’est plutôt l’ornithorynque. Maintenant, toute ma hiérarchie de classe est basée sur le cas étrange et j’ai beaucoup de code gaspillé.

Vous pouvez également trouver à un moment donné que tous les chats ne sont pas IPables (comme celui sans poils). Maintenant, vous pouvez déplacer cette interface vers toutes les classes dérivées qui correspondent. Vous constaterez qu’un changement beaucoup moins important que tout à coup les chats ne sont plus dérivés de PettableBase.

Voici la définition simple et fondamentale de l’interface et de la classe de base:

  • Classe de base = inheritance d’object.
  • Interface = inheritance fonctionnel.

à votre santé

Je recommande d’utiliser la composition plutôt que l’inheritance chaque fois que possible. Utilisez des interfaces mais utilisez des objects membres pour l’implémentation de base. De cette façon, vous pouvez définir une fabrique qui construit vos objects pour qu’ils se comportent d’une certaine manière. Si vous souhaitez modifier le comportement, vous créez une nouvelle méthode d’usine (ou fabrique abstraite) qui crée différents types de sous-objects.

Dans certains cas, vous pouvez constater que vos objects principaux ne nécessitent aucune interface si tout le comportement mutable est défini dans des objects auxiliaires.

Donc, au lieu d’IPet ou de PetBase, vous pourriez vous retrouver avec un animal qui a un paramètre IFurBehavior. Le paramètre IFurBehavior est défini par la méthode CreateDog () de PetFactory. C’est ce paramètre qui est appelé pour la méthode shed ().

Si vous faites cela, vous constaterez que votre code est beaucoup plus flexible et que la plupart de vos objects simples traitent des comportements à l’échelle du système.

Je recommande ce modèle même dans les langues à inheritance multiple.

Bien expliqué dans cet article de Java World

Personnellement, j’ai tendance à utiliser des interfaces pour définir des interfaces – c’est-à-dire des parties de la conception du système qui spécifient comment accéder à quelque chose.

Il n’est pas rare d’avoir une classe implémentant une ou plusieurs interfaces.

Les classes abstraites que j’utilise comme base pour autre chose.

Ce qui suit est un extrait de l’article mentionné ci-dessus, l’article JavaWorld.com, auteur Tony Sintes, 20/04/01.


Interface vs classe abstraite

Choisir des interfaces et des classes abstraites n’est pas une proposition. Si vous devez modifier votre conception, faites-en une interface. Cependant, vous pouvez avoir des classes abstraites qui fournissent un comportement par défaut. Les classes abstraites sont d’excellents candidats dans les frameworks d’application.

Les classes abstraites vous permettent de définir certains comportements; ils forcent vos sous-classes à en fournir d’autres. Par exemple, si vous avez une infrastructure d’application, une classe abstraite peut fournir des services par défaut tels que la gestion des événements et des messages. Ces services permettent à votre application de se connecter à votre environnement d’application. Cependant, il existe certaines fonctionnalités spécifiques à l’application que seule votre application peut exécuter. Une telle fonctionnalité peut inclure des tâches de démarrage et d’arrêt, qui dépendent souvent de l’application. Ainsi, au lieu d’essayer de définir ce comportement lui-même, la classe de base abstraite peut déclarer des méthodes d’arrêt et de démarrage abstraites. La classe de base sait qu’elle a besoin de ces méthodes, mais une classe abstraite permet à votre classe d’admettre qu’elle ne sait pas comment effectuer ces actions. il sait seulement qu’il doit initier les actions. Au moment de démarrer, la classe abstraite peut appeler la méthode de démarrage. Lorsque la classe de base appelle cette méthode, Java appelle la méthode définie par la classe enfant.

De nombreux développeurs oublient qu’une classe qui définit une méthode abstraite peut également appeler cette méthode. Les classes abstraites sont un excellent moyen de créer des hiérarchies d’inheritance planifiées. Ils sont également un bon choix pour les classes non-feuilles dans les hiérarchies de classes.

Classe vs. interface

Certains disent que vous devriez définir toutes les classes en termes d’interfaces, mais je pense que la recommandation semble un peu extrême. J’utilise des interfaces lorsque je constate que quelque chose dans ma conception changera fréquemment.

Par exemple, le modèle de stratégie vous permet d’échanger de nouveaux algorithmes et processus dans votre programme sans modifier les objects qui les utilisent. Un lecteur multimédia peut savoir comment lire des CD, des fichiers MP3 et des fichiers wav. Bien sûr, vous ne voulez pas coder en dur ces algorithmes de lecture dans le lecteur; cela rendra difficile l’ajout d’un nouveau format comme AVI. De plus, votre code sera encombré de déclarations de cas inutiles. Et pour append l’insulte à la blessure, vous devrez mettre à jour ces déclarations de cas chaque fois que vous ajoutez un nouvel algorithme. Dans l’ensemble, ce n’est pas une façon très orientée object de programmer.

Avec le modèle de stratégie, vous pouvez simplement encapsuler l’algorithme derrière un object. Si vous faites cela, vous pouvez fournir de nouveaux plug-ins de médias à tout moment. Appelons la classe de plug-in MediaStrategy. Cet object aurait une méthode: playStream (Stream s). Donc, pour append un nouvel algorithme, nous étendons simplement notre classe d’algorithme. Maintenant, lorsque le programme rencontre le nouveau type de média, il délègue simplement la diffusion du stream à notre stratégie média. Bien sûr, vous aurez besoin d’une plomberie pour instancier correctement les stratégies d’algorithme dont vous aurez besoin.

C’est un excellent endroit pour utiliser une interface. Nous avons utilisé le modèle de stratégie, qui indique clairement une place dans la conception qui changera. Vous devez donc définir la stratégie comme une interface. Vous devez généralement privilégier les interfaces sur l’inheritance lorsque vous souhaitez qu’un object ait un certain type; dans ce cas, MediaStrategy. Compter sur l’inheritance pour l’identité de type est dangereux; il vous enferme dans une hiérarchie d’inheritance particulière. Java n’autorise pas l’inheritance multiple, vous ne pouvez donc pas étendre quelque chose qui vous apporte une implémentation utile ou plus d’identité de type.

Gardez également à l’esprit de ne pas vous laisser emporter par OO ( voir blog ) et de toujours modéliser les objects en fonction du comportement requirejs, si vous concevez une application dont le seul comportement requirejs était un nom générique et une espèce. une classe animale avec une propriété pour le nom, au lieu de millions de classes pour chaque animal possible dans le monde.

J’ai une règle approximative

Fonctionnalité: susceptible d’être différente dans toutes les parties: Interface.

Les données et les fonctionnalités, les parties seront essentiellement les mêmes, des parties différentes: la classe abstraite.

Données et fonctionnalités fonctionnant réellement, si elles ne sont étendues qu’avec de légères modifications: classe ordinaire (concrète)

Données et fonctionnalité, aucun changement prévu: classe ordinaire (concrète) avec modificateur final.

Données, et peut-être fonctionnalité: lecture seule: membres enum.

Ceci est très brut et prêt et pas du tout ssortingctement défini, mais il y a un spectre d’interfaces où tout est destiné à être changé en enums où tout est corrigé un peu comme un fichier en lecture seule.

Les interfaces doivent être petites. Vraiment petit. Si vous décomposez réellement vos objects, vos interfaces ne contiendront probablement que quelques méthodes et propriétés très spécifiques.

Les classes abstraites sont des raccourcis. Y at-il des choses que tous les dérivés de PetBase partagent que vous pouvez coder une fois et être fait avec? Si oui, alors il est temps pour un cours abstrait.

Les classes abstraites sont également limitantes. Bien qu’ils vous offrent un raccourci pour produire des objects enfants, tout object donné ne peut implémenter qu’une seule classe abstraite. Plusieurs fois, je trouve cela une limitation des classes abstraites, et c’est pourquoi j’utilise beaucoup d’interfaces.

Les classes abstraites peuvent contenir plusieurs interfaces. Votre classe abstraite PetBase peut implémenter IPet (animaux de compagnie ayant des propriétaires) et IDigestion (les animaux de compagnie mangent ou au moins ils devraient). Cependant, PetBase ne va probablement pas implémenter IMammal, car tous les animaux ne sont pas des mammifères et tous les mammifères ne sont pas des animaux de compagnie. Vous pouvez append une MammalPetBase qui étend PetBase et append IMammal. FishBase pourrait avoir PetBase et append IFish. IFish aurait ISwim et IUnderwaterBreather comme interfaces.

Oui, mon exemple est trop compliqué pour l’exemple simple, mais cela fait partie de la grande chose sur la façon dont les interfaces et les classes abstraites fonctionnent ensemble.

Le cas des classes de base sur les interfaces a été bien expliqué dans les directives de codage .NET Submain:

Classes de base et interfaces Un type d’interface est une description partielle d’une valeur, potentiellement prise en charge par de nombreux types d’objects. Utilisez des classes de base au lieu d’interfaces lorsque cela est possible. Du sharepoint vue de la gestion des versions, les classes sont plus flexibles que les interfaces. Avec une classe, vous pouvez envoyer la version 1.0, puis dans la version 2.0, append une nouvelle méthode à la classe. Tant que la méthode n’est pas abstraite, toutes les classes dérivées existantes continuent de fonctionner sans modification.

Étant donné que les interfaces ne prennent pas en charge l’inheritance d’implémentation, le modèle qui s’applique aux classes ne s’applique pas aux interfaces. Ajouter une méthode à une interface équivaut à append une méthode abstraite à une classe de base; toute classe qui implémente l’interface se brisera car la classe n’implémente pas la nouvelle méthode. Les interfaces sont appropriées dans les situations suivantes:

  1. Plusieurs classes non liées veulent prendre en charge le protocole.
  2. Ces classes ont déjà des classes de base établies (par exemple, certaines sont des commandes d’interface utilisateur et d’autres sont des services Web XML).
  3. L’agrégation n’est ni appropriée ni praticable. Dans toutes les autres situations, l’inheritance de classe est un meilleur modèle.

Une différence importante est que vous ne pouvez hériter que d’ une classe de base, mais que vous pouvez implémenter de nombreuses interfaces. Vous ne voulez donc utiliser une classe de base que si vous êtes absolument certain de ne pas devoir hériter d’une classe de base différente. De plus, si vous constatez que votre interface devient volumineuse, vous devriez commencer à la diviser en quelques éléments logiques qui définissent des fonctionnalités indépendantes, car il n’existe aucune règle selon laquelle votre classe ne peut pas les implémenter tous (ou définir une interface qui les hérite tout pour les regrouper).

Lorsque j’ai commencé à apprendre la programmation orientée object, j’ai commis l’erreur facile et probablement courante d’utiliser l’inheritance pour partager un comportement commun, même lorsque ce comportement n’était pas essentiel à la nature de l’object.

Pour développer davantage un exemple très utilisé dans cette question particulière, il y a beaucoup de choses qui peuvent être manipulées – copines, voitures, couvertures floues … – donc j’aurais pu avoir une classe Petable qui fournissait ce comportement commun et diverses classes héritant à partir de cela.

Cependant, être petable ne fait partie de la nature d’aucun de ces objects. Il y a des concepts beaucoup plus importants qui sont essentiels à leur nature – la petite amie est une personne, la voiture est un véhicule terrestre, le chat est un mammifère …

Les comportements doivent être affectés en premier aux interfaces (y compris l’interface par défaut de la classe) et promus en classe de base uniquement s’ils sont (a) communs à un grand groupe de classes qui sont des sous-ensembles d’une classe plus large “chat” et “personne” sont des sous-ensembles de “mammifère”.

Le problème est que, une fois que vous avez compris la conception orientée object suffisamment mieux que ce que je faisais au départ, vous le ferez normalement sans même y penser. Donc, la simple vérité de l’affirmation “code à une interface, pas à une classe abstraite” devient si évidente que vous avez du mal à croire que quelqu’un prendrait la peine de le dire – et commencerait à y lire d’autres significations.

Une autre chose que j’appendais est que si une classe est purement abstraite – sans membres non abstraits et non hérités ou avec des méthodes exposées à l’enfant, au parent ou au client – alors pourquoi est-ce une classe? Il pourrait être remplacé, dans certains cas, par une interface et dans d’autres cas par Null.

Source : http://jasonroell.com/2014/12/09/interfaces-vs-abstract-classes-what-should-you-use/

C # est une langue merveilleuse qui a mûri et évolué au cours des 14 dernières années. C’est très bien pour nous, développeurs, car un langage mature nous fournit une multitude de fonctionnalités linguistiques à notre disposition.

Cependant, avec beaucoup de pouvoir devient beaucoup de responsabilité. Certaines de ces fonctionnalités peuvent être utilisées à mauvais escient, ou il est parfois difficile de comprendre pourquoi vous choisiriez d’utiliser une fonctionnalité plutôt qu’une autre. Au fil des ans, une des fonctionnalités que j’ai rencontrées par de nombreux développeurs est de savoir quand choisir d’utiliser une interface ou de choisir d’utiliser une classe abstraite. Les deux présentent des avantages et des inconvénients, ainsi que le bon moment et le bon endroit pour les utiliser. Mais comment on décide ???

Les deux permettent de réutiliser les fonctionnalités communes entre les types. The most obvious difference right away is that interfaces provide no implementation for their functionality whereas abstract classes allow you to implement some “base” or “default” behavior and then have the ability to “override” this default behavior with the classes derived types if necessary.

This is all well and good and provides for great reuse of code and adheres to the DRY (Don’t Repeat Yourself) principle of software development. Abstract classes are great to use when you have an “is a” relationship.

For example: A golden resortingever “is a” type of dog. So is a poodle. They both can bark, as all dogs can. However, you might want to state that the poodle park is significantly different than the “default” dog bark. Therefor, it could make sense for you to implement something as follows:

 public abstract class Dog { public virtual void Bark() { Console.WriteLine("Base Class implementation of Bark"); } } public class GoldenResortingever : Dog { // the Bark method is inherited from the Dog class } public class Poodle : Dog { // here we are overriding the base functionality of Bark with our new implementation // specific to the Poodle class public override void Bark() { Console.WriteLine("Poodle's implementation of Bark"); } } // Add a list of dogs to a collection and call the bark method. void Main() { var poodle = new Poodle(); var goldenResortingever = new GoldenResortingever(); var dogs = new List(); dogs.Add(poodle); dogs.Add(goldenResortingever); foreach (var dog in dogs) { dog.Bark(); } } // Output will be: // Poodle's implementation of Bark // Base Class implementation of Bark // 

As you can see, this would be a great way to keep your code DRY and allow for the base class implementation be called when any of the types can just rely on the default Bark instead of a special case implementation. The classes like GoldenResortingever, Boxer, Lab could all could inherit the “default” (bass class) Bark at no charge just because they implement the Dog abstract class.

But I’m sure you already knew that.

You are here because you want to understand why you might want to choose an interface over an abstract class or vice versa. Well one reason you may want to choose an interface over an abstract class is when you don’t have or want to prevent a default implementation. This is usually because the types that are implementing the interface not related in an “is a” relationship. Actually, they don’t have to be related at all except for the fact that each type “is able” or has “the ablity” to do something or have something.

Now what the heck does that mean? Well, for example: A human is not a duck…and a duck is not a human. Pretty obvious. However, both a duck and a human have “the ability” to swim (given that the human passed his swimming lessons in 1st grade 🙂 ). Also, since a duck is not a human or vice versa, this is not an “is a” realationship, but instead an “is able” relationship and we can use an interface to illustrate that:

 // Create ISwimable interface public interface ISwimable { public void Swim(); } // Have Human implement ISwimable Interface public class Human : ISwimable public void Swim() { //Human's implementation of Swim Console.WriteLine("I'm a human swimming!"); } // Have Duck implement ISwimable interface public class Duck: ISwimable { public void Swim() { // Duck's implementation of Swim Console.WriteLine("Quack! Quack! I'm a Duck swimming!") } } //Now they can both be used in places where you just need an object that has the ability "to swim" public void ShowHowYouSwim(ISwimable somethingThatCanSwim) { somethingThatCanSwim.Swim(); } public void Main() { var human = new Human(); var duck = new Duck(); var listOfThingsThatCanSwim = new List(); listOfThingsThatCanSwim.Add(duck); listOfThingsThatCanSwim.Add(human); foreach (var something in listOfThingsThatCanSwim) { ShowHowYouSwim(something); } } // So at runtime the correct implementation of something.Swim() will be called // Output: // Quack! Quack! I'm a Duck swimming! // I'm a human swimming! 

Using interfaces like the code above will allow you to pass an object into a method that “is able” to do something. The code doesn’t care how it does it…All it knows is that it can call the Swim method on that object and that object will know which behavior take at run-time based on its type.

Once again, this helps your code stay DRY so that you would not have to write multiple methods that are calling the object to preform the same core function (ShowHowHumanSwims(human), ShowHowDuckSwims(duck), etc.)

Using an interface here allows the calling methods to not have to worry about what type is which or how the behavior is implemented. It just knows that given the interface, each object will have to have implemented the Swim method so it is safe to call it in its own code and allow the behavior of the Swim method be handled within its own class.

Résumé:

So my main rule of thumb is use an abstract class when you want to implement a “default” functionality for a class hierarchy or/and the classes or types you are working with share a “is a” relationship (ex. poodle “is a” type of dog).

On the other hand use an interface when you do not have an “is a” relationship but have types that share “the ability” to do something or have something (ex. Duck “is not” a human. However, duck and human share “the ability” to swim).

Another difference to note between abstract classes and interfaces is that a class can implement one to many interfaces but a class can only inherit from ONE abstract class (or any class for that matter). Yes, you can nest classes and have an inheritance hierarchy (which many programs do and should have) but you cannot inherit two classes in one derived class definition (this rule applies to C#. In some other languages you are able to do this, usually only because of the lack of interfaces in these languages).

Also remember when using interfaces to adhere to the Interface Segregation Principle (ISP). ISP states that no client should be forced to depend on methods it does not use. For this reason interfaces should be focused on specific tasks and are usually very small (ex. IDisposable, IComparable ).

Another tip is if you are developing small, concise bits of functionality, use interfaces. If you are designing large functional units, use an abstract class.

Hope this clears things up for some people!

Also if you can think of any better examples or want to point something out, please do so in the comments below!

Previous comments about using abstract classes for common implementation is definitely on the mark. One benefit I haven’t seen mentioned yet is that the use of interfaces makes it much easier to implement mock objects for the purpose of unit testing. Defining IPet and PetBase as Jason Cohen described enables you to mock different data conditions easily, without the overhead of a physical database (until you decide it’s time to test the real thing).

Don’t use a base class unless you know what it means, and that it applies in this case. If it applies, use it, otherwise, use interfaces. But note the answer about small interfaces.

Public Inheritance is overused in OOD and expresses a lot more than most developers realize or are willing to live up to. See the Liskov Substitutablity Principle

In short, if A “is a” B then A requires no more than B and delivers no less than B, for every method it exposes.

Conceptually, an Interface is used to formally and semi-formally define a set of methods that an object will provide. Formally means a set of method names and signatures, semi-formally means human readable documentation associated with those methods. Interfaces are only descriptions of an API (after all, API stands for Application Programmer Interface ), they can’t contain any implementation, and it’s not possible to use or run an Interface. They only make explicit the contract of how you should interact with an object.

Classes provide an implementation, they can declare that they implement zero, one or more Interfaces. If a Class is intended to be inherited, the convention is to prefix the Class name with “Base”.

There is a distinction between a Base Class and an Abstract Base Classes (ABC). ABCs mix interface and implementation together. Abstract outside of computer programming means “summary”, that is “Abstract == Interface”. An Abstract Base Class can then describe both an interface, as well as an empty, partial or complete implementation that is intended to be inherited.

Opinions on when to use Interfaces versus Abstract Base Classes versus just Classes is going to vary wildly based on both what you are developing, and which language you are developing in. Interfaces are often associated only with statically typed languages such as Java or C#, but dynamically typed languages can also have Interfaces and Abstract Base Classes. In Python for example, the distinction is made clear between a Class, which declares that it implements an Interface, and an object, which is an instance of a Class, and is said to provide that Interface. It’s possible in a dynamic language that two objects that are both instances of the same Class, can declare that they provide completely different interfaces. In Python this is only possible for object atsortingbutes, while methods are shared state between all objects of a Class. However in Ruby, objects can have per-instance methods, so it’s possible that the Interface between two objects of the same Class can vary as much as the programmer desires (however, Ruby doesn’t have any explicit way of declaring Interfaces).

In dynamic languages the Interface to an object is often implicitly assumed, either by introspecting an object and asking it what methods it provides (Look Before You Leap) or preferably by simply attempting to use the desired Interface on an object and catching exceptions if the object doesn’t provide that Interface (Easier to Ask Forgiveness than Permission). This can lead to “false positives” where two Interfaces have the same method name but are semantically different, however the trade-off is that your code is more flexible since you don’t need to over specify up-front to anticipate all possible uses of your code.

Another option to keep in mind is using the “has-a” relationship, aka “is implemented in terms of” or “composition.” Sometimes this is a cleaner, more flexible way to structure things than using “is-a” inheritance.

It may not make as much sense logically to say that Dog and Cat both “have” a Pet, but it avoids common multiple inheritance pitfalls:

 public class Pet { void Bathe(); void Train(Trick t); } public class Dog { private Pet pet; public void Bathe() { pet.Bathe(); } public void Train(Trick t) { pet.Train(t); } } public class Cat { private Pet pet; public void Bathe() { pet.Bathe(); } public void Train(Trick t) { pet.Train(t); } } 

Yes, this example shows that there is a lot of code duplication and lack of elegance involved in doing things this way. But one should also appreciate that this helps to keep Dog and Cat decoupled from the Pet class (in that Dog and Cat do not have access to the private members of Pet), and it leaves room for Dog and Cat to inherit from something else–possibly the Mammal class.

Composition is preferable when no private access is required and you don’t need to refer to Dog and Cat using generic Pet references/pointers. Interfaces give you that generic reference capability and can help cut down on the verbosity of your code, but they can also obfuscate things when they are poorly organized. Inheritance is useful when you need private member access, and in using it you are committing yourself to highly coupling your Dog and Cat classes to your Pet class, which is a steep cost to pay.

Between inheritance, composition, and interfaces there is no one way that is always right, and it helps to consider how all three options can be used in harmony. Of the three, inheritance is typically the option that should be used the least often.

Prefer interfaces over abstract classes

Rationale, the main points to consider [two already mentioned here] are :

  • Interfaces are more flexible, because a class can implement multiple interfaces. Since Java does not have multiple inheritance, using abstract classes prevents your users from using any other class hierarchy. In general, prefer interfaces when there are no default implementations or state. Java collections offer good examples of this (Map, Set, etc.).
  • Abstract classes have the advantage of allowing better forward compatibility. Once clients use an interface, you cannot change it; if they use an abstract class, you can still add behavior without breaking existing code. If compatibility is a concern, consider using abstract classes.
  • Even if you do have default implementations or internal state, consider offering an interface and an abstract implementation of it . This will assist clients, but still allow them greater freedom if desired [1].
    Of course, the subject has been discussed at length elsewhere [2,3].

[1] It adds more code, of course, but if brevity is your primary concern, you probably should have avoided Java in the first place!

[2] Joshua Bloch, Effective Java, items 16-18.

[3] http://www.codeproject.com/KB/ar

It depends on your requirements. If IPet is simple enough, I would prefer to implement that. Otherwise, if PetBase implements a ton of functionality you don’t want to duplicate, then have at it.

The downside to implementing a base class is the requirement to override (or new ) existing methods. This makes them virtual methods which means you have to be careful about how you use the object instance.

Lastly, the single inheritance of .NET kills me. A naive example: Say you’re making a user control, so you inherit UserControl . But, now you’re locked out of also inheriting PetBase . This forces you to reorganize, such as to make a PetBase class member, instead.

@Joel: Some languages (eg, C++) allow multiple-inheritance.

I usually don’t implement either until I need one. I favor interfaces over abstract classes because that gives a little more flexibility. If there’s common behavior in some of the inheriting classes I move that up and make an abstract base class. I don’t see the need for both, since they essentially server the same purpose, and having both is a bad code smell (imho) that the solution has been over-engineered.

Regarding C#, in some senses interfaces and abstract classes can be interchangeable. However, the differences are: i) interfaces cannot implement code; ii) because of this, interfaces cannot call further up the stack to subclass; and iii) only can abstract class may be inherited on a class, whereas multiple interfaces may be implemented on a class.

I’ve found that a pattern of Interface > Abstract > Concrete works in the following use-case:

 1. You have a general interface (eg IPet) 2. You have a implementation that is less general (eg Mammal) 3. You have many concrete members (eg Cat, Dog, Ape) 

The abstract class defines default shared atsortingbutes of the concrete classes, yet enforces the interface. Par exemple:

 public interface IPet{ public boolean hasHair(); public boolean walksUprights(); public boolean hasNipples(); } 

Now, since all mammals have hair and nipples (AFAIK, I’m not a zoologist), we can roll this into the abstract base class

 public abstract class Mammal() implements IPet{ @override public walksUpright(){ throw new NotSupportedException("Walks Upright not implemented"); } @override public hasNipples(){return true} @override public hasHair(){return true} 

And then the concrete classes merely define that they walk upright.

 public class Ape extends Mammal(){ @override public walksUpright(return true) } public class Catextends Mammal(){ @override public walksUpright(return false) } 

This design is nice when there are lots of concrete classes, and you don’t want to maintain boilerplate just to program to an interface. If new methods were added to the interface, it would break all of the resulting classes, so you are still getting the advantages of the interface approach.

In this case, the abstract could just as well be concrete; however, the abstract designation helps to emphasize that this pattern is being employed.

An inheritor of a base class should have an “is a” relationship. Interface represents An “implements a” relationship. So only use a base class when your inheritors will maintain the is a relationship.

Use Interfaces to enforce a contract ACROSS families of unrelated classes. For example, you might have common access methods for classes that represent collections, but contain radically different data ie one class might represent a result set from a query, while the other might represent the images in a gallery. Also, you can implement multiple interfaces, thus allowing you to blend (and signify) the capabilities of the class.

Use Inheritance when the classes bear a common relationship and therefore have a similair structural and behavioural signature, ie Car, Motorbike, Truck and SUV are all types of road vehicle that might contain a number of wheels, a top speed