php设计模式遵循的原则

原创于 2021-05-21 09:40:53 发布 · 258 阅读

0 ·

CC 4.0 BY-SA版权

PHP高级同时被 2 个专栏收录

10 篇文章

订阅专栏

PHP7

2 篇文章

订阅专栏

php设计模式遵循的原则

在讨论面向对象编程和模式（具体一点来说，设计模式）的时候，我们需要一些标准来对设计的好还进行判断，或者说应该遵循怎样的原则和指导方针。

现在，我们就来了解下这些原则：

单一职责原则（S）
开闭原则（O）
里氏替换原则（L）
接口隔离原则（I）
依赖倒置原则（D）
合成复用原则
及迪米特法则（最少知道原则）

本文将涵盖 SOLID + 合成复用原则的讲解及示例，迪米特法则以扩展阅读形式给出。

单一职责原则（Single Responsibility Principle[SRP]） ★★★★

一个类只负责一个功能领域中的相应职责（只做一类事情）。或者说一个类仅能有一个引起它变化的原因。

来看看一个功能过重的类示例：

/**
* CustomerDataChart 客户图片处理
*/
class CustomerDataChart
{
/**
* 获取数据库连接
*/
public function getConnection()
{
}
/**
* 查找所有客户信息
*/
public function findCustomers()
{
}
/**
* 创建图表
*/
public function createChart()
{
}
/**
* 显示图表
*/
public function displayChart()
{
}
}

我们发现 CustomerDataChart 类完成多个职能：

建立数据库连接
查找客户
创建和显示图表

此时，其它类若需要使用数据库连接，无法复用 CustomerDataChart；或者想要查找客户也无法实现复用。另外，修改数据库连接或修改图表显示方式都需要修改 CustomerDataChart 类。这个问题挺严重的，无论修改什么功能都需要多这个类进行编码。

所以，我们采用 单一职责原则 对类进行重构，如下：

/**
* DB 类负责完成数据库连接操作
*/
class DB
{
public function getConnection()
{
}
}
/**
* Customer 类用于从数据库中查找客户记录
*/
class Customer
{
private $db;
public function __construct(DB $db)
{
$this->db = $db;
}
public function findCustomers()
{
}
}
class CustomerDataChart
{
private $customer;
public function __construct(Customer $customer)
{
$this->customer = $customer;
}
/**
* 创建图表
*/
public function createChart()
{
}
/**
* 显示图表
*/
public function displayChart()
{
}
}

重构完成后：

DB 类仅处理数据库连接的问题，挺提供 getConnection() 方法获取数据库连接；
Customer 类完成操作 Customers 数据表的任务，这其中包括 CRUD 的方法；
CustomerDataChart 实现创建和显示图表。

各司其职，配合默契，完美！

开闭原则（Open-Closed Principle[OCP]） ★★★★★

开闭原则 是 最重要 的面向对象设计原则，是可复用设计的基石。

「开闭原则」：对扩展开放、对修改关闭，即尽量在不修改原有代码的基础上进行扩展。要想系统满足「开闭原则」，需要对系统进行抽象。

通过接口或 抽象类 将系统进行抽象化设计，然后通过实现类对系统进行扩展。当有新需求需要修改系统行为，简单的通过增加新的实现类，就能实现扩展业务，达到在不修改已有代码的基础上扩展系统功能这一目标。

示例，系统提供多种图表展现形式，如柱状图、饼状图，下面是不符合开闭原则的实现：

<?php
/**
* 显示图表
*/
class ChartDisplay
{
private $chart;
/**
* @param string $type 图标实现类型
*/
public function __construct(string $type)
{
switch ($type) {
case 'pie':
$this->chart = new PieChart();
break;
case 'bar':
$this->chart = new BarChart();
break;
default:
$this->chart = new BarChart();
}
return $this;
}
/**
* 显示图标
*/
public function display()
{
$this->chart->render();
}
}
/**
* 饼图
*/
class PieChart
{
public function render()
{
echo 'Pie chart.';
}
}
/**
* 柱状图
*/
class BarChart
{
public function render()
{
echo 'Bar chart.';
}
}
$pie = new ChartDisplay('pie');
$pie->display(); //Pie chart.
$bar = new ChartDisplay('bar');
$bar->display(); //Bar chart.

在这里我们的 ChartDisplay 每增加一种图表显示，都需要在构造函数中对代码进行修改。所以，违反了 开闭原则。我们可以通过声明一个 Chart 抽象类（或接口），再将接口传入 ChartDisplay 构造函数，实现面向接口编程。

/**
* 图表接口
*/
interface ChartInterface
{
/**
* 绘制图表
*/
public function render();
}
class PieChart implements ChartInterface
{
public function render()
{
echo 'Pie chart.';
}
}
class BarChart implements ChartInterface
{
public function render()
{
echo 'Bar chart.';
}
}
/**
* 显示图表
*/
class ChartDisplay
{
private $chart;
/**
* @param ChartInterface $chart
*/
public function __construct(ChartInterface $chart)
{
$this->chart = $chart;
}
/**
* 显示图标
*/
public function display()
{
$this->chart->render();
}
}
$config = ['PieChart', 'BarChart'];
foreach ($config as $key => $chart) {
$display = new ChartDisplay(new $chart());
$display->display();
}

修改后的 ChartDisplay 通过接收 ChartInterface 接口作为构造函数参数，实现了图表显示不依赖于具体的实现类即 面向接口编程。在不修改源码的情况下，随时增加一个 LineChart 线状图表显示。具体图表实现可以从配置文件中读取。

里氏替换原则（Liskov Substitution Principle[LSP]） ★★★★★

里氏代换原则：在软件中将一个基类对象替换成它的子类对象，程序将不会产生任何错误和异常，反过来则不成立。如果一个软件实体使用的是一个子类对象的话，那么它不一定能够使用基类对象。

示例，我们的系统用户类型分为：普通用户（CommonCustomer）和 VIP 用户（VipCustomer），当用户收到留言时需要给用户发送邮件通知。原系统设计如下：

<?php
/**
* 发送邮件
*/
class EmailSender
{
/**
* 发送邮件给普通用户
*
* @param CommonCustomer $customer
* @return void
*/
public function sendToCommonCustomer(CommonCustomer $customer)
{
printf("Send email to %s[%s]", $customer->getName(), $customer->getEmail());
}
/**
* 发送邮件给 VIP 用户
*
* @param VipCustomer $vip
* @return void
*/
public function sendToVipCustomer(VipCustomer $vip)
{
printf("Send email to %s[%s]", $vip->getName(), $vip->getEmail());
}
}
/**
* 普通用户
*/
class CommonCustomer
{
private $name;
private $email;
public function __construct(string $name, string $email)
{
$this->name = $name;
$this->email = $email;
}
public function getName()
{
return $this->name;
}
public function getEmail()
{
return $this->email;
}
}
/**
* Vip 用户
*/
class VipCustomer
{
private $name;
private $email;
public function __construct(string $name, string $email)
{
$this->name = $name;
$this->email = $email;
}
public function getName()
{
return $this->name;
}
public function getEmail()
{
return $this->email;
}
}
$customer = new CommonCustomer("liugongzi", "liuqing_hu@126.com");
$vip = new VipCustomer("vip", "liuqing_hu@126.com");
$sender = new EmailSender();
$sender->sendToCommonCustomer($customer);// Send email to liugongzi[liuqing_hu@126.com]
$sender->sendToVipCustomer($vip);// Send email to vip[liuqing_hu@126.com]

这里，为了演示说明我们通过在 EmailSender 类中的 send* 方法中使用类型提示功能，对接收参数进行限制。所以如果有多个用户类型可能就需要实现多个 send 方法才行。

依据 里氏替换原则 我们知道，能够接收父类的地方一定能够接收子类作为参数。所以我们仅需定义 send 方法来接收父类即可实现不同类型用户的邮件发送功能：

<?php
/**
* 发送邮件
*/
class EmailSender
{
/**
* 发送邮件给普通用户
*
* @param CommonCustomer $customer
* @return void
*/
public function send(Customer $customer)
{
printf("Send email to %s[%s]", $customer->getName(), $customer->getEmail());
}
}
/**
* 用户抽象类
*/
abstract class Customer
{
private $name;
private $email;
public function __construct(string $name, string $email)
{
$this->name = $name;
$this->email = $email;
}
public function getName()
{
return $this->name;
}
public function getEmail()
{
return $this->email;
}
}
/**
* 普通用户
*/
class CommonCustomer extends Customer
{
}
/**
* Vip 用户
*/
class VipCustomer extends Customer
{
}
$customer = new CommonCustomer("liugongzi", "liuqing_hu@126.com");
$vip = new VipCustomer("vip", "liuqing_hu@126.com");
$sender = new EmailSender();
$sender->send($customer);// Send email to liugongzi[liuqing_hu@126.com]
$sender->send($vip);// Send email to vip[liuqing_hu@126.com]

修改后的 send 方法接收 Customer 抽象类作为参数，到实际运行时传入具体实现类就可以轻松扩展需求，再多客户类型也不用担心了。

依赖倒置原则（Dependence Inversion Principle[DIP]） ★★★★★

依赖倒转原则：抽象不应该依赖于细节，细节应当依赖于抽象。换言之，要针对接口编程，而不是针对实现编程。

在里氏替换原则中我们在未进行优化的代码中将 CommonCustomer 类实例作为 sendToCommonCustomer 的参数，来实现发送用户邮件的业务逻辑，这里就违反了「依赖倒置原则」。

如果想在模块中实现符合依赖倒置原则的设计，要将依赖的组件抽象成更高层的抽象类（接口）如前面的 Customer 类，然后通过采用 依赖注入（Dependency Injection） 的方式将具体实现注入到模块中。另外，就是要确保该原则的正确应用，实现类应当仅实现在抽象类或接口中声明的方法，否则可能造成无法调用到实现类新增方法的问题。

这里提到「依赖注入」设计模式，简单来说就是将系统的依赖有硬编码方式，转换成通过采用 设值注入（setter）、构造函数注入 和 接口注入 这三种方式设置到被依赖的系统中，感兴趣的朋友可以阅读我写的深入浅出依赖注入一文。

举例，我们的用户在登录完成后需要通过缓存服务来缓存用户数据：