SOLID 设计原则

考虑代码结构，使代码易于维护、易于扩展、易于阅读。

SRP

Single Responsibility Principle 单一功能原则

职责单一，一个类只有一种修改的原因。

每个类都有它该在的地方，也只能在它该在的地方。

例如：

　　Controller 类，只接受用户输入，返回输出，不需要具体处理背后的事情。当需要表单验证的时候，注入相应的 Request 类。当需要数据操作时，注入相应的 Repository 或 Service 或 Factory。

　　Model 类，将修改器，访问器定义在 trait 然后 use 进来。数据操作逻辑分离成 Repository。

　　Helper.php 全局函数，将同类型的 helper 分离成单独的文件，使其高内聚。然后在 Helper.php 中引入。

OCP

Open/Close Principle 开闭原则

不更改类的前提下，能扩展类的行为

例如：
所有具体的类都需要实现 Interface 中定义的方法。
在 Factory 中实例化具体的类。
在 Controller 中使用 Factory。

首先创建一个 PaymentInterface，任何支付方式都必须实现此接口中定义的方法。

interface PaymentInterface {
    public function pay();
}

接着，创建两个实现 PaymentInterface 的具体类。

class Alipay implements PaymentInterface {
    public function pay() {
        // 支付宝支付具体代码
    }
}

class Wechat implements PaymentInterface {
    public function pay() {
        // 微信支付具体代码
    }
}

然后，创建一个支付工厂，此工厂用来实例化具体的支付类

class PeymentFactory
{
    public function init($payType) {
        switch ($payType) {
            case 'Alipay':
                return new Alipay();
            case 'Wechat':
                return new Wechat();
        }
        throw new Exception('未知支付方式');
    }
}

最后，在控制器中注入此 Factory

public function pay (Request $request, PaymentFactory $paymentFactory) {
    $payment = $paymentFactory->init($request->payType);
    $payment->pay();
}

LSP

Liskov Substitution Principle 里氏替换原则

子类要可以替代父类

ISP

Interface Segregation Principle 接口隔离原则

使用客户端特定的细粒度接口

使用非内聚接口时，创建多个较小的高内聚接口。不要强迫调用者去依赖他不适用的接口。

DIP

Dependency Inversion Principle 依赖反转原则

依赖抽象接口，而不是具体实现

将高层次组件对低层次组件的依赖解耦出来，例如「类A」原本依赖于「类B」，那么新建 「InterfaceB」，让「类A」改为依赖于「InterfaceB」，让「类B」去实现「InterfaceB」 规定的接口方法。

依赖注入 DI

一个类，如果依赖另一个类的功能，就通过注入方式实现。比如在构造方法中引入。

控制反转 IOC

将创建实例的控制权剥离出来，交给IOC容器控制。

本作品采用《CC 协议》，转载必须注明作者和本文链接