Faut-il utiliser les interfaces ou les classes abstraites ? (et comment choisir entre les deux)

Dans cet article, je vais vous expliquer comment choisir entre les interfaces et les classes abstraites pour écrire du code en C#.
Cette décision est importante car elle a des conséquences sur le code et sur la facilité d’utilisation par la suite.

Comme tout développeur, a un moment donné, vous avez du vous poser la question : est-ce que je dois créer plutôt une interface ou bien une classe abstraite pour ce nouveau type ? Comment faire pour choisir entre les deux ? Quelles sont les conséquences si je me trompe ?
Rassurez-vous, nous allons parler de tout ça dans cet article.

Je rencontre souvent des débutants qui utilisent des interfaces un peu partout. C’est à la mode, alors ils en mettent un peu partout dans le code, même quand ça n’est pas nécessaire. L’exemple le plus classique que je vois souvent : créer une interface pour une seule classe. Et quand je demande pourquoi le développeur a fait ce choix, j’ai souvent des réponses un peu floues.

Qu’est ce qu’une interface en C# ?

En C#, une interface permet de décrire un « contrat ».
Elle ne peut contenir que des méthodes, des propriétés ou des événements. Les membres d’une interface sont forcément publiques.

Une classe peut alors « implémenter » une interface. C’est-à-dire qu’elle s’engage à implémenter les méthodes décrites dans l’interface.

En C#, une classe peut implémenter plusieurs interfaces différentes.

Qu’est ce qu’une classe abstraite en C# ?

Une classe abstraite est une classe partiellement définie. Elle comporte, au moins, une méthode abstraite qui n’a pas de corps (pas de code).

Une classe abstraite peut contenir tous les éléments d’une classe « normale » : champs (variables), événements, propriétés, méthodes…

Par contre, une classe abstraite peut comporter un état. Comme elle peut contenir des membres (variables), il est possible d’affecter un état à cette classe.

En C#, une classe peut hériter que d’une seule autre classe.

Quelles sont les différences entre les interfaces et les classes abstraites en C# ?

Comme nous l’avons vu dans les paragraphes précédents, les classes abstraites sont des classes partiellement définies.

Par rapport à une interface, une classe abstraite peut avoir :

• un état (des champs – les variables)
• un comportement (du code)

Une classe pourra :

• Implémenter une ou plusieurs interfaces
• Hériter d’une seule classe (abstraite ou non)

Comment choisir entre interface ou classe abstraite ?

Une classe abstraite est généralement utilisée pour construire des classes similaires. Elles auront toutes une implémentation en commun, celle de la classe abstraite.

Une interface est généralement utilisée pour définir des capacités (le « contrat »), même si les classes n’ont pas grand chose en commun.

Pour vous aider, posez-vous les questions suivantes : Est-ce que mes classes auront un comportement commun ?

Exemple dans .NET

Dans le framework .NET, vous avez des dizaines de classes qui implémentent IEnumerable. Cela vous permet d’utiliser foreach sur une collection d’objets.

Si vous y regardez de plus prêt, les classes qui implémentent IEnumerable n’ont parfois rien en commun. Par contre, vous pouvez énumérer des collections d’entiers ou bien des collections de chaines.

Est-ce que ces classes ont un comportement commun ? La réponse est Non. Les entiers et les chaines n’ont pas grand chose en commun (en tout cas du point de vue énumération).

Pour les classes abstraites, je vous propose l’exemple suivant. Nous avons une classe de base AbstractLogger. Celle-ci contient des méthodes « Info », « Error », « Warn »… Voici le code correspondant :

public abstract class AbstractLogger
{
    public void Info(string msg)
    {
        WriteMessage("INFO : " + msg);
    }

    public void Error(string msg)
    {
        WriteMessage("ERROR : " + msg);
    }

    public void Warn(string msg)
    {
        WriteMessage("WARN : " + msg);
    }

    public abstract void WriteMessage(string text);
}

Comme nous le voyons, la classe AbstractLogger propose une implémentation partielle.
Si nous souhaitons créer un logger pour la console, nous pourrions écrire quelque chose comme ça :

public class ConsoleLogger : AbstractLogger
{
    public override void WriteMessage(string text)
    {
        Console.WriteLine(text);
    }
}

Nous pourrions bien sûr créer une classe pour écrire dans un fichier ou bien une autre pour écrire en base de données. Toutes ces classes partageraient le même comportement par défaut (les méthodes Info, Warn et Error).

Est-ce que ces classes ont un comportement commun ? La réponse est Oui car toutes les classes partagent les mêmes méthodes de formatage (Info, Error, Warn).

Si vous souhaitez aller plus loin, je vous invite à découvrir le programme de la formation Apprendre CSharp en 24 heures chrono.