佳星辰 的个人博客

SOLID是 面向对象编程 和 面向对象设计 的五个基本原则，应用这五个原则能创建一个易于维护和拓展的软件系统。

SOLID 可以指导代码重构和在迭代的过程中进行代码清扫，以使得软件源代码清晰可读和具有良好的扩展性。在测试驱动开发中是典型应用场景，并且也是敏捷开发和自适应软件开发基本原则的重要组成部分

单一功能原则（S）

引起类变化的因素永远不要多于一个，也就是说一个类有且只有一个职责。

在 Laravel 框架的模型中，我们既定义了数表关联关系，又定义了服务器，修改器，还将部分数据访问逻辑写在模型中，模型到最后就会很臃肿而且难以维护。

通过分拆，把相同功能的函数及功能放在一起，使得同一类进行高内聚，可以更好的进行这些代码的集中管理和维护。全局函数分拆可以通过将不同功能的函数放入不同的文件中，然后在 Helpers.php 引入解决，而模型分拆，可以将修改器，访问器定义在 trait 中然后在模型中 use 分拆（PHP 5.4 以上版本），数据访问逻辑可以通过 Repository 设计模式进行与模型分离。

开闭原则 (O)

软件实体（类，模块，函数等等）应当对扩展开放，对修改闭合。

这个是面向对象编程原则中最为抽象、最难理解的。「对扩展开放」指的是设计类时要考虑到新需求提出是类可以增加新功能，「对修改关闭」指的是一旦一个类开发完成，除了修正 BUG 就不要再去修改它。

这个原则前后两步似乎是冲突的，但是如果正确地设计类和它们的依赖关系，就可以增加功能而不修改已有的源代码。

通常可以通过依赖关系抽象实现开闭原则，比如 interface（接口） 或 abstract（抽象类）而不是具体类，通过创建新的类实现它们来增加功能。

这个原则能减少改出来的 BUG 出现，而且增加软件本身的灵活性。

比如支付功能，不遵守这个原则的话你可能会写出这样的代码:

public function payInit($payType){
    $payment = null;
    if(true == $payType){
        // 微信支付
        $payment = acceptWechat($total);
    }else{
        // 支付宝支付
        $payment = acceptAlipay($total);
    }
    return $payment;
}

以上的代码中初始化了两种支付方式，当业务增长时要增加信用卡支付只能去修改这个方法增加 elseif 或者改为 switch 而且因为忽视了业务的增长情况，传入参数是一个 Bool 值，不能适用这种变化，因此需要更改调用的传值，这种修改只要一不小心就会改出 BUG 来。

更好的解决方案是：

interface PaymentMethod{ public function accept($total) }

public function checkOut(PaymentMethod $pm, $total){
    return $pm->accept($total);
}

这样在实现一个新的支付渠道时，只要实现 PaymentMethod 接口就可以创建一个新的支付方式，在调用时将实现接口具体类的实例传入到 checkOut 中就可以得到不同支付渠道付款的实例，而不用每新增一个支付渠道就去修改原来的代码。

里氏替换原则 (L)

当一个子类的实例应该能够替换任何其父类的实例时，它们之间才具有 IS-A 关系

里氏替换原则适用于继承层次结构，指设计类时客户端依赖的父类可以被子类替换，而客户端无须了解这个变化。

一个违反 LSP 的典型例子是 Square（正方形） 类派生于 Rectangle（长方形） 类。Square 类总是假定宽度与高度相等。如果一个正方形对象用于期望一个长方形的上下文中，可能会出现意外行为，因为一个正方形的宽高不能 (或者说不应该) 被独立修改。

如果没有 LSP，类继承就会混乱；
如果子类作为一个参数传递给方法，将会出现未知行为；
如果没有 LSP，适用与基类的单元测试将不能成功用于测试子类；
若违反 LSP 进行设计，将导致不明确的行为产生，不明确也意味着它在开发过程中运行良好，但生产环境下会出现偶发 BUG，我们不得不去查阅上百兆的日志找出错误发生在什么地方

接口隔离原则 (I)

不要强迫客户端（泛指调用者）去依赖那些他们不使用的接口

当我们使用非内聚的接口时，ISP 原则指导我们创建多个较小的高内聚接口。

比如我们创建一个鸟类接口 Bird，这个接口中包括了鸟类的很多行为，其中有一个行为是飞行方法 Fly ()，但是此时我们要创建一个 Ostrich（鸵鸟）类，那么还是需要实现不必要的 Fly () 方法，此时这个臃肿的接口就应该拆成 Bird 接口和 FlyingBird 接口，Ostrich 类只需去实现 Bird 接口就可以了，在这个接口里没有 Fly () 这个方法，而要创建一个 KingFisher（翠鸟） 类就去实现 FlyingBird，那么当你要创建一个企鹅类，你觉得你应该去实现那个接口呢？

上面这个例子是单一接口实现，也许你觉得太简单了，而且实际业务中无法用的，我们为什么要没事干去创建上面鸟类接口并且去实现它呢，那么我们来接下来看一个更贴近实际业务的例子吧。

想象一个 ATM 取款机，通过屏幕显示我们想要的不同信息，我们现在要为取款机添加一个仅在取款功能界面才出现的信息，比如「ATM 机将在您取款时收取一些费用，你同意吗？」。这时你有一个 Messenger 接口，你也许会直接给 Messenger 接口添加一个方法，然后去实现它。这时你就违反了 OCP 原则，代码开始腐败！因为所有实现 Messenger 接口的实现类都需要进行修改实现这个新添加的方法。但我们仅仅需要在取款界面才具有这个方法

interface Messenger {
    askForCard();
    tellInvalidCard();
    askForPin();
    tellInvalidPin();
    tellCardWasSiezed();
    askForAccount();
    tellNotEnoughMoneyInAccount();
    tellAmountDeposited();
    tellBalance();
}

根据 ISP 原则，我们需要将 Messenger 接口进行分切，不同的 ATM 功能依赖于分离后的 Messenger

interface LoginMessenger {
  askForCard();
  tellInvalidCard();
  askForPin();
  tellInvalidPin(); 
}

interface WithdrawalMessenger {
  tellNotEnoughMoneyInAccount();
  askForFeeConfirmation();
}

publc class EnglishMessenger implements LoginMessenger, WithdrawalMessenger {
  ...   
}

依赖反转原则（D）

1. 高层模块不应该依赖底层模块，两者都应该依赖其抽象

2. 抽象不应该依赖于细节，细节应该依赖于抽象

interface Reader { getchar(); }
interface Writer { putchar($c);}

class CharCopier {

  public function copy(Reader reader, Writer writer) {
    $c;
    while ((c = reader.getchar()) != EOF) {
      writer.putchar();
    }
  }
}

public Keyboard implements Reader {...}
public Printer implements Writer {...}

以上代码片段是一个例子，一个程序依赖于 Reader 和 Writer 接口，Keyboard 和 Printer 作为依赖于这些抽象的细节实现了这些接口，CharCopier 是依赖于 Reader 和 Writer 实现类的底层细节，可以传入任何 Reader 和 Writer 的实现进行正常工作。