.Net principes SOLID : Principe de substitution Liskov

Les principes SOLID font partie des principes « de base » de l’informatique qui permettent de faire du code propre, maintenable et évolutif. En effet, cet acronyme décrit 5 principes distincts, que nous allons analyser au fur et à mesure de 5 articles distincts.

Nous continuons notre série avec le L, pour « Liskov Substitution Principle« .

Definition

Si Φ(x) est une propriété démontrable pour tout objet x de type T, alors Φ(y) est vraie pour tout objet y de type S tel que S est un sous-type de T.

Ce principe indique que tous objets d’une classe mère peuvent être remplacés par une classe fille sans nuire à l’intégrité de l’application.

Tout paraît si théorique ? Passons alors à la pratique.

Exemple : Un carré est un rectangle

L’exemple le plus simple pour illustrer ce genre de souci est de casser avec une exception. Prenons le code suivant comme base de travail :

public abstract class Animal
{
   public void Marcher();
}

public class Chien : Animal
{
   public override void Marcher() {  Console.WriteLine("Le chien marche"); }
}

public class Promeneur
{
    public void Promener(Animal a)
    {
         a.Marcher();
    }
}

Ici, la classe Promeneur fait marcher un animal. On peut lui spécifier n’importe quelle classe qui hérite de la classe Animal. Donc, si on appelle la méthode Promener avec une instance de Chien, c’est valide et ça va fonctionner.

Ici, on a définit un comportement commun dans la classe Animal qui est marché. Mais que se passe-t-il si nous overridons cette méthode ?

public class Poisson : Animal
{
   public override void Marcher() { throw new InvalidOperationException("Un poisson, ça nage, ça ne marche pas ... !"); }
}

Au niveau objet, cette approche est valide (mais désastreuse). Au niveau « logique » aussi : un poisson est un animal après tout ! Sauf que l’action de « marcher » ne correspond pas ici à la fonctionnalité de la classe mère, donc, exception. On n’a pas respecté le principe, car une classe plus spécifique casse le fonctionnement de la classe de base.

Maintenant, imaginez une classe qui traite des règles de calculs diverses et variées, et chaque règle est implémentée dans une classe héritant de la classe mère Regle. Puis, une classe de calcul spécifique, dans un cas bien précis renvoie 0, qui est une valeur invalide car le moteur divise généralement par le résultat de ce calcul. DivideByZeroException …

Ça peut aller loin ! C’est juste ça Liskov Substitution Principle : assurez-vous que vos classes filles ne cassent pas le programme quand vous les passer à une méthode qui attendent une classe spécifique.