Cet article présente principalement le principe de substitution de Liskov (LSP) des cinq principes orientés objet de PHP. Il analyse plus en détail le concept et le principe du principe de substitution de Liskov (LSP) et analyse le principe de substitution de Liskov de PHP dans. sous forme d'exemples. Pour une utilisation simple de (LSP), les amis qui en ont besoin peuvent se référer à
Cet article explique le principe de substitution de Liskov (LSP), les cinq grands principes du PHP orienté objet, avec des exemples. . Partagez-le avec tout le monde pour référence. Les détails sont les suivants :
Le principe de remplacement 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 sur l'héritage, c'est ce qu'on appelle le principe de substitution de Richter.
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. Le contenu du LSP
Principe de substitution de Liskov, LSP) la définition et l'idée principale sont les suivantes. : Parce 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 ne réfléchissons pas sérieusement et rationnellement à chaque classe du système d'application si la relation d'héritage entre elles est appropriée, si la classe dérivée peut remplacer correctement 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 nécessite que nous ayons 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 cache mémoire, l'accélérateur, etc., il vous suffit d'hériter de cette classe abstraite et implémenter ses méthodes abstraites.
Le code en LSP n'est pas seulement la fonction, mais aussi la signification de la langue des signes. Pensez-y : le cheval blanc peut remplacer le cheval, et le bœuf sert aussi de main d'œuvre, peut-il remplacer le cheval ? Les talons hauts sont aussi des chaussures. Est-il acceptable pour les hommes de porter des talons hauts ?
Recommandations associées :
Explication détaillée du principe ouvert-fermé (OCP) des cinq principes orientés objet de PHP
Structure d'héritage de la fonction orientée objet PHP
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!