122 votes

Quelle est la différence entre une interface et une classe, et pourquoi devrais-je utiliser une interface alors que je peux implémenter les méthodes directement dans la classe ?

Je sais que c'est une question très basique, mais un interviewer me l'a posée d'une manière très compliquée et j'étais impuissant :(

Je ne connais que la définition matérielle ou théorique d'une interface et je l'ai également mise en œuvre dans de nombreux projets sur lesquels j'ai travaillé. Mais je ne comprends vraiment pas pourquoi et comment cela peut être utile.

Je ne comprends pas non plus une chose dans l'interface, c'est-à-dire que nous utilisons par exemple

conn.Dispose(); dans le bloc final. Mais je ne vois pas que la classe implémente ou hérite IDisposable interface ( SqlConnection ) classe, je veux dire. Je me demande comment je peux simplement appeler le nom de la méthode. De même, je ne comprends pas comment fonctionne la méthode Dispose, car nous devons implémenter le corps de la fonction avec notre propre implémentation pour toutes les méthodes d'interface. Alors comment les interfaces sont-elles acceptées ou nommées comme des contrats ? Ces questions n'ont cessé de me trotter dans la tête jusqu'à présent et, franchement, je n'ai jamais vu un bon fil de discussion qui expliquerait mes questions d'une manière que je puisse comprendre.

MSDN, comme d'habitude, a l'air très effrayant et aucune ligne n'y est claire ( Les amis, veuillez excuser ceux qui sont dans le développement de haut niveau, je crois fermement que tout code ou article doit atteindre l'esprit de quiconque le voit, donc comme beaucoup d'autres le disent, MSDN n'est pas utile. ).

L'enquêteur a dit :

Il a 5 méthodes et il est heureux de les implémenter directement dans la classe, mais si vous devez opter pour une classe abstraite ou une interface, laquelle choisissez-vous et pourquoi ? J'ai répondu à toutes les choses que j'ai lues dans différents blogs sur les avantages et les inconvénients des classes abstraites et des interfaces, mais il n'est pas convaincu, il essaie de comprendre "Pourquoi les interfaces" en général. "Pourquoi une classe abstraite en général, même si je ne peux implémenter les mêmes méthodes qu'une seule fois et que je ne vais pas les changer.

Je ne vois pas où sur le net, je pourrais trouver un article qui m'expliquerait clairement les interfaces et leur fonctionnement. Je suis l'un de ces nombreux programmeurs qui ne connaissent toujours pas les interfaces (je connais la théorie et les méthodes que j'ai utilisées), mais je ne suis pas convaincu de les avoir comprises clairement.

5 votes

J'ai également eu du mal à comprendre les interfaces. Bonne question.

4 votes

La programmation en fonction d'un contrat abstrait plutôt que d'une mise en œuvre concrète....En bref, cela signifie que vous pouvez substituer tout objet qui implémente une interface lorsqu'une interface est requise.

7 votes

SqlConnection hérite de System.ComponentModel.Component qui met en œuvre IDisposable .

94voto

Guilherme J Santos Points 1253

Les interfaces sont excellentes lorsque vous voulez créer quelque chose de semblable :

using System;

namespace MyInterfaceExample
{
    public interface IMyLogInterface
    {
        //I want to have a specific method that I'll use in MyLogClass
        void WriteLog();       
    }

    public class MyClass : IMyLogInterface
    {

        public void WriteLog()
        {
            Console.Write("MyClass was Logged");
        }
    }

    public class MyOtherClass : IMyLogInterface
    {

        public void WriteLog()
        {
            Console.Write("MyOtherClass was Logged");
            Console.Write("And I Logged it different, than MyClass");
        }
    }

    public class MyLogClass
    {
        //I created a WriteLog method where I can pass as a parameter any object that implements IMyLogInterface.
        public static void WriteLog(IMyLogInterface myLogObject)
        {
            myLogObject.WriteLog(); //So I can use WriteLog here.
        }
    }

    public class MyMainClass
    {
        public void DoSomething()
        {
            MyClass aClass = new MyClass();
            MyOtherClass otherClass = new MyOtherClass();

            MyLogClass.WriteLog(aClass);//MyClass can log, and have his own implementation
            MyLogClass.WriteLog(otherClass); //As MyOtherClass also have his own implementation on how to log.
        }
    }
}

Dans mon exemple, je pourrais être un développeur qui écrit MyLogClass et les autres développeurs, pouvaient créer leurs classes, et lorsqu'ils voulaient se connecter, ils implémentaient l'interface IMyLogInterface . C'est comme s'ils me demandaient ce qu'ils doivent mettre en œuvre pour utiliser WriteLog() méthode dans MyLogClass . La réponse, ils la trouveront dans l'interface.

3 votes

Hé, ça a l'air d'être un très bon ingrédient à comprendre pour moi, j'apprécie vraiment, merci beaucoup :) :)

14 votes

Ma question est la suivante : si vous instanciez MyClass y MyOtherClass pourquoi ne pas simplement appeler aClass.WriteLog() pourquoi ajouter cette étape supplémentaire. L'implémentation de WriteLog() resterait différente pour chacune des classes, mais vous avez déjà l'objet, alors pourquoi le passer à une classe gestionnaire ?

0 votes

Hm peut-être que si vous mettez votre exemple de journalisation sur nugget, il serait plus simple pour les autres d'utiliser votre logger, sans connaître les détails mais d'un autre côté, ce n'est toujours pas une classe universelle, (je pourrais écrire une interface avec des niveaux de journalisation ET d'alerte) les interfaces sont toujours seulement dans votre champ d'application. donc à part vous-même, qui en bénéficie ?

49voto

SliverNinja Points 15924

Interfaces sont des contrats que les exécutants doivent suivre. Classes abstraites permettent des contrats et des mises en œuvre partagées, ce qui n'est pas le cas des interfaces. Les classes peuvent implémenter et hériter de plusieurs interfaces. Les classes ne peuvent étendre qu'une seule classe abstraite.

Pourquoi l'interface

  • Vous n'avez pas d'implémentation de code par défaut ou partagé
  • Vous voulez partager des contrats de données (services web, SOA)
  • Vous avez des implémentations différentes pour chaque implémenteur d'interface ( IDbCommand a SqlCommand y OracleCommand qui implémentent l'interface de manière spécifique )
  • Vous voulez support de l'héritage multiple .

Pourquoi le résumé

2 votes

@Silver J'ai lu la plupart de ce que vous avez tapé dans les blogs, mais j'essaie de comprendre de manière pratique. J'ai fait des services WCF, des interfaces exposées (mais c'était juste une seule application autonome sans amont ni aval). Je n'ai donc pas pu le comprendre correctement bien que j'aie très bien conçu et mis en œuvre les interfaces. Ma question est la suivante : dans la pratique, vous partagez simplement les noms de méthodes avec les moyens contractuels, n'est-ce pas ? En quoi est-ce utile :( Je sais que cela oblige juste à implémenter toutes les méthodes, mais sinon comment ? Dans votre post ci-dessus sur l'interface, le deuxième point parle de partage, pouvez-vous donner un exemple pratique en temps réel de ceci ?

1 votes

Pour un exemple pratique concernant les interfaces et la SOA, nous partager nos interfaces WCF ( DataContracts ) dans un assemblage .NET ( par exemple, Contracts.Shared.dll ) afin que les clients .NET puissent facilement interopérer en utilisant ChannelFactory ( éviter de générer du code via l'ajout d'une référence de service, etc. ) ou en utilisant Ajouter une référence de service avec des types partagés

0 votes

Si je ne déclare que des méthodes abstraites à l'intérieur d'une classe abstraite, alors la classe abstraite agira comme une interface, alors pourquoi avons-nous besoin d'une interface ?

23voto

Gabriel C. Troia Points 547

En un mot - à cause de Polymorphisme !

Si vous "programmez en fonction d'une interface, pas d'une implémentation", vous pouvez injecter différents objets qui partagent la même interface (type) dans la méthode en tant qu'argument. De cette façon, le code de votre méthode n'est pas couplé à une implémentation d'une autre classe, ce qui signifie qu'il est toujours ouvert pour travailler avec des objets nouvellement créés de la même interface. (Principe d'ouverture/fermeture)

  • Regardez dans Dependency Injection et lisez certainement Patrons de conception - Éléments de logiciels orientés objet réutilisables par GOF.

4voto

Erix Points 3705

C# n'a pas de typage de canard - juste parce que vous savez qu'une certaine méthode est implémentée dans un ensemble de classes concrètes ne signifie pas que vous pouvez les traiter toutes de la même manière en ce qui concerne l'appel de cette méthode. L'implémentation d'une interface vous permet de traiter toutes les classes qui l'implémentent comme le même type de chose, en ce qui concerne ce que cette interface définit.

3 votes

Vous pouvez obtenir une sorte de ducktyping dans .net4 avec le type dynamique.

1voto

Jeow Li Huan Points 2133

Vous ne pouvez hériter que d'une seule classe abstraite. Vous pouvez hériter de plusieurs interfaces. Ceci détermine ce que j'utilise dans la plupart des cas.

L'avantage d'une classe abstraite est que vous pouvez avoir une implémentation de base. Cependant, dans le cas de IDisposable, une implémentation par défaut est inutile, puisque la classe de base ne sait pas comment nettoyer correctement les choses. Ainsi, une interface serait plus appropriée.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X