Principe de substitution de Liskov : garantir la fiabilité des hiérarchies de classe

Parmi les principes fondamentaux qui guident les développeurs vers ce but, il y a le principe de substitution de Liskov (LSP). Conçu par Barbara Liskov en 1987, le LSP est le troisième pilier des cinq principes SOLID pour la conception de logiciels, et il répond à une question critique : lorsque vous créez une sous-classe qui hérite d'une classe parent, pouvez-vous remplacer en toute sécurité toute instance du parent par une instance de l'enfant sans rompre le programme ? La réponse de principe est une réponse définitive - - - mais seulement si la sous-classe respecte le contrat défini par le parent. Cet article explore en profondeur le principe de substitution de Liskov, fournissant des définitions claires, des exemples pratiques et des stratégies pour assurer que vos hiérarchies de classe restent fiables et flexibles.

Quel est le principe de la substitution de Liskov?

Le principe de substitution de Liskov stipule que les objets d'une superclasse doivent être remplaçables par des objets de ses sous-classes sans affecter la justesse du programme. Autrement dit, si une fonction ou méthode est conçue pour fonctionner avec un type de base, elle doit aussi fonctionner avec n'importe quel type dérivé sans nécessiter de modification ou produire des effets secondaires inattendus. Barbara Liskov a d'abord articulé cette idée dans son discours de 1987 à la Conférence sur les systèmes de programmation orientés objet, langues et applications (OOPSLA), et elle est depuis devenue une pierre angulaire de la conception orientée objet.

Il ne suffit pas qu'une sous-classe ait les mêmes signatures de méthode que son parent (conformité syntaxique); la sous-classe doit également honorer les intentions et les contraintes de la classe parent. Si une sous-classe modifie le comportement fondamental d'une méthode parent – par exemple, en jetant une exception que le parent ne lance jamais, en renvoyant une valeur qui viole le contrat parent, ou en exigeant des conditions plus strictes – alors la substitution n'est pas sûre, et le design viole la LSP.

Définition formelle et historique

Barbara Liskov , la définition formelle originale est la suivante:

-Si pour chaque objet de type S il y a un objet de type T de type [₂ de type T tel que pour tous les programmes P définis en termes de T, le comportement de P est inchangé lorsque o[₁ est substitué à o_2[, alors S est un sous-type de T.

Cette définition souligne qu'un sous-type (S) doit être substituable à son supertype (T) dans tout programme (P) écrit en termes de T. Le comportement observable du programme doit être préservé. Ce concept est étroitement lié à la méthodologie de conception par contrat (DbC), lancée par Bertrand Meyer, où chaque méthode a des conditions préalables explicites (ce qui doit être vrai avant que la méthode ne tourne) et des conditions post-conditions (ce qui doit être vrai après).

Pour plus de détails, voir l'original Liskov et Wing paper qui formalisaient le concept. De plus, l'article Wikipedia sur LSP fournit un bon aperçu.

Pourquoi le LSP est-il important?

L'adhésion au LSP apporte plusieurs avantages critiques aux systèmes orientés objet :

• Reliabilité et exactitude:[ Le code qui utilise un type de base peut faire confiance à toute sous-classe qui se comportera selon le contrat de type de base. Cela empêche les bugs subtils qui se produisent quand une sous-classe introduit un comportement inattendu.
• Polymorphisme: Le polymorphisme est la capacité de traiter des objets de différentes classes par une interface commune. Sans LSP, le polymorphisme devient dangereux parce qu'il peut produire des résultats incorrects.
• Maintenabilité et extensibilité:[ Lorsque des violations de LSP sont évitées, l'ajout de nouvelles sous-classes ne nécessite pas de modifier le code existant qui dépend du type de base. Ceci s'harmonise avec le principe ouvert/fermé (OCP) – les entités logicielles devraient être ouvertes pour l'extension mais fermées pour la modification.
• Testabilité:[ Les tests unitaires écrits sur une classe de base peuvent être réutilisés pour valider les sous-classes. Si une sous-classe viole la LSP, ces tests échoueront, révélant l'incohérence tôt.

Par exemple, dans un système de traitement des paiements, si vous avez une classe de base avec une méthode , vous attendez toutes les sous-classes (par exemple , ) pour traiter les paiements sans erreurs ou effets secondaires que la classe de base ne prévoit pas. Les violations ici peuvent entraîner une perte de revenus ou des données corrompues.

Violations communes du principe de substitution de Liskov

La reconnaissance des violations des LSP est la première étape vers leur correction. Voici quelques modèles typiques qui rompent le principe :

Renforcement des conditions préalables

Si une méthode de classe de base s'attend à un paramètre entier, ajouter une condition dans la sous-classe que l'entier doit être positif (alors que la classe de base accepte tout entier) renforce la condition préalable. Les clients qui ont passé un nombre négatif à la classe de base échoueraient maintenant avec la sous-classe. Exemple:

// Base class
class UserService {
 public void assignRole(int userId) { ... }
}
// Subclass violation
class AdminService extends UserService {
 @Override
 public void assignRole(int userId) {
 if (userId <= 0) throw new IllegalArgumentException("Invalid ID");
 ...
 }
}

Faiblessement des conditions post-conditions

Si la classe de base garantit une certaine valeur de retour ou un effet secondaire, une sous-classe qui réduit cette garantie viole le LSP. Par exemple, une méthode de classe de base peut toujours renvoyer une chaîne non-nulle; une sous-classe qui retourne affaiblit dans certains cas la condition post.

Nouvelles exceptions

Les sous-classes ne devraient pas donner d'exceptions que la classe de base ne lance pas (sauf si ces exceptions sont des sous-classes d'exceptions déjà autorisées). Si les clients de la classe de base ne capturent que , et qu'une sous-classe lance un , la substitution causera des accidents inattendus.

Suppression ou dépassement de méthodes qui devraient être héritées

Si une sous-classe remplace une méthode pour ne rien faire (corps vide) ou pour lancer une , cela constitue une violation claire. La sous-classe ne se comporte pas comme la classe de base prévue.

Exemple classique : Rectangle, place et piège de la zone

L'exemple le plus cité de violation de LSP implique des formes géométriques. Beaucoup de manuels commencent par une classe qui a et méthodes, puis créent une sous-classe qui les outrepasse pour imposer la largeur == hauteur. Voici le problème:

// Base class
class Rectangle {
 protected int width, height;
 public void setWidth(int w) { width = w; }
 public void setHeight(int h) { height = h; }
 public int getArea() { return width * height; }
}

// Subclass violation
class Square extends Rectangle {
 @Override
 public void setWidth(int w) {
 width = height = w;
 }
 @Override
 public void setHeight(int h) {
 width = height = h;
 }
}

Considérez maintenant une fonction qui fonctionne avec un :

void resize(Rectangle r) {
 r.setWidth(5);
 r.setHeight(10);
 assert r.getArea() == 50; // Expect 50
}

Lorsque la méthode passe, elle établit la largeur à 5 et la hauteur à 10 – mais les carrés sont surbordés , la largeur à 10 est ainsi réglée, de sorte que le carré se termine par la largeur=10, la hauteur=10, la surface=100. L'affirmation échoue. n'est pas substituable pour parce qu'elle change la condition post-condition: après et , une surface rectangle=50, mais une surface carrée=100.

La correction:[ Évitez d'hériter de . Concevez plutôt une classe abstraite avec une méthode commune , et avez à la fois et mettre en œuvre indépendamment. Sinon, utilisez la composition: un carré peut être un rectangle avec des côtés égaux, mais exposer les setts qui rompent l'invariant est la vraie question. Le principe est souvent résumé comme ─ Ne rompez pas le contrat.

abstract class PaymentGateway {
 public abstract void charge(double amount);
 public void refund(double amount) { /* default implementation */ }
}