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

本书的目的是解决如何构建一个中大型应用,并且满足:

  1. 可测性
  2. 可重构
  3. 易处理
  4. 易维护

而对小的应用,不适合本书的原则,本书在组织上按照:

  • 先介绍平时写PHP代码遇到的共性问题,然后给出为什么good, solid,clean code是对于应用的健壮和可维护非常重要
  • 接着介绍了一些原则和设计模式
  • 最后使用这些原则,介绍了Clean Architecture

先介绍第一部分:The Problem With Code

Writing Good Code is Hard

If it were easy, everyone would be doing it

框架是非常好的,可以帮助我们快速的开发,但是前期的学习成本往往很高,特别是如果想要深入理解框架,需要花费大量的经历。

框架的选择上也非常有讲究,每年都有新的框架产生、消亡,我们要选择那些文档好的,活力好的框架,并且框架不应该限制的应用太死,这样我们的应用能快速的从一个框架切换到另一个框架。

另一个重要的议题是:库函数的使用。

composer和packagist的出现,让我们能更方便的使用各种各样的库和函数,但是使用库同样也会和框架一个问题,当库做升级和废弃的时候,我们需要花费精力去迁移、升级库函数。

以上所有的问题都是本书希望能解决的,本书会通过架构来尝试解决这些问题。

What is Architecture?

我们写任何程序的时候,都会按照某种形式组织,而软件架构就是我们组织程序的方式,当然这种组织是为了更好的达成软件的目标。

What does Architecture Look Like?

我们应用的所有特性定义了软件架构,这些特性可能是:

  • 文件的组织方式
  • PHP代码和Html代码怎么交互
  • 面向过程 or 面向对象
  • 等等....

所以定义架构可能非常的冗长,因此我们会针对一些特点给架构起个名字,方便彼此交流,同时运用这些通用的架构模式,也能使我们写出更容易阅读和理解的代码。

举个具体的例子:你可能只要说我在前端使用MVC模式,后端使用API web service,别人就能很容易的理解你整个应用的组织方式了。

Layers of Software

在面向对象编程中,分层架构中的层往往是将功能相同的类放到一起,而分层往往是根据应用的功能进行划分的。虽然每个应用分层会各不相同,但是一般都会有:数据库交互层,业务层,api交互。

好的分层架构中,彼此间松耦合,内部高内聚。

Examples of Poor Architecture

看好的之前,先看看坏的,通过分析坏的能帮我们更好的理解为什么要这么去做。

Dirty,In-line PHP

<body>
  <?php $results = mysql_query(
    'SELECT * FROM customers ORDER BY name'
); ?>
  <h2>Customers</h2>
  <ul>
<?php while ($customer = mysql_fetch_assoc($results)): ?> <li><?= $customer['name'] ?></li>
<?php endwhile; ?>
  </ul>
</body>

问题:

  1. mysql_*函数已经废弃,使得我们升级PHP变得困难 Choosing to use these functions today is choosing heartache tomorrow
  2. 一层就解决了所有的事 将应用所有的事情都在一层中解决了!应用主要有两个关注点:一个是从数据库中获取数据,另一个是是对数据进行展示。
  3. 重构的噩梦 考虑下面的变更
    • 表名(customers)或者列名(name)变了怎么办?有多少文件你需要去修改?如果我们要从mysql_换到PDO怎么办?如果数据不再是从数据库中,而是从Restful API?
    • 如果我们开始使用模块语言,如Twig或者Blade?我们的数据库逻辑深嵌入Html代码中,我们必须要重写所有代码
    • 如果我们想改变名字的显示方式,我们需要更改多少地方?
  4. 代码不可测

Poor Man's MVC

看完用PHP裸写应用后,进一步是使用mvc模式,下面是一个例子:

class CustomersController { public function indexAction() {
    $db = Db::getInstance();
    $customers = $db->fetchAll(
      'SELECT * FROM customers ORDER BY name'
);
return [
'customers' => $customers
]; }
}
<h2>Customers</h2>
<ul>
<?php foreach ($this->customers as $customer): ?> <li><?= $customer['name'] ?></li>
<?php endforeach; ?>
</ul>

我们让显示逻辑和控制逻辑分离了,但是仍然有问题:

  1. 仍然是硬编码Querys
  2. 和Db类强耦合
  3. 仍然很难测试
  4. 分了两个非常大的层

Poor Usage of Database Abstraction

使用Repository设计模式进行重构:

class CustomersController { 
  public function usersAction() {
    $repository = new CustomersRepository(); 
    $customers = $repository->getAll();
    return [
        'customers' => $customers
    ]; 
   }
}
<h2>Customers</h2>
<ul>
<?php foreach ($this->customers as $customer): ?> <li><?= $customer['name'] ?></li>
<?php endforeach; ?>
</ul>

通过使用CustomersRepositoryusersAction不需要关心数据从哪来,怎么获取数据。

但是上面的架构仍然会有些问题:

  1. CustomersRepository强耦合 仍然直接实例化出CustomersRepository类,意味着依赖于具体实现,而不是抽象。
  2. 依赖问题 由于我们仍然依赖于具体的类,因此在测试时候,不适合单元测试。

So how Should this Code Look?

class CustomersController extends AbstractActionController { 
  protected $customerRepository;
public function __construct(CustomerRepositoryInterface $repository) { 
  $this->customerRepository = $repository;
}
public function indexAction() { 
  return [
      'users' => $this->customerRepository->getAll()
    ];
} 
}

上面的代码解决了几个问题:

  1. 通过声明依赖于接口,我们再也不依赖于具体实现了
  2. 可测性好,通过实现不同的CustomerRepositoryInterface,我们就能模拟各种case
  3. 没有地方会影响我们升级新的PHP或者函数库
  4. 数据来源的变化再也不会影响我们了

Coupling The Enemy

耦合是我们遇到的问题中最普遍的,我们为了更好的理解耦合,看两个例子:

Spaghetti Coupling

<body>
<?php $users = mysqli_query('SELECT * FROM users'); ?>
<ul>
<?php foreach ($users as $user): ?> <li><?= $user['name'] ?></li> <?php endforeach; ?>
  </ul>
</body>

上面的代码耦合非常严重,高耦合意味着一旦离开另一个类或功能,将无法工作。上面的例子:一旦离开database,我们不能正常工作了,一旦离开浏览器,我们也无法正常显示用户信息。

OOP Coupling

class UsersController {
public function indexAction() {
  $repo = new UserRepository(); 
  $users = $repo->getAll();
  return $users; 
}
}

UsersController离开UserRepository能工作吗?不能,因此UsersController强依赖于UserRepository

低耦合谁特别关心?

  • Developers who refactor their code.
  • Developers who like to test their code
  • Developers who like to reuse their code

How do we Reduce Coupling?

那怎么减少耦合呢?有下面4个方法

  1. 减少依赖:尽可能将类的职责设计的最少,减少对外部的依赖
  2. 使用依赖注入(DI)
  3. 使用接口,而不是具体的类
  4. 使用适配器:不直接依赖于第三方库,而是使用适配器的方式,减少对于不可控类的依赖

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏IT大咖说

容器化RDS|计算存储分离架构下的 IO 优化

摘要 在基于 Kubernetes 和 Docker 构建的私有 RDS 中,普遍采用了计算存储分离架构。该架构优势明显, 但对于数据库类 Latency Se...

3658
来自专栏地方网络工作室的专栏

MAC解压软件推荐——全能解压

MAC解压软件推荐——全能解压 前言 一直以来,我都没有找到MAC上类似于haozip或者360压缩这样的好用的免费的压缩软件。keka这个软件不能预览压缩包内...

44710
来自专栏美团技术团队

顶会论文:纠删码存储系统中的投机性部分写技术

本文已被USENIX'17年度技术大会录用,此处为中文简译版。 阅读英文论文完整版请点击:Speculative Partial Writes in Erasu...

67910
来自专栏ThoughtWorks

Kubernetes救援 - 教你如何从新技术的坑里爬出来(上) | TW洞见

今日洞见 文章作者/配图来自ThoughtWorks:佟达。 本文所有内容,包括文字、图片和音视频资料,版权均属ThoughtWorks公司所有,任何媒体、网站...

4059
来自专栏数据库新发现

性能测试指标介绍[转载]

http://www-900.ibm.com/cn/products/servers/pseries/tech/tpcc.shtml

2142
来自专栏SDNLAB

【双语频道】6分钟了解ONOS

本视频来自ONOS首席架构师Thomas Vachuska的讲解,视频在短短6分钟左右的时间内深入浅出的对ONOS的架构进行了阐述和分析,并对其功能进行了演示...

3344
来自专栏Zchannel

核武按钮终被劫持?Meltdown与Spectre攻击深入解析

1632
来自专栏黄希彤的专栏

内部体验腾讯负载均衡的新功能

腾讯云近期将推出的新的负载均衡轮询算法,新算法被称为“最小连接数”算法,也就是LB会随时判断哪台主机上的HTTP连接数最少,然后尽量把新的请求分发给它。

8500
来自专栏AI科技大本营的专栏

8月精选Python开源项目Top10

【导读】过去一个月里,我们对近 250 个 Python 开源项目进行了排名,并挑选出热度前 10 的项目。这份清单的平均 github star 数量高达 1...

2095
来自专栏FreeBuf

安全应急响应工具年末大放送

为了帮助安全分析师更好的完成工作,小编整理了一些现在比较流行的安全应急响应工具和资源,从磁盘镜像创建工具、内存分析工具到内存镜像工具、沙盒/逆向工具等,相信总有...

5106

扫码关注云+社区

领取腾讯云代金券