Quand doit-on utiliser les interfaces?

Dans des langages tels que Java et C# interfaces de fournir un moyen pour une classe d'être dans un polymorphe manière. C'est-à-dire une classe peut satisfaire plus d'un contrat, il peut se comporter comme plusieurs types différents, une classe d'un type peut être substitué à un autre. Dans d'autres langues, cela peut aussi être fourni par l'héritage multiple, mais il y a plusieurs inconvénients à cette approche. Cependant, une classe se comportent comme de plus d'un type n'est pas le plus commun de la motivation pour l'utilisation d'interfaces.

Par la programmation d'interfaces au lieu de classes, vous pouvez également dissocier votre programme à partir d'implémentations spécifiques. Cela le rend beaucoup plus facile de remplacer une classe de mise en œuvre pour l'autre. Ceci est particulièrement utile lors de l'écriture de tests unitaires où vous souhaitez échanger quelques poids lourds de la classe de mise en œuvre avec un léger l'objet fantaisie. Si votre programme ne prévoit qu'un type d'interface, et les deux poids lourds de l'objet et de l'objet fantaisie de mettre en œuvre ladite interface, alors qu'ils sont très faciles à remplacer.

Aussi, envisager un simple exemple Java où je dis avoir un programme qui affiche les pages de données sur l'écran. D'abord je veux pour obtenir les données à partir d'une base de données ou des fichiers XML. Si j'écris mon programme pour qu'il utilise les interfaces, je peux définir une interface comme ceci:

public interface PageDatasource {
    public List<Page> getPages();
}

Et de l'utiliser comme ceci:

PageDatasource datasource = //insert concrete PageDatasource implementation here
List<Pages> pages = datasource.getPages();
display(pages);

Je peux alors écrire une base de données et XML implémentations qui adhèrent à cette interface:

public class DatabasePageDatasource implements PageDatasource {
    public List<Page> getPages() {
        //Database specific code
    }
}

public class XmlPageDatasource implements PageDatasource {
    public List<Page> getPages() {
        //XML specific code
    }
}

Parce que j'ai utilisé une interface je peux maintenant utiliser la mise en œuvre des bases de données XML, de façon interchangeable, sans avoir à changer les pièces de mon programme qui demandent les données de la page. Le XML et Base de données des implémentations probablement faire des choses complètement différentes, mais tous mes programme se soucie est que l'objet en fournissant les données de la page implémente l' PageDatasource interface.

Même comme un seul développeur d'interfaces peuvent être un outil très utile. Laissez-moi illustrer avec un exemple.

Supposons que vous êtes en train de développer un système permettant de gérer un catalogue de bibliothèque et de la bibliothèque va prêter à la fois des livres et des Dvd. Vous décidez de créer des classes Livre et Dvd aux éléments de modèle d'être prêté mais maintenant, vous voulez mettre en œuvre le polymorphisme de sorte que vous pouvez traiter avec des articles plutôt que des livres ou des Dvd. La question est doit Élément être une classe abstraite ou une Interface ?

Dans ce cas, vous voudrez probablement utiliser une classe abstraite car il existe des fonctionnalités communes aux deux Livre et Dvd que vous pouvez fournir par un parent de la classe, par exemple, de la vérification ou de retourner un article.

Maintenant, disons que vous souhaitez mettre en place un mécanisme de persistance pour votre catalogue de bibliothèque. Vous avez décidé que vous voulez stocker des données dans une base de données, certaines données dans des fichiers XML et des données dans les fichiers délimités par des virgules. Donc, la question maintenant est de savoir comment vous pouvez aller à ce sujet dans un polymorphe manière qui vous permet de traiter avec une persistance API ?

Dans ce cas, vous devriez probablement définir une Interface qui peut être mis en œuvre par chacune de vos classes fournissant la base de données, XML et délimité par des virgules persistance puisque chacun de ces mécanismes de persistance fournit des fonctionnalités similaires, c'est à dire le stockage et la récupération de données, mais chacun sera mis en œuvre de manière très différente. Cela va vous permettre de changer facilement de laquelle mécanisme de persistance que vous utilisez sans avoir à faire beaucoup de changements de code qui utilise le mécanisme de persistance.

Au premier coup d'oeil, les classes abstraites et les interfaces paraître comme une évidence. Pourquoi fournir une interface lorsque vous fournir une base de mise en œuvre? Après enquête, vous trouverez qu'il ya plus à cette.

Cela dit, il y a un certain nombre de raisons pour utiliser les interfaces. Vous pouvez trouver un bon billet de blog sur les différences ici.

Cela dit, considérez le fait que vous pouvez créer une interface (un "contrat" qui dit que votre classe a certainement prend en charge certains appels/signature de la méthode des invocations), mais vous ne pouvez fournir une seule classe abstraite. Aussi considérer le fait que vous pouvez créer une classe abstraite qui implémente une ou plusieurs interfaces, et héritent de ce. Ce n'est pas un bord de cas. C'est effectivement assez fréquemment dans l'API pour haute extensibilité.

Consultez le blog je vous ai cité et vous devriez obtenir une compréhension approfondie de l'utilisation de chaque et pourquoi vous devez les utiliser. Je voudrais également fortement recommander un bon livre tel que "CLR via C#" par Microsoft Press. Vous en apprendrez beaucoup!

À ajouter à la réponse à la question précédente, les interfaces de vous aider lors de tests unitaires en vous permettant d'injecter un objet fantaisie basée sur une interface dans votre code, vous permettant de simuler des scénarios spécifiques et aussi d'isoler votre unité de test à un composant particulier sans s'appuyer sur des composants externes.

Par exemple, supposons que vous avez une logique d'entreprise de classe qui utilise les données de la logique de classe pour récupérer des données à partir d'une source de données et de les traiter ensuite. Par la création d'une interface pour les données de la logique de la classe dont elle hérite alors, vous pouvez créer une maquette/faux instance de cette classe en fonction de l'interface et de les injecter dans la classe de logique métier, vous êtes des tests unitaires. L'instance factices peuvent être définis de manière à obtenir une certaine méthode/propriété des appels, lancer des exceptions sur certains points, le retour valide sorties etc etc. Cela signifie, vos tests unitaires peuvent courir plus vite/potentiellement plus sûrement qu'ils ne comptent pas sur le sous-jacent de la source de données étant disponibles/n'ont pas besoin de s'y connecter. Et vous êtes isoler l'appareil de test de le réduire à une unité de code.

Les Interfaces et les classes abstraites servent à des fins différentes.
Pour commencer, une classe abstraite est seulement bon pour l'héritage de - il ne peut pas être instanciée directement. Vous pouvez mettre de la mise en œuvre du code dans une classe abstraite, mais ce code ne peut être appelé à partir de la classe qui étend la classe, ou par l'intermédiaire de la classe qui étend la classe elle.

exemple:

public abstract class A {
    public void myFunc() {
        //do some work
    }
}

public class B : A {
    private void someOtherFunc() {
        base.myFunc();
    }
}

public class Z {
    public void exampleFunc() {
        //call public base class function exposed through extending class:
        B myB = new B();
        myB.myFunc();

        //explicitly cast B to A:
        ((A) myB).myFunc();

        //'A' cannot be created directly, do implicit cast down to base class:
        A myA = new B();
        myA.myFunc();
    }
}

Le but de l'interface est de fournir un contrat - ce qui signifie que la classe qui l'implémente a à fournir mise en œuvre pour les propriétés ou fonctions déclarées dans l'interface, et c'est exactement la même fonction de signatures. Ceci fournit la caution, quand j'écris un code qui appelle une classe qui implémente une interface, et il n'est pas pertinent ce que les classes sont dérivées à partir de, ou même la langue qu'ils sont écrites, ou où je les ai fait partir. Une autre fonctionnalité intéressante est que je peux avoir plusieurs implémentations différentes de la même fonction de signature pour les différentes interfaces. Cochez cette exemple, qui utilise certains des mêmes classes de l'exemple précédent:

public class Z {
    public void exampleFunc() {
        C myC = new C();
        //these two calls both call the same function:
        myC.myFunc();
        ((IExampleInterface1)myC).myFunc();

        D myD = new D();
        //hmmm... try and work out what happens here, which myFunc() gets called?
        //(clue: check the base class)
        myD.myFunc();

        //call different myFunc() in same class with identical signatures:
        ((IExampleInterface1)myD).myFunc();
        ((IExampleInterface2)myD).myFunc();
    }
}

interface IExampleInterface1
{
    void myFunc();
}

interface IExampleInterface2
{
    void myFunc();
}

public class C : IExampleInterface1
{
    public void myFunc()
    {
        //do stuff
    }
}

public class D : A, IExampleInterface1, IExampleInterface2
{
    void IExampleInterface1.myFunc()
    {
        //this is called when D is cast as IExampleInterface1
    }

    void IExampleInterface2.myFunc()
    {
        //this is called when D is cast as IExampleInterface2
    }
}

Supposons que j'ai la classe FoodEstablishment, maintenant je veux faire simple opération CRUD, alors comment dois-je faire?
Je définir une interface pour le service, mais pourquoi?

public interface IFoodEstablishmentService
{
    Task<int> AddAsync(FoodEstablishment oFoodEstablishment);
    FoodEstablishment SelectByFoodEstablishmentId(long id);
    Task<int> UpdateAsync(FoodEstablishment oFoodEstablishment);
    Task<int> DeleteAsync(FoodEstablishment oFoodEstablishment);
}

Ensuite je vais mettre en œuvre ce contrat ou de l'interface pour ce service en particulier

public class FoodEstablishmentService : IFoodEstablishmentService
{
    public async Task<int> AddAsync(FoodEstablishment oFoodEstablishment)
    {
       //Insert Operation
        return result;
    }

    public FoodEstablishment SelectByFoodEstablishmentId(long id)
    {
        //Select Logic
        return oFoodEstablishment;
    }

    public async Task<int> UpdateAsync(FoodEstablishment oFoodEstablishment)
    {
        //Update Logic
        return result;
    }

    public async Task<int> DeleteAsync(FoodEstablishment oFoodEstablishment)
    {
        //Delete Logic
        return result;
    }

}

Donc dans mon programme principal ou lorsque je souhaite utiliser le Service, je vais faire

IFoodEstablishmentService oFoodEstablishmentService =  new FoodEstablishmentService();
FoodEstablishment oFoodEstablishment = //Input might be from views;
oFoodEstablishmentService.AddAsync(oFoodEstablishment);

Jusqu'à maintenant, il semble comme une étape supplémentaire, nous pourrions directement fait

FoodEstablishmentService oFoodEstablishmentService =  new FoodEstablishmentService();
FoodEstablishment oFoodEstablishment = //Input might be from views;
oFoodEstablishmentService.AddAsync(oFoodEstablishment);

Mais attendez quoi si je pourrais avoir besoin pour passer mon insérer de la logique par le biais de la file d'attente plutôt que directement à un serveur, d'attente pour l'opération d'insertion de remplir et de retourner ensuite conséquent, plutôt passer sur la file d'attente, puis la file d'attente travailleur manipule ceux de l'opération, peut-être pas la meilleure idée de la file d'attente de plaquette, mais oui certainement bon pour l'interface exemple :-). Alors maintenant, ce que je fais est, de créer une autre classe FoodEstablishment l'exécution du contrat IFoodEstablishment.

public class FoodEstablishmentQueueService : IFoodEstablishmentService
{
    public async Task<int> AddAsync(FoodEstablishment oFoodEstablishment)
    {
       //Insert Queue Operation
        return result;
    }

    public FoodEstablishment SelectByFoodEstablishmentId(long id)
    {
        //Select Queue Logic
        return oFoodEstablishment;
    }

    public async Task<int> UpdateAsync(FoodEstablishment oFoodEstablishment)
    {
        //Update Queue Logic
        return result;
    }

    public async Task<int> DeleteAsync(FoodEstablishment oFoodEstablishment)
    {
        //Delete Queue Logic
        return result;
    }
}

Alors maintenant, si je veux utiliser la file d'attente de la version, je voudrais juste faire

IFoodEstablishmentService oFoodEstablishmentService =  new FoodEstablishmentQueueService();
FoodEstablishment oFoodEstablishment = //Input might be from views;
oFoodEstablishmentService.AddAsync(oFoodEstablishment);

On pourrait le faire avec l'ancienne façon à l'aide de la classe, mais que les limites de l'instanciation de classe avec une classe particulière qui est un peu rigide de la vulgarisation, maintenant FoodEstablishmentQueueService pouvez faire d'autres choses aussi, créer une autre méthode jusqu'à ce que le contrat est valide si l'interface est en contact pour des raisons de cohérence, l'Imagerie, un gars qui fait de la version normale et l'autre en faisant la file d'attente de la version ou de quelqu'un qui fait cache version, il y a peut-être des problèmes concernant la signature, à moins que son pré-spécifié sur le contrat de travail et que les gens ne finissent pas à la contre-vérification de tout.

De même, envisager d'autres exemple simple d'utilisation de types prédéfinis comme IEnumerable. Supposons que je passe une liste de FoodEstablishment de collecte et de retourner sur liste triée

public FoodEstablishment[] SortFoodEstablishment(FoodEstablishment[] list)
{
    foreach(var oFoodEstablishment in list)
    {
    //some logic
    }
    return sortedList;
}

Nous allons donc l'utiliser de cette façon

FoodEstablishment[] list = new FoodEstablishment[]{ //some values }
var listSorted = oFoodEstablishmentService.SortFoodEstablishment(list);

Mais que faire si nous envoyer la liste au lieu de la matrice de

List<FoodEstablishment> list = //some values;
var listSorted = oFoodEstablishmentService.SortFoodEstablishment(list);

Nous allons obtenir une erreur, parce que la rigueur de sa mise en œuvre à l'aide de la classe au lieu de cela, nous utilisons IEnumerable<> qui est mis en œuvre par Liste et que, fondamentalement, supprime la dépendance de la Liste de l'Interface

public IEnumerable<FoodEstablishment> SortFoodEstablishment(IEnumerable<FoodEstablishment> list)
{
    foreach(var oFoodEstablishment in list)
    {
    //some logic
    }
    return sortedList;
}

Donc généralement mise en œuvre extrêmement dépend de la situation

Aussi, l'utilisation d'interfaces facilite les tests unitaires. Afin de tester les classes qui dépendent des interfaces, et aussi longtemps que vous êtes à l'aide de l'injection de dépendance, vous pouvez créer stub des classes qui implémentent l'dépendait des interfaces, ou vous pouvez utiliser un moqueur moteur.

Classe abstraite v/s de l'interface est toujours un point de discussion entre développeurs. Je voudrais ajouter mon 5 cents.
Utilisation de la classe abstraite lorsque vous souhaitez étendre un comman de base et où vous voulez fournir une implémentation par défaut de la méthode abstraite.

Utilisation de l'interface quand vous voulez exactement de mettre en œuvre toutes les méthodes abstraites de la classe implementaing l'interface et pas de défaut corps d'une méthode peuvent être fournis.

Interface conserve la définition et la mise en œuvre Séparée.Ainsi, dans le cas où si vous voulez Fournisseur de mise en Œuvre spécifiques, alors que c'est la meilleure façon de le faire .

L'exemple de la vie réelle c'est JDBC Si vous voyez l'API Statemnet ,PreparedStatemnet Tout ce qui est de l'interface, mais la mise en œuvre est spécifique au vendeur comme Oracle ojdbc pot a une autre mise en œuvre ,mysql eu quelques autres.

Dans le cas où vous souhaitez modifier la Base de données, vous avez juste à chnage le pilote de nad dans le cadre nom de la classe. C'est l'avantage de l'utilisation de l'interface

Objets qui appartiennent à une catégorie peuvent utiliser une Interface.Quand EST-il existe UNE relation entre les objets.

E. g. Texte,Image,MP3,FLV,MOV appartient FileType catégorie

Si notre application permet aux utilisateurs de télécharger des 4 types de fichiers qu'ils appartiennent tous à une seule catégorie appelée TYPE de FICHIER

1. Texte
2. Image
3. Audio
4. Vidéo

Dans le code, nous aurions objet pour chacun des types ci-dessus.

Supposons que nous avons besoin d'envoyer un fichier puis

Avec Interface de Sortie       

Avec Interface 

Donc on peut supposer que tous les types de fichiers(Texte,Audio, etc) pour être de type FileFormat.Donc nous former une relation " EST-UN.

Cela permet lors d'un retour de type de données unique  au lieu de renvoyer type spécifique à partir d'une fonction, nous pouvons envoyer des type le plus commun qui est FileFormat.