C# – Interfaces

On nomme interface un contrat auquel les classes l'implémentant seront assujetties. Ce qu'on nomme l'héritage d'interfaces joue deux grandes rôles en POO :

Dans un langage supportant l'héritage multiple, donc dans un langage où une classe peut avoir plusieurs parents directs (comme C++). les interfaces sont d'abord et avant tout un schéma de conception. Techniquement, une interface est alors une classe abstraite n'offrant que des méthodes abstraites (et, en C++, un destructeur polymorphique)
Dans un langage ne supportant que l'héritage simple d'implémentation, donc dans un langage où une classe ne peut avoir avoir qu'un seul parent direct, outre la racine de la hiérarchie d'objets du langage (souvent une classe Object), l'héritage d'interfaces permet malgré tout de réaliser le polymorphisme selon plusieurs aspects (tout Dessinable peut être dessiné, par exemple, et tout Volant peut voler). Notez que dans cet article, qui porte principalement sur C#, je préfixerai les noms d'interfaces par un I majuscule (p. ex. : IVolant, IDessinable) comme c'est l'usage avec la plateforme .NET... bien que ce ne soit pas la meilleure idée du monde.

Un exemple simple d'utilisation d'interfaces avec C# serait :

using System;
using System.Collections.Generic;

List<IVolant> volants = new () { new Rumeur(), new Oiseau(), new Couteau() };
foreach (IVolant v in volants)
{
   v.Décoller();
   v.Atterrir();
}

interface IVolant
{
   void Décoller();
   void Atterrir();
}
class Rumeur : IVolant
{
   public void Décoller()
   {
      Console.WriteLine("Cette rumeur décolle!");
   }
   public void Atterrir()
   {
      Console.WriteLine("Cette rumeur tombe à plat...");
   }
}
class Oiseau : IVolant
{
   public void Décoller()
   {
      Console.WriteLine("Pit pit, je décolle");
   }
   public void Atterrir()
   {
      Console.WriteLine("Pit pit, j'atterris!");
   }
}
class Couteau : IVolant
{
   public void Décoller()
   {
      Console.WriteLine("Les couteaux volent bas...");
   }
   public void Atterrir()
   {
      Console.WriteLine("... c'est bien connu!");
   }
}

Dans cet exemple, le polymorphisme est appliqué à travers l'interface IVolant implémentée par trois classes sans autre « parent » commun.

Interfaces, polymorphisme et particularités de C#

Un réflexe que plusieurs ont (votre humble serviteur inclus) est de voir les interfaces dans un langage comme C# sous la forme de classes abstraites, soumises à des règles connexes, mais il se trouve que C# offre un traitement quelque peu différent aux interfaces de celui que ce langage réserve, à titre d'exemple, aux classes abstraites.

Ce qui suit montre un exemple de telles différences. Examinons tout d'abord un héritage en deux temps, avec MachinAbstrait une classe abstraite exposant un service abstrait F, et Machin son descendant direct implémentant le service F :

Exemple avec classe abstraite

using System;
namespace z
{
   abstract class MachinAbstrait
   {
      public abstract void F();
   }
   class Machin : MachinAbstrait
   {
      public override void F()
      {
         Console.WriteLine("Machin");
      }
   }
   class Program
   {
      static void Main(string[] args)
      {
         MachinAbstrait p = new Machin();
         p.F();
      }
   }
}

Remarquez la combinaison des mots clés :

La classe MachinAbstrait a un service abstrait, F, ce qui impose de qualifier la classe elle-même d'abstraite
L'enfant Machin cherche à implémenter un service de même signature que la méthode F de MachinAbstrait. Les règles de C# font en sorte que Machin doive qualifier F par override s'il souhaite spécialiser ce service ou par new s'il souhaite le masquer
Cependant, bien que le langage permette d'apposer la qualification new à Machin.F, le faire poserait des problèmes par la suite (Machin serait abstrait car cette classe n'aurait pas encore implémenté sa propre version de la méthode abstraite F dans MachinAbstrait). La qualification override est donc celle dont nous avons besoin ici

Examinons maintenant un héritage en trois temps, avec MachinAbstrait une classe abstraite exposant un service abstrait F, Machin son descendant direct implémentant le service F en question et Truc, un descendant de Machin spécialisant F un peu plus :

Exemple avec classe abstraite

using System;
namespace z
{
   abstract class MachinAbstrait
   {
      public abstract void F();
   }
   class Machin : MachinAbstrait
   {
      public override void F()
      {
         Console.WriteLine("Machin");
      }
   }
   class Truc : Machin
   {
      public override void F()
      {
         Console.WriteLine("Truc");
      }
   }  
   class Program
   {
      static void Main(string[] args)
      {
         MachinAbstrait p = new Truc();
         p.F();
      }
   }
}

Ce qui doit être remarqué ici est que dans Truc, pour proposer une méthode F, deux qualifications sont possibles, soit new (pour masquer celle du parent dans l'enfant) et override (pour spécialiser celle du parent dans l'enfant).

Examinons maintenant un autre design en deux temps, avec IMachin une interface exposant un service abstrait F, Machin son descendant direct implémentant le service F en question :

Exemple avec classe abstraite

using System;
namespace z
{
   interface IMachin
   {
      void F();
   }
   class Machin : IMachin
   {
      public void F()
      {
         Console.WriteLine("Machin");
      }
   }
   class Program
   {
      static void Main(string[] args)
      {
         IMachin p = new Machin();
         p.F();
      }
   }
}

Remarquez que dans ce cas-ci, le fait pour Machin d'implémenter IMachin lui impose la contrainte d'écrire la méthode F() de même signature que celle déclarée dans IMachin. Ceci impose d'ailleurs à Machin la contrainte (superflue) que qualifier F de public parce que les méthodes abstraites d'une interface sont elles-mêmes publiques (en C++ par exemple, cet irritant n'existe pas, et il est normal pour une interface d'exposer un service public alors que ses enfants implémentent le service de manière privée; ceci a pour effet de forcer les clients à solliciter les services à travers l'interface, tout simplement).

Notez par ailleurs que dans Machin, la méthode F n'est pas qualifiée override, même si utiliser un Machin comme un IMachin permet le polymorphisme sur la méthode F. Cette subtilité met de l'avant une différence clé du modèle de C# avec celui de C++, différence qui amène des surprises (voir plus bas).

Examinons enfin une version en trois temps de ce design, avec IMachin une interface exposant un service abstrait F, Machin son descendant direct implémentant le service F en question et Truc, un descendant de Machin spécialisant F un peu plus :

Exemple avec classe abstraite

using System;
namespace z
{
   interface IMachin
   {
      void F();
   }
   class Machin : IMachin
   {
      public virtual void F()
      {
         Console.WriteLine("Machin");
      }
   }
   class Truc : Machin
   {
      public override void F()
      {
         Console.WriteLine("Truc");
      }
   }  
   class Program
   {
      static void Main(string[] args)
      {
         IMachin p = new Truc();
         p.F();
      }
   }
}

Remarquez que cette fois, la méthode Machin.F a été qualifiée de virtual. En effet, sans ajouter ce mot, la méthode F n'était pas considérée par un compilateur C# comme étant polymorphique à travers Machin. Puisque nous souhaitions spécialiser un peu plus le comportement de IMachin.F dans Truc, il nous a fallu qualifier Machin.F de virtual et Truc.F avec la mention override.

Constat : en C#, le polymorphisme qui prend racine à travers une classe est transitif, alors que celui qui prend racine dans une interface ne l'est pas de prime abord, mais cette transitivité peut étre provoquée par une forme d'enchaînement; comme on peut le constater avec le dernier exemple, une fois Machin.F() qualifiée virtual et Truc.F qualifiée override, l'appel de F à partir un IMachin tel que p est bel et bien polymorphique.

Il n'existe pas de langage simple...