The Richter Replacement Principle of the Five Object Oriented Principles of PHP of LSP Detailed Explanation

In this paper, the Richter Replacement Principle (LSP), one of the five object-oriented principles of PHP, is described with examples. Share it for your reference, as follows:

The replacement principle was put forward by Ms. Liskov of MIT Computer Science Laboratory in an article at OOPSLA Conference in 1987, which mainly expounded one principle about inheritance, so it was called Richter replacement principle.

In 2002, Robert C. Martin published a book entitled "Agile Software Development Principles Patterns and Practices", in which he finally simplified the Richter substitution principle into one sentence: "Subtypes must be substitutable for their base types" (subclasses must be able to replace their base classes.)

1. Content of LSP

The Richter Replacement Principle (Liskov Substitution Principle, LSP) is defined as follows: Because the inheritance in object-oriented programming technology is too simple in concrete programming, in the design and programming implementation of many systems, we do not seriously and rationally think about whether the inheritance relationship between various classes in the application system is appropriate, and whether the derived classes can correctly rewrite some methods in their base classes. Therefore, the phenomenon of abusing inheritance or wrongly inheriting often occurs, which brings a lot of troubles to the later maintenance of the system. This requires us to have a design principle to follow, which is the replacement principle.

LSP states that subclass types must be able to replace their parent type and appear wherever the parent class can. It guides us how to inherit and derive correctly and reuse code reasonably. This principle holds that if a software entity uses a base class, then 1 must be applicable to its subclasses, and this does not detect the difference between base class objects and subclass objects at all. Think 1, is it similar to the concept of polymorphism?

2. LSP is designed primarily for inheritance

Because inheritance and derivation are one of the main features of OOP, it can reduce the repeated programming implementation of code, thus realizing the code reuse in the system. But how to design inheritance correctly and apply inheritance mechanism reasonably?

This is the problem that LSP is trying to solve:

How to design inheritance correctly.

How to get the best inheritance level?

How to avoid the designed class hierarchy falling into a situation that does not conform to OCP principles?

How to abide by the design principle?

1) The methods of the parent class should be implemented or overridden in the child class, and the derived class should only implement the methods declared in its abstract class, and should not give redundant method definitions or implementations

2) In the client program, only parent objects should be used instead of subclass objects directly, so that runtime binding (dynamic polymorphism) can be realized.

If A and B violate the design of LSP, the common practice is to create a new abstract class C as a superclass of the two concrete classes, and transfer the common behavior of A and B to C, so as to solve the problem that the behavior of A and B is incomplete.

However, PHP's support for LSP is not good, and it lacks the concept of upward transformation, which can only be realized by some tortuous methods. This principle will not be elaborated here.

The following is a cache implementation interface, using abstract classes as base classes, following LSP to achieve its design.

<?php
abstract class Cache
{
 /**
  *  Settings 1 Cache variables 
  * @param $key  Cache key
  * @param $value  Cache content 
  * @param int $expire  Cache time ( Seconds )
  * @return boolean  Whether the cache succeeded 
  */
 public abstract function set($key, $value, $expire = 60);
 /**
  *  Get 1 Cached 
  * @param $key  Cache key
  * @return mixed  Cache content 
  */
 public abstract function get($key);
 /**
  *  Delete 1 Cached variables 
  * @param $key  Cache key
  * @return boolean  Is the deletion successful 
  */
 public abstract function del($key);
 /**
  *  Delete all cached variables 
  * @return boolean  Is the deletion successful 
  */
 public abstract function delAll();
 /**
  *  Detect whether there is a corresponding cache 
  * @param $key  Cache key
  * @return boolean  Does it exist 
  */
 public abstract function has($key);
}

If you need to implement caching under various mechanisms such as files, memcache, accelerator, etc., you only need to inherit this abstract class and implement its abstract methods.

The code in LSP is not only functional, but also named sign meaning. Try to think: White horses can be replaced by horses, while cattle are also used as labor force. Can they be replaced by horses? High-heeled shoes are also shoes. Is it acceptable for men to wear high-heeled shoes?

For more readers interested in PHP related content, please check the topics on this site: "Introduction to php Object-Oriented Programming", "Encyclopedia of PHP Array (Array) Operation Skills", "Introduction to PHP Basic Syntax", "Summary of PHP Operation and Operator Usage", "Summary of php String (string) Usage", "Introduction to php+mysql Database Operation" and "Summary of php Common Database Operation Skills"

I hope this paper is helpful to everyone's PHP programming.