The Clean Architecture in PHP 读书笔记(三)The Clean Architecture in PHP 读书笔记(三)

图片

上篇最重要的是介绍了去耦的工具之一设计模式,本篇将继续介绍去耦工具:设计原则。

本文为系列文章的第三篇,第一、二篇地址是

The Clean Architecture in PHP 读书笔记(一)

The Clean Architecture in PHP 读书笔记(二)

The Clean Architecture in PHP 读书笔记(三)

本篇介绍5大设计原则SOLID

  1. Single Responsibility Principle
  2. Open/Closed Principle
  3. Liskov Substitution Principle
  4. Interface Segregation Principle
  5. 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连接起来。我们看到类InvoiceGeneratorInvoiceDeliveryService其实可以再进一步拆分,因为单据会有不同的表现形式,寄送方式也有多种方式,此时类InvoiceGeneratorInvoiceDeliveryService不仅负责生产和寄送,还负责多种策略的选择。

那介绍了这么多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的第三篇,你的鼓励是我继续写下去的动力,期待我们共同进步。 ​

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏FreeBuf

两张图片告诉你为什么域名会被解析到65.49.2.178

2014年1月21日中国出现重大网络事故,大量域名被解析到一个65.49.2.178 这个IP了。 中国的一家DNS服务商DNSPOD于 2014 年 1 月...

4177
来自专栏喔家ArchiSelf

回顾Bob大叔的简洁架构

Robert Martin 就是我们常说的Bob大叔,是码界的骨灰级人物了,在4年前提出了所谓的简洁架构,值得回顾反思一下,看看是否可以借鉴到微服务中呢?

952
来自专栏牛客网

阿里巴巴2018Java实习面经

1312
来自专栏TSW

程序员大型甩锅现场,太搞笑了!

2142
来自专栏FreeBuf

遨游浏览器把全球用户的这些数据偷偷传回了北京服务器

其实咱中国的Maxthon遨游浏览器在国际上也还是有一定知名度的,从StatsMonkey前年的数据来看,它在中国的市场份额排名第6,在波兰的份额也是第6。 最...

2219
来自专栏瓜大三哥

键盘防抖

按键大多是机械式开关结构,一个按键开关在闭合是不会马上接通,在断开时也不会一下在断开,而是会产生一系列的抖动现象。释放按键后,按键信号稳定前出现了多个段脉冲,如...

2159
来自专栏程序员互动联盟

同样的技术,为何别人总是能挖到漏洞 ?

菜鸟和高手的区别,不完全在于你学了多少,更看你能否清晰认知到目前所处阶段,正确迸发出对下一阶段知识的渴望。

1352
来自专栏大数据挖掘DT机器学习

如何用R语言从网上读取多样格式数据

第一部分:数据信息 生活中,我们面临着各种各样的数据:比如你的成绩单,比如公司的财务报表,比如朋友圈的一些状态,比如微信里的一段语音……我们生活的大数据时代的一...

3877
来自专栏互联网技术栈

Dubbo 3.0 即将到来

据了解,新的 Dubbo 内核与 Dubbo 2.0 完全不同,但它兼容 2.0。Dubbo 3.0 将以 Streaming 为内核,而不再是 2.0 时代的...

1072
来自专栏程序员互动联盟

【计算机基本概念】中央处理器

中央处理器(CPU,Central Processing Unit)是一块超大规模的集成电路,是一台计算机的运算核心(Core)和控制核心( Control U...

3485

扫码关注云+社区

领取腾讯云代金券