Analyse pratique du principe de substitution PHP Liskov

Cette fois, je vais vous apporter une analyse pratique du principe de substitution PHP Liskov. Quelles sont les précautions lors de l'utilisation du principe de substitution PHP Liskov. Voici des cas pratiques, jetons un coup d'oeil.

Le principe de substitution a été proposé par Mme Liskov du laboratoire d'informatique du MIT dans un article lors de la conférence OOPSLA en 1987. Il développe principalement certains principes liés à l'héritage, c'est pourquoi on l'appelle le principe de substitution de Liskov.

En 2002, Robert C.Martin a publié un livre intitulé "Agile Software Development Principles Patterns and Practices", dans lequel il a finalement simplifié le principe de substitution de Liskov en une phrase : "Les sous-types doivent être substituables à leurs types de base" (Les sous-classes doivent pouvoir être remplacées par leurs types de base.)

1 Contenu du LSP

Principe de substitution de Liskov, la définition et l'idée principale du LSP. ) sont les suivants : Étant donné que l'héritage dans la technologie de programmation orientée objet est trop simple dans une programmation spécifique, dans la conception et la mise en œuvre de la programmation de nombreux systèmes, nous n'avons pas sérieusement et rationnellement examiné si la relation d'héritage entre les différentes classes dans le système d'application est approprié, si la classe dérivée peut correctement remplacer certaines méthodes de sa classe de base, etc. Par conséquent, des abus d'héritage ou des héritages incorrects se produisent souvent, ce qui entraîne beaucoup de problèmes lors de la maintenance ultérieure du système. Cela nous oblige à avoir un principe de conception à suivre, qui est le principe de remplacement.

LSP souligne que les types de sous-classes doivent pouvoir remplacer leurs types parents et apparaître partout où la classe parent peut apparaître. Il nous explique comment hériter et dériver correctement et réutiliser le code de manière raisonnable. Ce principe veut que si une entité logicielle utilise une classe de base, elle doit s'appliquer à ses sous-classes, et cela ne peut pas du tout détecter la différence entre les objets de classe de base et les objets de sous-classe. Pensez-y, est-ce similaire au concept de polymorphisme ?

2. LSP est principalement basé sur le principe de conception de l'héritage

Parce que l'héritage et la dérivation sont une caractéristique majeure de la POO, ils peuvent réduire la mise en œuvre répétée du code, réalisant ainsi la réutilisation du code du système dans l'application, mais comment concevoir correctement l'héritage et appliquer rationnellement le mécanisme d'héritage ?

C'est le problème que LSP veut résoudre :

Comment concevoir correctement l'héritage ?

Comment obtenir la meilleure hiérarchie successorale ?

Comment éviter que la hiérarchie de classes conçue ne tombe dans une situation non conforme aux principes de l'OCP ?

Alors comment respecter ce principe de conception ?

1) Toutes les méthodes de la classe parent doivent être implémentées ou réécrites dans la sous-classe, et la classe dérivée n'implémente que les méthodes déclarées dans sa classe abstraite et ne doit pas donner de définitions ou d'implémentations de méthodes redondantes

2) Seuls les objets de classe parent doivent être utilisés dans les programmes clients au lieu des objets de sous-classe directement, afin que la liaison d'exécution (polymorphisme dynamique) puisse être réalisée.

Si les classes A et B violent la conception de LSP, l'approche habituelle consiste à créer une nouvelle classe abstraite C en tant que superclasse des deux classes concrètes, et à déplacer les comportements communs de A et B vers C , ainsi résoudre le problème selon lequel les comportements de A et B ne sont pas complètement cohérents.

Cependant, la prise en charge de PHP pour LSP n'est pas bonne. Il manque des concepts tels que la transformation ascendante et ne peut être réalisé que par certaines méthodes tortueuses. Ce principe ne sera pas détaillé ici.

Ce qui suit est une interface d'implémentation de cache, utilisant des classes abstraites comme classes de base et suivant LSP pour implémenter sa conception.

<?php
abstract class Cache
{
 /**
  * 设置一个缓存变量
  * @param $key 缓存key
  * @param $value 缓存内容
  * @param int $expire 缓存时间(秒)
  * @return boolean 是否缓存成功
  */
 public abstract function set($key, $value, $expire = 60);
 /**
  * 获取一个已经缓存的
  * @param $key 缓存key
  * @return mixed 缓存内容
  */
 public abstract function get($key);
 /**
  * 删除一个已经缓存的变量
  * @param $key 缓存key
  * @return boolean 是否删除成功
  */
 public abstract function del($key);
 /**
  * 删除全部缓存变量
  * @return boolean 是否删除成功
  */
 public abstract function delAll();
 /**
  * 检测是否存在对应的缓存
  * @param $key 缓存key
  * @return boolean 是否存在
  */
 public abstract function has($key);
}

Si vous devez maintenant implémenter la mise en cache sous divers mécanismes tels que les fichiers, le memcache, l'accélérateur, etc., il vous suffit d'hériter de cette classe abstraite et d'implémenter ses méthodes abstraites.

Je pense que vous maîtrisez la méthode après avoir lu le cas dans cet article. Pour des informations plus intéressantes, veuillez prêter attention aux autres articles connexes sur le site Web chinois de php !

Lecture recommandée :

Explication détaillée des étapes pour télécharger plusieurs images avec Bootstrap+PHP

PHP+Session vers éviter les étapes répétées de soumission du formulaire Explication détaillée

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!