面向对象设计原则 SOLID

SRP 单一职责原则

<?php

<<<EOF
SRP 单一职责原则

任何一个软件模块都应该只对某一类行为者负责
EOF;

<<<EOF
下面举一个错误示范

Animal 既有吃肉, 又有吃奶酪. 在某些情况下肯定就会导致错误, 比如 jerry 不吃肉, 但是因为 jerry 是 Animal 的实例, 所以 jerry 也可以吃肉了, 这不符合逻辑。
另外一种问题是修改的时候, 比如 tom 吃奶酪的方式是一口一个, 然后 tom 的开发者把 Animal 的吃奶酪方法改为一口一个, jerry 本来是小口吃也会受到影响.
EOF;

class Animal{

    private string $name;
    private string $type;

    function __construct(string $name,string $type){
        $this->name = $name;
        $this->type = $type;
    }

    function eatMeat(){
        echo $this->type . $this->name . " eat meat";
    }

    function eatCheese(){
        echo $this->type . $this->name . " eat cheese";
    }
}


<<<EOF
解决办法有两种, 第一种是直接将动物的属性和动物的操作相分离, 像下面这样猫的操作和老鼠的操作作为两个类互不影响, 同时他们的 animalInfo 都是 AnimalInfo 的实例, 保持了 Animal 的共性
EOF;

class AnimalInfo{

    private string $name;
    private string $type;

    function __construct(string $name,string $type){
        $this->name = $name;
        $this->type = $type;
    }

    function getName():string
    {
        return $this->name;
    }
    function getType():string
    {
        return $this->type;
    }

}


class Cat{

    private AnimalInfo $animalInfo;

    function __construct(AnimalInfo $animalInfo){
        $this->animalInfo = $animalInfo;
    }

    function eatMeat(){
        echo $this->animalInfo->getType() . ":" . $this->animalInfo->getName() . " eat meat";
    }

    function eatCheese(){
        echo $this->animalInfo->getType() . ":" . $this->animalInfo->getName() . " eat cheese";
    }
}

class Mouse{

    private AnimalInfo $animalInfo;

    function __construct(AnimalInfo $animalInfo){
        $this->animalInfo = $animalInfo;
    }

    function eatCheese(){
        echo $this->animalInfo->getType() . ":" . $this->animalInfo->getName() . " eat cheese";
    }
}

<<<EOF
上面的方法可以解决问题, 但是从 Animal 的使用者角度看, 原来需要管理一个类, 现在需要管理三个类, 而且得根据不同的情况创建不同的类的实例, 真的很麻烦.
为了解决上面的问题, 下面还有一种更好的方法, 那就是 Facade 设计模式, 可以看到使用者只需要管理 AnimalFacade 就可以做到和上面相同的事
EOF;

class AnimalFacade{

    private $animalImpl;

    function __construct(string $name,string $type){
        if($type == 'cat'){
            $this->animalImpl = new Cat(new AnimalInfo($name, $type));
        }elseif($type == 'mouse'){
            $this->animalImpl = new Mouse(new AnimalInfo($name, $type));
        }
    }

    function eatMeat()
    {
        $this->animalImpl->eatMeat();
    }

    function eatCheese()
    {
        $this->animalImpl->eatCheese();
    }

}




<<<EOF
本来到这里就结束了, 但是可能有的人会想到为什么不直接用多态来解决这个问题, 个人理解多态和上面的两种解决方法并不冲突, 然后第一种解法中的状态和操作相分离的思路确实非常的炫酷
EOF;


function test_1(){
    $tom = new Animal('Tom', 'cat');
    $tom->eatMeat();
    $jerry = new Animal('Jerry', 'mouse');
    $jerry->eatCheese();
}



function test_2(){
    $tom = new AnimalInfo('Tom', 'cat');
    $jerry = new AnimalInfo('Jerry', 'mouse');
    $cat = new Cat($tom);
    $mouse = new Mouse($jerry);
    $cat->eatMeat();
    $mouse->eatCheese();
}


function test_3(){
    $tom = new AnimalFacade('Tom', 'cat');
    $tom->eatMeat();
    $jerry = new AnimalFacade('Jerry', 'mouse');
    $jerry->eatCheese();
}

test_1();
test_2();
test_3();

OCP 开闭原则

<?php

<<<EOF
OCP 开闭原则
设计良好的计算机软件应该易于扩展， 同时抗拒修改

什么意思呢? 就是说设计好的软件, 如果要扩展它的功能是很容易的, 同时扩展它的功能时不需要修改已有的功能模块。
EOF;


<<<EOF
同样先举一个不好的例子, 在写功能的时候先写 controller 然后慢慢的 controller 的行数太长了, 又把 controller 的代码往 services 抽离, 这样每次需要改 controller, 就要改之前抽离的 service, 这就不符合开闭原则。
EOF;


class UserController
{

    private $responseData;

    function update(array $form)
    {
// 模拟重构
//        $updateData = [];
//        if(isset($form['name'])){
//            $updateData["name"] = $form['name'];
//        }
//        if(isset($form['aga'])){
//            $updateData["aga"] = $form['aga'];
//        }
//        if(isset($form['id'])){
//            UserModel::where('id', $form['id'])->update($updateData);
//            $this->response_data = ["code"=> 200, "msg"=> "更新成功"];
//        }else{
//            $this->response_data = ["code"=> 501, "msg"=> "参数错误, 缺少 id"];
//        }
        $this->responseData = UserService::update($form);
        return $this->responseData;
    }
}

class UserService
{
    static function update($form)
    {
        // 后续这里必定还会再改
        $updateData = [];
        if (isset($form['name'])) {
            $updateData["name"] = $form['name'];
        }
        if (isset($form['aga'])) {
            $updateData["aga"] = $form['aga'];
        }
        if (isset($form['id'])) {
            UserModel::where('id', $form['id'])->update($updateData);
            return ["code" => 200, "msg" => "更新成功"];
        } else {
            return ["code" => 501, "msg" => "参数错误, 缺少 id"];
        }
    }
}


<<<EOF
正确的方法是先定义 接口和 service , 然后扩展 service
下面的 ProjectInterface 是一个接口, 定义了一个 update 方法, 代表了不论 ProjectService 的功能如何扩展, update 是必定存在的, 同时 ProjectService 又可以很方便的扩展, 这就是符合了开闭原则
EOF;

interface ProjectInterface
{
    function update($form);
}

class ProjectService implements ProjectInterface
{
    function update($form)
    {
    }
}

// 这里模拟重构
class ProjectServiceV1 extends ProjectService
{
    function update($form)
    {
        $updateData = [];
        // TODO 这里懒得写了
    }
}


class ProjectController
{
    // 这里直接通过接口名称注入实现
    function update(ProjectInterface $service, $form)
    {
        $this->response_data = $service->update($form);
        return $this->response_data;
    }
}


<<<EOF
开闭原则在软件架构中的应用, 主要体现在一个逻辑分层的概念, 比如 MVC,  当代码需要修改时, 第一反应就是要修改那一层的代码, 而不是直接重构项目
EOF;

LSP 里氏替换原则

<<<EOF
LSP 里氏替换原则
操作父类的程序在操作子类时行为可以保持不变

里氏替换原则可以看作开闭原则的补充, 开闭原则中提到好的架构是方便扩展的, 里氏替换原则对这种扩展进行了限制, 要求子类对父类进行扩展时需要保证行为一致, 不能随意扩展。

这里行为一致其实指的就是，返回值的类型相同或者更严格， 而不是说子类的方法必须和父类一模一样。 所以不用纠结子类的返回值不一样了，是不是不符合里氏替换原则了。 因为面向对象的多态，指的就是同一类型的不同对象， 行为可能不同。 里氏替换原则只是要求行为一致，不是完全相同。
EOF;


<<<EOF
同样举一个不好的例子
EOF;

####### 太晚了, 懒得写了。

<<<EOF
里氏替换原则不仅可以用在代码层面，还可以用在架构层面， 比如日志系统... 写着写着忘了， 睡觉了， 晚安玛卡巴卡
EOF;