The Liskov Substitution Principle

Core points

• Liskov Substitution Principle (LSP) is a key concept in object-oriented programming that ensures that subclasses can replace their base class abstractions without breaking the contract with client code. It maintains the integrity of the system design and is crucial to the reusability of the code.
• When overwriting methods in subclasses, certain requirements must be met: their signature must match the signature of the parent class; their prerequisites must be the same or weaker; their postconditions must be the same or stronger; exceptions (if any) must be the same as the exception type thrown by the parent class.
• LSP violations can lead to unstoppable behavior and errors that are difficult to track. It also makes the code harder to maintain and extend, because the assumption that a subclass can replace its superclass is no longer true.
• Method rewriting does not always violate LSP. However, if the rewritten method changes the behavior of the original method in a way that is not expected in the superclass contract, it will violate the LSP.
• To ensure that the code complies with LSP, it is best to create subclasses that only extend (rather than rewrite) their base class functions. Additionally, using composition instead of inheritance and implementing interfaces can help create derived classes without breaking the abstraction of conditions imposed by LSP.

Fictional Scene: Hacker and Matrix

The following conversation comes from a cut scene from the Matrix trilogy:

Merpheus: Neo, I'm in the matrix now. Sorry to tell you this bad news, but our Agent Tracking PHP program needs a quick update. It currently uses PDO's query() method (with string) to get the state of all matrix agents from our database, but we need to use preprocessing queries instead.

Neo: Sounds good, Morpheus. Can I get a copy of the program?

Merphes: No problem. Clone our repository and check out the AgentMapper.php and index.php files.

(Neo executes some Git commands, and the following code appears in front of him)

<?php namespace ModelMapper;

class AgentMapper
{
    protected $_adapter;
    protected $_table = "agents";

    public function __construct(PDO $adapter) {
        $this->_adapter = $adapter;
    }

    public function findAll() {
        try {
            return $this->_adapter->query("SELECT * FROM " . $this->_table, PDO::FETCH_OBJ);
        }
        catch (Exception $e) {
            return array();
        }
    }   
}

<?php use ModelMapperAgentMapper;

// 一个 PSR-0 兼容的类加载器
require_once __DIR__ . "/Autoloader.php";

$autoloader = new Autoloader();
$autoloader->register();

$adapter = new PDO("mysql:dbname=Nebuchadnezzar", "morpheus", "aa26d7c557296a4e8d49b42c8615233a3443036d");

$agentMapper = new AgentMapper($adapter);
$agents = $agentMapper->findAll();

foreach ($agents as $agent) {
    echo "Name: " . $agent->name .  " - Status: " . $agent->status . "<br>";
}

Nio: Morpheus, I just got the documents. I subclassed PDO and override its query() method so that it can use preprocessed queries. Due to my superpowers, I should be able to finish this job very quickly. keep Calm.

(The sound of the computer keyboard echoes in the air)

Nio: Morpheus, the subclass is ready for testing. Check it anytime.

(Murphys searched quickly on his laptop and saw the following class)

<?php namespace LibraryDatabase;

class PdoAdapter extends PDO
{
    protected $_statement;

    public function __construct($dsn, $username = null, $password = null, array $driverOptions = array()) {
        // 检查是否传递了有效的 DSN
        if (!is_string($dsn) || empty($dsn)) {
            throw new InvalidArgumentException("The DSN must be a non-empty string.");
        }
        try {
            // 尝试创建一个有效的 PDO 对象并设置一些属性。
            parent::__construct($dsn, $username, $password, $driverOptions);
            $this->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
            $this->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
        }
        catch (PDOException $e) {
            throw new RunTimeException($e->getMessage());
        }
    }

    public function query($sql, array $parameters = array())
    {
        try {
           $this->_statement = $this->prepare($sql);
           $this->_statement->execute($parameters);
           return $this->_statement->fetchAll(PDO::FETCH_OBJ);        
        }
        catch (PDOException $e) {
            throw new RunTimeException($e->getMessage());
        }
    }
}

Merphes: The adapter looks good. I'll try it right away to see if our agent mapper is able to track active agents that travel through the matrix. Good luck to me.

(Murphys hesitated for a moment, running the previous index.php file, this time using Neo's masterpiece PdoAdapter class. Then, a scream!)

Merpheus: Neo, I believe you are the "savior"! But there was a terrible fatal error on my face, and the news was as follows:

<code>Catchable fatal error: Argument 2 passed to LibraryDatabasePdoAdapter::query() must be an array, integer given, called in path/to/AgentMapper on line (who cares?)</code>

(Another scream)

Neo: What's wrong? ! What went wrong? ! (More Screams)

Merphes: I really don't know. Oh, Agent Smith is coming to catch me now! (The communication was suddenly interrupted. The long silence ended the conversation, suggesting that Morpheus was caught off guard and was seriously injured by Agent Smith.)

LSP does not represent lazy, stupid programmers

Needless to say, the above dialogue is fictional, but the problem is undoubtedly true. If Neo had learned only one or two pieces of knowledge about the Liskov Substitution Principle (LSP) like a hacker he once was as famous as he once was, Agent Smith could be traced immediately. Most importantly, Morpheus is protected from the malice of the agent. It was such a pity for him. However, in many cases, PHP developers think about LSP almost the same as Neo's previous opinion: LSP is nothing but a purist theoretical principle that has little application in practice. But they went the wrong way. Even though the formal definition of LSP is dazzling (including me), its core is to avoid a hierarchy of unclearly defined classes where descendants behave very differently from base class abstractions that use the same contract. Simply put, LSP stipulates that when rewriting methods in subclasses, the following requirements must be met:

1. Its signature must match the signature of the parent class
2. The prerequisites (what accepts) must be the same or weaker
3. Their post-conditions (what is expected) must be the same or stronger
4. Exception (if any) must be the same as the exception type thrown by the parent class

Now, feel free to read the list above again (don't worry, I'll wait) and you hope to understand why this makes sense. Going back to the example, Neo's fatal error simply fails to keep the method signature the same, thus breaking the contract with the client code. To solve this problem, the findAll() method of the agent mapper can be rewritten with some conditional statements (obvious code odor), as shown below:

<?php namespace ModelMapper;

class AgentMapper
{
    protected $_adapter;
    protected $_table = "agents";

    public function __construct(PDO $adapter) {
        $this->_adapter = $adapter;
    }

    public function findAll() {
        try {
            return $this->_adapter->query("SELECT * FROM " . $this->_table, PDO::FETCH_OBJ);
        }
        catch (Exception $e) {
            return array();
        }
    }   
}

If you are in a good mood, try the refactoring method and it will work well, whether using a native PDO object or an instance of a PDO adapter. I know this sounds rough, but it's just a quick and easy fix, and it blatantly violates the principle of opening and closing. On the other hand, the adapter's query() method can be refactored to match its signature of rewrite parent class. But in doing so, all other conditions stated by the LSP should also be satisfied. In short, this means that method rewriting should be done with caution and can only be done for very strong reasons. In many use cases, assuming that the interface cannot be used, it is better to create a subclass that only extends (rather than overrides) its base class functionality. In the case of Neo's PDO adapter, this approach will work perfectly and will never break the client code at any level. As I just said, there is a more efficient — but more radical — solution that takes advantage of implementing interfaces. While previous PDO adapters were created through inheritance and undeniably violated the LSP’s precepts, the drawbacks actually come from the way the Agent Mapper class was originally designed. In fact, it depends on a concrete database adapter implementation from top to bottom, rather than on an interface-defined contract. And large OO power has been said since ancient times, this is always a bad thing. So, how will the above solution be implemented?

(The rest is similar to the input text, and can be adjusted and simplified as needed)

The above is the detailed content of The Liskov Substitution Principle. For more information, please follow other related articles on the PHP Chinese website!