Quand utiliser une interface au lieu d'une classe abstraite et vice versa ?

Question

Il s'agit peut-être d'une question générique sur la POO. Je voulais faire une comparaison générique entre une interface et une classe abstraite sur la base de leur utilisation.

Quand veut-on utiliser une interface et quand veut-on utiliser une classe abstraite ? ?

Answer 1

J'ai écrit un article à ce sujet :

Classes et interfaces abstraites

Je résume :

Lorsque nous parlons de classes abstraites, nous définissons les caractéristiques d'un type d'objet, en spécifiant les éléments suivants ce qu'est un objet .

Lorsque nous parlons d'une interface et que nous définissons les capacités que nous promettons de fournir, nous parlons de l'établissement d'un contrat concernant ce que l'objet peut faire.

Answer 2

Une classe abstraite peut avoir un état ou une fonctionnalité partagée. Une interface est seulement une promesse de fournir l'état ou la fonctionnalité. Une bonne classe abstraite réduira la quantité de code à réécrire car sa fonctionnalité ou son état peut être partagé. L'interface n'a pas d'information définie à partager

Answer 3

Personnellement, je n'ai presque jamais besoin d'écrire des classes abstraites.

La plupart du temps, je vois des classes abstraites (mal) utilisées, c'est parce que l'auteur de la classe abstraite utilise le modèle de la "méthode modèle".

Le problème avec la "méthode modèle" est qu'elle est presque toujours quelque peu ré-entrante - la classe "dérivée" connaît non seulement la méthode "abstraite" de sa classe de base qu'elle implémente, mais aussi les méthodes publiques de la classe de base, même si la plupart du temps elle n'a pas besoin de les appeler.

Exemple (excessivement simplifié) :

abstract class QuickSorter
{
    public void Sort(object[] items)
    {
        // implementation code that somewhere along the way calls:
        bool less = compare(x,y);
        // ... more implementation code
    }
    abstract bool compare(object lhs, object rhs);
}

Ainsi, ici, l'auteur de cette classe a écrit un algorithme générique et souhaite que les gens l'utilisent en le "spécialisant" en fournissant leurs propres "crochets" - dans ce cas, une méthode "compare".

L'utilisation prévue est donc quelque chose comme ceci :

class NameSorter : QuickSorter
{
    public bool compare(object lhs, object rhs)
    {
        // etc.
    }
}

Le problème, c'est que vous avez indûment associé deux concepts :

1. Une façon de comparer deux éléments (quel élément doit passer en premier)
2. Une méthode de tri des éléments (c'est-à-dire tri rapide ou tri par fusion, etc.).

Dans le code ci-dessus, théoriquement, l'auteur de la méthode "compare" peut de manière rentrante dans la méthode "Sort" de la superclasse... même si, dans la pratique, ils n'auront jamais envie ou besoin de le faire.

Le prix à payer pour ce couplage inutile est qu'il est difficile de changer la superclasse et, dans la plupart des langages OO, impossible de la changer au moment de l'exécution.

L'autre méthode consiste à utiliser le modèle de conception "Stratégie" à la place :

interface IComparator
{
    bool compare(object lhs, object rhs);
}

class QuickSorter
{
    private readonly IComparator comparator;
    public QuickSorter(IComparator comparator)
    {
        this.comparator = comparator;
    }

    public void Sort(object[] items)
    {
        // usual code but call comparator.Compare();
    }
}

class NameComparator : IComparator
{
    bool compare(object lhs, object rhs)
    {
        // same code as before;
    }
}

Alors remarquez maintenant : Tout ce que nous avons, ce sont des interfaces, et des implémentations concrètes de ces interfaces. En pratique, vous n'avez pas vraiment besoin d'autre chose pour faire une conception OO de haut niveau.

Pour "cacher" le fait que nous avons implémenté le "tri des noms" en utilisant une classe "QuickSort" et un "NameComparator", nous pouvons toujours écrire une méthode de fabrique quelque part :

ISorter CreateNameSorter()
{
    return new QuickSorter(new NameComparator());
}

Tout Dès que vous avez une classe abstraite, vous pouvez le faire... même lorsqu'il existe une relation ré-entrante naturelle entre la classe de base et la classe dérivée, il est généralement utile de les rendre explicites.

Une dernière pensée : Tout ce que nous avons fait ci-dessus est de "composer" une fonction "NameSorting" en utilisant une fonction "QuickSort" et une fonction "NameComparison"... dans un langage de programmation fonctionnel, ce style de programmation devient encore plus naturel, avec moins de code.

Answer 4

Mes deux centimes :

Une interface définit essentiellement un contrat auquel toute classe d'implémentation doit adhérer (implémenter les membres de l'interface). Elle ne contient pas de code.

D'autre part, une classe abstraite peut contenir du code, et il peut y avoir certaines méthodes marquées comme abstraites qu'une classe héritière doit mettre en œuvre.

Les rares situations dans lesquelles j'ai utilisé des classes abstraites sont celles où j'ai une fonctionnalité par défaut que la classe héritière ne serait pas intéressée à surcharger, dans une classe de base abstraite, par exemple, dont héritent certaines classes spécialisées.

Exemple (très rudimentaire !) : considérons une classe de base appelée Customer qui possède des méthodes abstraites telles que CalculatePayment() , CalculateRewardPoints() et certaines méthodes non-abstraites comme GetName() , SavePaymentDetails() .

Des cours spécialisés comme RegularCustomer et GoldCustomer héritera de la Customer et implémentent leur propre classe de base CalculatePayment() y CalculateRewardPoints() mais en réutilisant la logique de la méthode GetName() y SavePaymentDetails() méthodes.

Vous pouvez ajouter plus de fonctionnalités à une classe abstraite (c'est-à-dire des méthodes non abstraites) sans affecter les classes enfant qui utilisaient une version plus ancienne. En revanche, l'ajout de méthodes à une interface affecterait toutes les classes qui l'implémentent, car elles devraient désormais implémenter les membres de l'interface nouvellement ajoutée.

Une classe abstraite avec tous les membres abstraits serait similaire à une interface.

Answer 5

Je sais que ce sujet est vieux comme le monde, mais quelqu'un d'autre pourrait bien tomber dessus un jour...

Les classes abstraites vous permettent de créer un modèle et de CONSTRUIRE (implémenter) les propriétés et les méthodes que vous souhaitez que TOUS ses descendants possèdent.

Une interface, quant à elle, vous permet seulement de déclarer que vous voulez que les propriétés et/ou les méthodes portant un nom donné existent dans toutes les classes qui l'implémentent - mais ne spécifie pas comment vous devez l'implémenter. En outre, une classe peut mettre en œuvre de NOMBREUSES interfaces, mais ne peut étendre qu'UNE seule classe abstraite. Une interface est davantage un outil architectural de haut niveau (ce qui devient plus clair si vous commencez à comprendre les modèles de conception) - une classe abstraite a un pied dans les deux camps et peut également effectuer une partie du sale boulot.

Pourquoi utiliser l'un plutôt que l'autre ? Le premier permet une plus béton définition des descendants - cette dernière permet une plus grande polymorphisme . Ce dernier point est important pour l'utilisateur final/codeur, qui peut utiliser ces informations pour mettre en œuvre l'A.P. I(nterface) dans une variété de combinaisons/formes pour répondre à leurs besoins.

Je pense que c'est le moment où j'ai eu une révélation : il faut penser aux interfaces moins du point de vue de l'auteur que de celui d'un codeur qui arrive plus tard dans la chaîne et qui ajoute l'implémentation à un projet, ou extension de une API.