上篇最重要的是介绍了去耦的工具之一设计模式，本篇将继续介绍去耦工具：设计原则。
本文为系列文章的第三篇，第一、二篇地址是
The Clean Architecture in PHP 读书笔记(一)
The Clean Architecture in PHP 读书笔记(二)
The Clean Architecture in PHP 读书笔记（三）
本篇介绍5大设计原则SOLID：
- Single Responsibility Principle
- Open/Closed Principle
- Liskov Substitution Principle
- Interface Segregation Principle
- Dependency Inversion Principle
这5大原则最初是由Robert C. Martin提出，这些原则主要解决了下面两个问题：
- 类应该怎么设计？彼此之间如何交互
- 我们如何组织这些类
介绍第一个原则：单一职责
单一职责原则
单一职责，要想理解这个原则，我们先来看下什么是职责？
Robert C. Martin描述职责是：“a reason for change”。我们写出来的类，如果会因为多于一种原因而去修改，那就不符合单一职责。另一角度看单一职责是从类的对外表现去看，如果类表现出不止一种行为，则也违反了SRP。
class User {
public function getName(){}
public function getEmail(){}
public function find( $id ){}
public function save(){}
}
上面的类User违反了SRP，因为有两个职责：
- 管理user的状态
- 管理user的存取
因此我们需要将其重构为下面两个类：
class User {
public function getName() {}
public function getEmail() {}
}
class UserRepository {
public function find($id) {}
public function save(User $user) {}
}
此时User负责状态，UserRepository负责存取，可能会引起UserRepository的改变的只有存储user地方的改变。
知道什么是单一职责后，我们再深入下去，面对已经存在，或者新建一个类的时候，我们怎么能够分析出它的职责？
Breaking up Classes（拆分类）
class InvoicingService {
public function generateAndSendInvoices() {}
protected function generateInvoice($customer) {}
protected function createInvoiceFile($invoice){}
protected function sendInvoice($invoice) {}
}
看方法名generateAndSendInvoices,直观上来至少有2个职责，生产并且发送单据，分析后，InvoicingService至少有下面4个职责：
- 负责哪个单据需要创建
- 在数据库中产生单据记录
- 产生单据的物理表示（PDF，Excel，CSV等）
- 通过某些手段发送单据给用户
分析出职责后，我们下一步就是将InvoicingService类拆分为小的，符合SRP的类
class OrderRepository {
public function getOrdersByMonth($month);
}
class InvoicingService {
public function generateAndSendInvoices() {}
}
class InvoiceFactory {
public function createInvoice(Order $order) {}
}
class InvoiceGenerator {
public function createInvoiceFormat(
Invoice $invoice,
$format ) {}
}
class InvoiceDeliveryService {
public function sendInvoice(
Invoice $invoice,
$method ) {}
}
根据4个职责拆分为4个类，然后由InvoicingService连接起来。我们看到类InvoiceGenerator和InvoiceDeliveryService其实可以再进一步拆分，因为单据会有不同的表现形式，寄送方式也有多种方式，此时类InvoiceGenerator和InvoiceDeliveryService不仅负责生产和寄送，还负责多种策略的选择。
那介绍了这么多SRP，最重要的问题是：
为什么SRP那么重要？
关键点还是SRP有助于我们实现解耦，去耦是贯穿全文的主题。
总结起来：类越小，越容易测试，越容易重构，也更不容易出现缺陷。
开闭原则
对扩展开发，对修改封闭
这样做的好处是我们不会破会原来的功能，我们只是在上面叠加，而不是修改。
一个开闭原则的非常好的例子就是上一篇介绍的策略模式，我们永远只需要新增策略，而不用去修改现有的策略。
里氏替换原则
先看代码的：
interface HelloInterface {
public function getHello();
}
class EnglishHello implements HelloInterface {
public function getHello()
{
return "Hello";
}
}
class SpanishHello implements HelloInterface {
public function getHello()
{
return "Hola";
}
}
class FrenchHello implements HelloInterface {
public function getHello()
{
return "Bonjour";
}
}
class Greeter {
public function sayHello( HelloInterface $hello )
{
echo $hello->getHello() . "!\n";
}
}
$greeter = new Greeter();
$greeter->sayHello( new EnglishHello() );
$greeter->sayHello( new SpanishHello() );
$greeter->sayHello( new FrenchHello() );
我们看上面的类：在Greeter()中我们使用了HelloInterface，我们可以使用该接口的不同实现，输出的内容会改变，但是不会改变sayHello这个行为本身。
总结起来就是：如果一个类使用了一个接口的一个实现类，那么该接口的任何其他实现类也可以被这里直接使用，不用做出任何修改。
为什么LSP那么重要呢？
LSP使得我们重构代码变的有理可循。任何依赖于的接口的使用方，都不用关心具体实现是什么，因为所有的具体实现都会使得程序行为是正确的。
接口隔离原则
接口隔离和单一职责相关，如果一个类只有一个职责，自然其接口就是隔离的，这么说可能还不是特别明白，我们看代码：
interface LoggerInterface {
public function write( $message );
public function read( $messageCount );
}
class FileLogger implements LoggerInterface {
....
}
class EmailLogger implements LoggerInterface{
....
}
上面我们定义了一个日志接口，并且有两个实现，一个基于文件，一个基于Email，但是Email的实现中，对于read接口，我们难道要去判断是正常邮件还是日志嘛？我们实现EmailLogger，只是想要将关键日志以邮件发送出来，对于read其实是没有需求的，因此我们做如下的重构:
interface LogWriterInterface {
public function write($message);
}
interface LogReaderInterface {
public function read($messageCount);
}
interface LogManagerInterface extends LogReaderInterface, LogWriterInterface {
}
通过将读和写隔离开来，我们得到了更大的灵活性。
为什么ISP重要？
ISP的目标同样是解耦。所有使用接口的使用者都意味着和这个接口耦合，不管你是用还是不用里面的方法，这带来的风险是，如果接口的实现中某个方法有错误，使用者就得承担风险。
依赖反转原则
该原则是后面介绍的The Clean Architecture的核心，因此我们来仔细讨论下：
我们设想下有下面的场景：假设一个class控制了一个简单的游戏。游戏负责接收用户的输入并且将结果展示在屏幕上，具体类如下：
class GameManager {
protected $input;
protected $video;
public function __construct()
{
$this->input = new KeyboardInput();
$this->video = new ScreenOutput();
}
public function run()
{
// accept user input from $this->input // draw the game state on $this->video
}
}
类GameManager依赖于KeyboardInput和ScreenOutput，带来的问题是：如果我们想要改变下输入或者输出，我们只能去修改GameManager类。如果我们应用之前的LSP原则，抽象出输入和输出接口，我们就有下面的实现：
class GameManager {
protected $input;
protected $video;
public function __construct( InputInterface $input, OutputInterface $output
)
{
$this->input = $input;
$this->video = $output;
}
public function run()
{
// accept user input from $this->input // draw the game state on $this->video
}
}
此时我们实现了依赖的反转，怎么回事呢？
看下面的图：
上面的图中：原先GameManager依赖于下面的实现，而在右边：KeyboardInput和ScreenOutput依赖GameManager声明的接口，实现了依赖的大逆转
为什么DIP重要？
DIP给我们的一个重要原则是：尽可能的依赖稳定的东西，因为这样子将来出错的概率会小。
High level modules should not depend upon low level modules. Both should depend upon abstractions.
Abstractions should not depend upon details. Details should depend upon abstractions.
High level modules是相对于low level modules是稳定的，因此不应该依赖于不稳定的low level modules。抽象相对于具体实现也是更稳定的，因此应该是具体实现依赖于抽象。
SOLID原则使得我们的代码更易扩展、重构和测试，下面会继续解耦的第三个工具：依赖反转。
最后推荐下介绍SOLID的非常好的书:Laravel - 从百草园到三味书屋 "From Apprentice To Artisan"目录
这是The Clean Architecture in PHP的第三篇，你的鼓励是我继续写下去的动力，期待我们共同进步。
