Comment puis-je savoir quand créer une interface?

J'aime beaucoup la réponse de Jimmy, mais je sens que je dois y ajouter quelque chose. La clé du tout est le "able" dans IProcess able . Il indique une capacité (ou une propriété, mais signifiant "qualité intrinsèque", pas dans le sens des propriétés C#) de l'objet qui implémente l'interface. IAnimal n'est probablement pas un bon exemple pour une interface, mais IWalkable pourrait être une bonne interface à avoir si votre système a beaucoup de choses qui peuvent marcher. Vous pourriez avoir des classes dérivées de Animal comme chien, vache, poisson, serpent. Les deux premiers implémenteraient probablement IWalkable, les deux derniers ne marchent pas, donc ils ne le feraient pas. Maintenant, vous demandez "pourquoi ne pas simplement avoir une autre superclasse, WalkingAnimal, dont le chien et la vache dérivent?". La réponse est quand vous avez quelque chose complètement en dehors de l'arbre d'héritage qui peut aussi marcher, comme un robot. Robot implémenterait IWalkable, mais ne dériverait probablement pas D'Animal. Si vous voulez une liste de choses qui peuvent marcher, vous tapez comme IWalkable et vous peut mettre tous les animaux de marche ainsi que des robots dans la liste.

Maintenant, remplacez IWalkable par quelque chose de plus Logiciel-y comme IPersistable, et L'analogie devient beaucoup plus proche de ce que vous verriez dans un programme réel.

Utilisez des interfaces lorsque les implémentations de la même fonctionnalité diffèrent.

Utilisez des classes abstraites / de base lorsque vous devez partager une implémentation concrète commune.

Pensez à une interface comme un contrat. C'est une façon de dire, "Ces classes doivent suivre ces règles."

Donc, dans L'exemple IAnimal, c'est une façon de dire: "je dois être capable d'appeler Run, Walk, etc. sur les classes qui implémentent IAnimal."

Pourquoi est-ce utile? Vous pouvez créer une fonction qui repose sur le fait que vous devez être capable d'appeler Run and Walk, par exemple, sur l'objet. Vous pourriez avoir ce qui suit:

public void RunThenWalk(Monkey m) {
    m.Run();
    m.Walk();
}

public void RunThenWalk(Dog d) {
    d.Run();
    d.Walk();
}

... et répétez cela pour tous les objets qui, vous savez, peut courir et marcher. Cependant, avec votre interface IAnimal, vous pouvez définir la fonction une fois comme suit:

public void RunThenWalk(IAnimal a) {
    a.Run();
    a.Walk();
}

En programmant sur l'interface, vous faites essentiellement confiance aux classes pour implémenter l'intention de l'interface. Donc, dans notre exemple, la pensée est "je me fiche Comment {[12] } Ils courent et marchent, tant qu'ils courent et marchent. Mon RunThenWalk sera valide tant qu'ils respectent cet accord. Il fonctionne parfaitement bien sans rien savoir d'autre à propos de la classe."

Il est également une bonne discussion dans cette question connexe.

Ne vous inquiétez pas tant. Beaucoup de développeurs, auront rarement besoin d'écrire une interface. Vous utiliserez fréquemment les interfaces disponibles dans le cadre . Net, mais si vous ne ressentez pas le besoin d'en écrire un de sitôt, cela n'a rien de surprenant.

L'exemple que je donne toujours à quelqu'un est si vous avez une classe de voilier et une classe de Vipère. Ils héritent respectivement de la classe bateau et de la classe Voiture. Maintenant, dites que vous devez faire une boucle à travers tous ces objets et appeler leur Drive() méthode. Alors que vous pouvez écrire du code comme suit:

if(myObject is Boat)
    ((Boat)myObject).Drive()
else
    if (myObject is Car)
        ((Car)myObject).Drive()

, Il serait beaucoup plus simple d'écrire:

((IDrivable)myObject).Drive()

Jimmy a raison, quand vous voulez pouvoir utiliser une seule variable pour plusieurs types, mais tous ces types implémentent la même méthode via une déclaration d'interface. Ensuite, vous pouvez les appeler méthode principale sur la variable typée interface.

Il y a une deuxième raison d'utiliser des interfaces, cependant. Lorsque l'architecte de projet est une personne différente du codeur d'implémentation, ou qu'il y a plusieurs codeurs d'implémentation et un gestionnaire de projet. La personne responsable peut écrire un ensemble tas d'interfaces et voir que le système interopère, puis laisser aux développeurs de remplir les interfaces avec des classes d'implémentation. C'est la meilleure façon de s'assurer que plusieurs personnes écrivent des classes compatibles, et elles peuvent le faire en parallèle.

Dans mon expérience, la force motrice pour créer des interfaces ne s'est pas produite jusqu'à ce que je commence à faire des tests unitaires avec un framework moqueur. Il est devenu très clair que l'utilisation d'interfaces allait rendre la moquerie beaucoup plus facile (puisque le framework dépendait des méthodes virtuelles). Une fois que j'ai commencé, j'ai vu la valeur d'extraire l'interface de ma classe de l'implémentation. Même si Je ne crée pas d'interface réelle, j'essaie maintenant de rendre mes méthodes virtuelles (en fournissant un implicite interface qui peut être remplacée).

Il y a beaucoup d'autres raisons que j'ai trouvées pour renforcer la bonne pratique de refactoring aux interfaces, mais le test unitaire/moqueur était ce qui a fourni le "moment aha" initial de l'expérience pratique.

EDIT : pour clarifier, avec les tests unitaires et les moqueries, j'ai toujours deux implémentations - l'implémentation réelle et concrète et une implémentation simulée alternative utilisée dans les tests. Une fois que vous avez deux implémentations, la valeur de l'interface devient évident - traiter en termes d'interface de sorte que vous pouvez remplacer l'implémentation à tout moment. Dans ce cas, je le remplace par une interface simulée. Je sais que je peux le faire sans interface réelle si ma classe est construite correctement, mais l'utilisation d'une interface réelle renforce cela et le rend plus propre (plus clair pour le lecteur). Sans cet élan, Je ne pense pas que j'aurais apprécié la valeur des interfaces puisque la plupart de mes classes seulement, ont jamais un mise en œuvre concrète unique.

J'aime l'analogie de l'armée.

Sergent ne se soucie pas si Vous êtes un développeur de logiciels, musicien ou avocat.
Vous êtes traité comme soldat .

Il estplus facile pour le sergent de ne pas s'embêter avec des détails précis sur les personnes avec lesquelles il travaille,
traitez tout le monde comme des abstractions de soldats (...et les punir quand ils ne parviennent pas à agir comme ceux).

La capacité des personnes à agir comme des soldats est appelée polymorphisme.

Les Interfaces sont des constructions logicielles qui aident à atteindre le polymorphisme.

Besoin d' pour abstraire les détails pour atteindre la simplicité est la réponse à Votre question.

Polymorphisme, dont l'étymologie signifie "plusieurs formes", est la capacité de traiter un objet d'une sous-classe d'une classe de base, comme si c'était un objet de la classe de base. Une classe de base a donc de nombreuses formes: la classe de base elle-même et l'une de ses sous-classes.

(..) Cela rend votre code plus facile à écrire et plus facile à comprendre pour les autres. Cela rend également votre code extensible, car d'autres sous-classes pourraient être ajoutées plus tard à la famille de types, et les objets de ces nouvelles sous-classes fonctionneraient également avec le code existant.

Quelques exemples de non-programmation qui pourraient vous aider à voir les utilisations appropriées des interfaces dans la programmation.

Il y a une interface entre les appareils électriques et le réseau électrique - c'est l'ensemble de conventions sur la forme des prises et des prises et les tensions/courants qui les traversent. Si vous souhaitez implémenter un nouveau dispositif électrique, tant que votre prise suit les règles, elle pourra obtenir des services du réseau. Cela rend extensibilité très facile et supprime ou réduit les coûts de coordination : vous n'avez pas à informer le fournisseur d'électricité sur le fonctionnement de votre nouvel appareil et de parvenir à un accord séparé sur la façon de brancher votre nouvel appareil dans le réseau.

Les pays ont des jauges de rail standard. Cela permet une division du travail entre les entreprises d'ingénierie qui déposent des rails et les entreprises d'ingénierie qui construisent des trains pour circuler sur ces rails, et cela permet aux entreprises ferroviaires de Remplacer et améliorez les trains sans réarchitecter l'ensemble du système.

Le service d'une entreprise présente à un client peut être décrit comme une interface: une interface bien définie insiste sur le service et les peaux les moyens. Lorsque vous mettez une lettre dans une boîte aux lettres, vous vous attendez à ce que le système postal La Livre dans un délai donné, mais vous n'avez aucune attente quant à la façon dont la lettre est livrée: vous n'avez pas besoin de savoir , et le service postal a la flexibilité de choisissez le moyen de livraison qui répond le mieux aux exigences et aux circonstances actuelles. Une exception à cela est la capacité des clients à choisir la Poste Aérienne-ce n'est pas le genre d'interface qu'un programmeur informatique moderne aurait conçu, car il révèle trop de la mise en œuvre.

Exemples de nature: Je ne suis pas trop passionné par les exemples eats (), makesSound (), moves (), etc. Ils décrivent le comportement, ce qui est correct, mais ils ne décrivent pas les interactions et comment ils sont activés. Les exemples évidents d'interfaces qui permettent des interactions dans la nature sont à voir avec la reproduction, par exemple Une fleur fournit une certaine interface à une abeille afin que la pollinisation puisse avoir lieu.

Il est tout à fait possible d'aller toute votre vie en tant que développeur. net et de ne jamais écrire vos propres interfaces. Après tout, nous avons bien survécu sans eux pendant des décennies et nos langues étaient encore Turing-complet.

Je ne peux pas vous dire pourquoi vous avez besoin d'interfaces, mais je peux vous donner une liste des endroits où nous les utilisons dans notre projet actuel:

1. Dans notre modèle de plug-in, nous chargeons les plug-ins par interface et fournissons cette interface aux écrivains de plug-in pour se conformer.

2. Dans notre système de messagerie intermachine, les classes de messages implémentent toutes une interface spécifique et sont "déballées" à l'aide de l'interface.

3. Notre système de gestion de la configuration définit une interface utilisée pour définir et récupérer les paramètres de configuration.

4. Nous avons une interface que nous utilisons pour éviter une mauvaise référence circulaire problème. (Ne le faites pas si vous n'avez pas à.)

Je suppose que s'il y a une règle, c'est d'utiliser des interfaces lorsque vous voulez en grouper plusieurs classes dans une relation is-a, mais vous ne voulez pas fournir d'implémentation dans la classe de base.

Un exemple de code (combinaison de Andrew avec un extra à what-is-the-purpose-of-interfaces), qui explique également pourquoi interface au lieu d'une classe abstraite sur les langages sans support pour l'héritage multiple (C# et java):

interface ILogger
{
    void Log();
}
class FileLogger : ILogger
{
    public void Log() { }
}
class DataBaseLogger : ILogger
{
    public void Log() { }
}
public class MySpecialLogger : SpecialLoggerBase, ILogger
{
    public void Log() { }
}

Notez que FileLogger et DataBaseLogger n'ont pas besoin de l'interface (pourrait être une classe de base abstraite de L'enregistreur). Mais considérez que vous devez utiliser un enregistreur tiers qui vous oblige à utiliser une classe de base (disons-le expose les méthodes protégées que vous devez utiliser). Comme le langage ne prend pas en charge l'héritage multiple, vous ne pourrez pas utiliser l'approche de la classe de base abstraite.

L'essentiel est: utilisez une interface lorsque cela est possible pour obtenir une flexibilité supplémentaire sur votre code. Votre implémentation est moins liée, donc elle s'adapte mieux au changement.

J'ai utilisé des interfaces de temps en temps et voici ma dernière utilisation (les noms ont été généralisés):

J'ai un tas de contrôles personnalisés sur un WinForm qui doivent enregistrer des données dans mon objet métier. Une approche consiste à appeler chaque contrôle séparément:

myBusinessObject.Save(controlA.Data);
myBusinessObject.Save(controlB.Data);
myBusinessObject.Save(controlC.Data);

Le problème avec cette implémentation est que chaque fois que j'ajoute un contrôle, je dois aller dans ma méthode "Save Data" et ajouter le nouveau contrôle.

J'ai changé mes contrôles pour implémenter une interface ISaveable qui a une méthode SaveToBusinessObject(...) alors maintenant, ma méthode" Save Data " itère simplement à travers les contrôles et si elle en trouve un qui est ISaveable, elle appelle SaveToBusinessObject. Alors maintenant, quand un nouveau contrôle est nécessaire, tout ce que quelqu'un a à faire est d'implémenter ISaveable dans cet objet (et ne jamais toucher une autre classe).

foreach(Control c in Controls)
{
  ISaveable s = c as ISaveable;

  if( s != null )
      s.SaveToBusinessObject(myBusinessObject);
}

L'avantage souvent non réalisé pour les interfaces est que vous localisez les modifications. Une fois défini, vous modifierez rarement le flux global d'une application, mais vous apporterez souvent des modifications sur le détail de niveau. Lorsque vous conservez les détails dans des objets spécifiques, une modification de ProcessA n'affectera pas une modification de ProcessB. (Les classes de Base vous donnent également cet avantage.)

EDIT: un autre avantage est la spécificité des actions. Comme dans mon exemple, tout ce que je veux faire est de sauvegarder les données; Je ne me soucie pas de quel type de contrôle il s'agit ou s'il peut faire autre chose-je veux juste savoir si je peux enregistrer les données dans le contrôle. Cela rend mon code de sauvegarde assez clair - il n'y a pas de vérifications pour voir si c'est du texte, numérique, booléen ou autre parce que le contrôle personnalisé gère tout cela.

Vous devez définir une interface une fois que vous avez besoin de forcer un comportement pour votre classe.

Le comportement d'un Animal peut impliquer la marche, manger, courir, etc. Par conséquent, vous les définissez comme des interfaces.

Un autre exemple pratique est L'interface ActionListener (ou Runnable). Vous les implémenteriez lorsque vous avez besoin de garder une trace d'un événement particulier. Par conséquent, vous devez fournir l'implémentation de la méthode actionPerformed(Event e) dans votre classe (ou sous-classe). De même, pour le Runnable interface, vous fournissez l'implémentation de la méthode public void run().

En outre, vous pouvez avoir ces interfaces implémentées par n'importe quel nombre de classes.

Une autre instance où les Interfaces sont utilisées (en Java) est d'implémenter l'héritage multiple offert en C++.

Supposons que vous voulez modéliser les désagréments qui pourraient se produire lorsque vous essayez de vous endormir.

Modèle Avant interfaces

class Mosquito {
    void flyAroundYourHead(){}
}

class Neighbour{
    void startScreaming(){}
}

class LampJustOutsideYourWindow(){
    void shineJustThroughYourWindow() {}
}

Comme vous le voyez clairement, beaucoup de "choses" peuvent être gênantes lorsque vous essayez de dormir.

Utilisation de classes sans interfaces

Mais quand il s'agit d'utiliser ces classes, nous avons un problème. Ils n'ont rien en commun. Vous devez appeler chaque méthode séparément.

class TestAnnoyingThings{
    void testAnnoyingThinks(Mosquito mosquito, Neighbour neighbour, LampJustOutsideYourWindow lamp){
         if(mosquito != null){
             mosquito.flyAroundYourHead();
         }
         if(neighbour!= null){
             neighbour.startScreaming();
         }
         if(lamp!= null){
             lamp.shineJustThroughYourWindow();
         }
    }
}

Modèle avec interfaces

Pour surmonter ce problème, nous pouvons introduire une iterface

interface Annoying{
   public void annoy();

}

Et l'implémenter dans les classes

class Mosquito implements Annoying {
    void flyAroundYourHead(){}

    void annoy(){
        flyAroundYourHead();
    }
}

class Neighbour implements Annoying{
    void startScreaming(){}

    void annoy(){
        startScreaming();
    }
}

class LampJustOutsideYourWindow implements Annoying{
    void shineJustThroughYourWindow() {}

    void annoy(){
        shineJustThroughYourWindow();
    }
}

Utilisation avec les interfaces

Ce qui rendra l'utilisation de ces classes beaucoup plus facile

class TestAnnoyingThings{
    void testAnnoyingThinks(Annoying annoying){
        annoying.annoy();
    }
}

L'exemple le plus simple à donner est quelque chose comme les processeurs de paiement.(Paypal, PDS etc.).

Disons que vous créez une interface IPaymentProcessor qui a des méthodes ProcessACH et ProcessCreditCard.

Vous pouvez maintenant implémenter une implémentation concrète de Paypal. Faire ces méthodes appellent des fonctions spécifiques PayPal.

Si vous décidez plus tard que vous devez passer à un autre fournisseur, vous pouvez. Il suffit de créer une autre implémentation concrète pour le nouveau fournisseur. Puisque tout ce que vous êtes lié est votre interface (Contrat), vous pouvez échanger celui que votre application utilise sans changer le code qui le consomme.

Il vous permet également d'effectuer des tests unitaires simulés (. net). si votre classe utilise une interface, vous pouvez simuler l'objet dans votre test unitaire et tester facilement la logique (sans toucher réellement la base de données, ou le service web, etc.).

Http://www.nmock.org/

Si vous parcourez les assemblys. NET Framework et explorez les classes de base pour l'un des objets standard, vous remarquerez de nombreuses interfaces (membres nommés ISomeName).

Les Interfaces sont essentiellement pour implémenter des frameworks, grands ou petits. Je ressentais la même chose à propos des interfaces jusqu'à ce que je veuille écrire mon propre cadre. J'ai également constaté que la compréhension des interfaces m'a aidé à apprendre les frameworks beaucoup plus rapidement. Le moment que vous voulez écrire un plus élégant solution pour à peu près tout, vous trouverez qu'une interface fait beaucoup de sens. C'est comme une méthode de laisser une classe mettre les vêtements appropriés pour le travail. Plus important encore, les interfaces permettent aux systèmes de devenir beaucoup plus auto-documentés, car les objets complexes deviennent moins complexes lorsque la classe implémente des interfaces, ce qui aide à catégoriser ses fonctionnalités.

Les Classes implémentent des interfaces lorsqu'elles veulent pouvoir participer explicitement à un framework ou implicitement. Par exemple, IDisposable est une interface commune qui fournit une signature de méthode pour la méthode Dispose() populaire et utile. Dans un framework, tout ce que vous ou un autre développeur devez savoir sur une classe est que si elle implémente IDisposable, alors vous le savez ((IDisposable)myObject).Dispose () est disponible pour être appelé à des fins de nettoyage.

Exemple classique: sans implémenter L'interface IDisposable, vous ne pouvez pas utiliser la construction de mot-clé "using ()" en C#, car elle nécessite que tout objet spécifié en tant que paramètre puisse être implicitement converti en IDisposable.

EXEMPLE COMPLEXE: Un exemple plus complexe serait le Système.ComponentModel.Classe de Composant. Cette classe implémente à la fois IDisposable et IComponent. La plupart, sinon tous les objets. net auxquels un concepteur visuel leur est associé implémentent IComponent afin que L'IDE puisse interagir avec le composant.

CONCLUSION: Comme vous devenez plus familier avec le. Net Framework, le premier chose que vous ferez lorsque vous rencontrerez une nouvelle classe dans le navigateur D'objets ou dans L'outil. Net Reflector (free) ( http://www.red-gate.com/products/reflector/) est de vérifier de quelle classe il hérite et aussi les interfaces qu'il implémente. . Net Reflector est encore meilleur que le navigateur D'objets car il vous permet également de voir les classes dérivées. Cela vous permet d'en apprendre davantage sur tous les objets qui dérivent d'une classe particulière, ce qui vous permet d'en apprendre davantage sur le framework fonctionnalité que vous ne saviez pas existait. Ceci est particulièrement important lorsque des espaces de noms mis à jour ou nouveaux sont ajoutés au.Net Framework.

Considérez que vous faites un jeu de tir à la première personne. Le joueur a plusieurs armes à choisir.

, Nous pouvons avoir une interface Gun, qui définit une fonction shoot().

Nous avons besoin de différentes sous-classes de Gun classe à savoir ShotGun Sniper et ainsi de suite.

ShotGun implements Gun{
    public void shoot(){
       \\shotgun implementation of shoot.
    } 
}

Sniper implements Gun{
    public void shoot(){
       \\sniper implementation of shoot.
    } 
}

Classe De Tir

List<Gun> listOfGuns = new ArrayList<Gun>();

Le tireur fait défiler ses armes, au fur et à mesure des besoins, en utilisant la fonction switchGun()

public void switchGun(){
    //code to cycle through the guns from the list of guns.
    currentGun = //the next gun in the list.
}

Nous pouvons définir le pistolet actuel, en utilisant la fonction ci-dessus et simplement appeler la fonction shoot(), lorsque fire() est appelé.

public void fire(){
    currentGun.shoot();
}

Le comportement de la fonction shoot varie en fonction des différentes implémentations de l'interface Gun.

Conclusion

Créer une interface, lorsqu'une fonction de classe dépend de une fonction d'une autre classe , qui est soumise à changer son comportement, en fonction de l'instance (objet) de la classe mettre.

Par exemple, la fonction fire() de la classe Shooter attend des pistolets(Sniper, ShotGun) pour implémenter la fonction shoot(). Donc, si nous changeons le pistolet et le feu.

shooter.switchGun();
shooter.fire();

Nous avons changé le comportement de la fonction fire().

Pour développer ce que Larsenal a dit. Une Interface est un contrat que toutes les classes d'implémentation doivent suivre. Pour cette raison, vous pouvez utiliser une technique appelée programmation au contrat. Cela permet à votre logiciel de devenir indépendant de l'implémentation.

Interfaces sont généralement utilisés lorsque vous souhaitez définir un comportement que les objets peuvent présenter.

Un bon exemple de ceci dans le monde. NET est l'interface IDisposable , qui est utilisée sur toutes les classes Microsoft qui utilisent des ressources système qui doivent être libérées manuellement. Cela nécessite que la classe qui l'implémente ait une méthode Dispose ().

(la méthode Dispose () est également appelée par la construction using language pour VB.NET et C # , qui ne fonctionne que sur IDisposables)

Gardez à l'esprit que vous pouvez vérifier si un objet implémente une interface spécifique en utilisant des constructions telles que TypeOf ... Is (VB.NET), is (C#), instanceof (Java), etc...

Comme plusieurs personnes ont probablement déjà répondu, les interfaces peuvent être utilisées pour appliquer certains comportements entre les classes qui n'implémenteront pas ces comportements de la même manière. Donc, en implémentant une interface, vous dites que votre classe A le comportement de l'interface. L'interface IAnimal ne serait pas une interface typique car Chien, Chat,Oiseau, etc. les classes sont des types d'animaux, et devraient probablement l'étendre, ce qui est un cas d'héritage. Au lieu de cela, une interface serait plus comme comportement animal dans ce cas, comme IRunnable, IFlyable, ITrainable, etc.

Les Interfaces sont bonnes pour beaucoup de choses, l'une des choses clés est la pluggability. Par exemple, déclarer une méthode qui a un paramètre List permettra de transmettre tout ce qui implémente L'interface List, permettant au développeur de supprimer et de brancher une liste différente ultérieurement sans avoir à réécrire une tonne de code.

Il est possible que vous n'utilisiez jamais d'interfaces, mais si vous projet à partir de zéro, en particulier un cadre de quelque sorte, vous aurez probablement envie de se familiariser avec eux.

Je recommande de lire le chapitre sur les interfaces dans Java Design par Coad, Mayfield et Kern. Ils l'expliquent un peu mieux que le texte d'introduction moyen. Si vous n'utilisez pas Java, vous pouvez simplement lire le début du chapitre, qui n'est que des concepts.

Comme toutes les techniques de programmation qui ajoutent de la flexibilité à votre système, les interfaces ajoutent également un certain niveau de complexité. Ils sont souvent géniaux et vous pouvez l'utiliser partout (vous pouvez créer une interface pour toutes vos classes) - mais ce faisant, vous créeriez un système plus complexe qui serait plus difficile à maintenir.

Il y a un compromis ici, comme d'habitude: la flexibilité sur la maintenabilité. Lequel est le plus important ? Il n'y a pas de réponses - cela dépend du projet. Mais rappelez-vous juste que tous les logiciels devront être maintenues...

Donc mon conseil: n'utilisez pas d'interfaces tant que vous n'en avez pas vraiment besoin. (Avec Visual Studio, vous pouvez extraire une interface d'une classe existante en 2 secondes - alors ne vous pressez pas.)

Cela dit, Quand avez-vous besoin de créer une interface ?

Je le fais quand je refactore une méthode qui soudainement doit traiter deux ou plusieurs classes similaires. Je crée ensuite une interface, attribue cette interface aux deux (ou plus) classes similaires et je change le type de paramètre de méthode (remplacez le type de classe par le type d'interface).

Et ça marche :o)

Une exception: quand je me moque des objets, l'interface est beaucoup plus facile à utiliser. Donc, je crée souvent une interface juste pour cela.

PS: quand j'écris "interface", je veux dire: "interface de n'importe quelle classe de base", y compris les classes d'interface pures. Notez que les classes abstraites sont souvent un meilleur pari que les interfaces pures puisque vous pouvez ajouter de la logique à ils.

Cordialement, Sylvain.

Les Interfaces deviendront évidentes lorsque vous deviendrez un développeur de bibliothèque (quelqu'un qui code pour d'autres codeurs). La plupart d'entre nous commencent en tant que développeurs d'applications, où nous utilisons des API et des bibliothèques de programmation existantes.

Dans le même sens que les Interfaces sont un contrat, personne n'a encore mentionné que les Interfaces sont un excellent moyen de rendre certaines parties de votre code stables. C'est particulièrement utile lorsqu'il s'agit d'un projetteam (ou lorsque vous développez code utilisé par d'autres développeurs). Alors, voici un scénario concret pour vous:

Lorsque vous développez du code dans une équipe , d'autres utiliseront éventuellement le code que vous écrivez. Ils seront plus heureux quand ils coderont sur vos interfaces (stables), et vous serez heureux quand vous aurez la liberté de changer vos implémentations (cachées derrière l'interface) sans casser le code de votre équipe. C'est une variante de Information hiding (les interfaces sont publiques, les implémentations sont masquées à partir du client programmeurs). En savoir plus sur variations protégées .

Voir Aussi cette question relative au codage d'une Interface .

Il y a tellement de raisons d'utiliser une interface.

1. Utilisation dans le comportement polymorphique. Où vous voulez appeler des méthodes spécifiques d'une classe enfant avec un inteface ayant une référence à la classe enfant.

2. Avoir un contrat avec des classes pour implémenter toutes les méthodes où c'est nécessaire, comme l'utilisation la plus courante est avec les objets COM, où une classe wrapper est générée sur une DLL qui hérite de l'interface; ces méthodes sont appelées dans les coulisses, et vous juste besoin de les implémenter mais avec la même structure que celle définie dans la DLL COM que vous ne pouvez connaître que via l'interface qu'ils exposent.

3. Pour réduire l'utilisation de la mémoire en chargeant des méthodes spécifiques dans une classe. Comme si vous avez trois objets métier et qu'ils sont implémentés dans une seule classe, vous pouvez utiliser trois interfaces.

Par exemple IUser, IOrder, IOrderItem

public interface IUser()
{

void AddUser(string name ,string fname);

}

// Same for IOrder and IOrderItem
//


public class  BusinessLayer: IUser, IOrder, IOrderItem

{    
    public void AddUser(string name ,string fname)
    {
        // Do stuffs here.
    }

    // All methods from all interfaces must be implemented.

}

Si vous voulez seulement ajouter un utilisateur, procédez comme ceci:

IUser user = new (IUser)BusinessLayer();

// It will load  all methods into memory which are declared in the IUser interface.

user.AddUser();