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

时间:2022-06-07
本文章向大家介绍The Clean Architecture in PHP 读书笔记(二),主要内容包括其使用实例、应用技巧、基本知识点总结和需要注意事项,具有一定的参考价值,需要的朋友可以参考一下。

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

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

你的解耦工具

在下面的文章中,主要会围绕去耦给出5大工具,让你轻松去耦。

  • Design Patterns,A Primer
  • SOLID Design Principles
  • Depedency Injection
  • Defining a Contract with Interfaces
  • Abstracting with Adapters

先介绍第一个工具:设计模式。

Design Patterns,A Primer

设计模式是对软件中通用问题的总结,有了设计模式,方便我们进行交流,譬如一说MVC,我们就知道是怎么回事了,不然我们必须巴拉巴拉一大堆话去描述,不易于传播、交流,一个好的设计模式必然有一个简单易懂的名字,因为只有简单的东西,才能被大家广泛传播。

如今,一谈到设计模式,被大家广泛传播的就是1994年四人帮提出的23种模式,分为了3大类别:

  1. Creational
  2. Structural
  3. Behavioral

本书不会去按个介绍23个模式,这样去介绍的书籍太多了,而且本书也没有那么多篇幅去按个讲,但是这些都是再进行展开的基础,因此我们会介绍一些最近本的概念:

  1. Factory:负责生产对象,类似于语言本省提供的new关键字,在C++中与new的不同就在于,new不能通过string直接实例化对象,但是factory可以
  2. Repository:不是GoF中提出的设计模式,其类似于一个仓库,负责数据的存储和获取
  3. Adapter:适配器,故名思议就是将接口实现转换
  4. Strategy:目的是灵活性,将一个或一组行为封装起来,方便的进行替换

对上面的概念具体展开

The Factory Patterns

简单代码:

$customer = new Customer();

如果customer足够简单,上面的创建没有问题,但是如果customer创建的时候,必须进行一堆初始化,那我们就疯了,一个简单的想法,当然是将这些创建逻辑抽离出来,变为一个函数,进行复用,因此就有下面的版本,

复杂代码:

class CustomerFactory {
    protected $accountManagerRepo;

    public function __construct(AccountManagerRepository $repo) { 
        $this->accountManagerRepo = $repo;
    }

    public function createCustomer($name) { 
        $customer = new Customer(); 
        $customer->setName($name); 
        $customer->setCreditLimit(0); 
        $customer->setStatus('pending'); 
        $customer->setAccountManager(
          $this->accountManagerRepo->getRandom()
        );
        return $customer; 
    }
}

总结下出现上面代码的原因:软件复杂度的提升,可以这么说,软件中各种问题的出现,都是因为软件的复杂度,不同的复杂度有不同的应对方法,总的目标都是为了降低复杂度

那上面出现的CustomerFactory带来的好处是:

  1. Reusable code.创建的地方都可以调用这段代码,降低了代码的复杂度。
  2. Testable code.由于关注点分离了,方便测试,可以单独进行创建逻辑的测试
  3. Easy to change.创建逻辑只在一处,方便修改
Static Factories
class CustomerFactory {
    public static function createCustomer($name) {
        $customer = new Customer(); 
        $customer->setName($name); 
        $customer->setCreditLimit(0); 
        $customer->setStatus('pending');
        return $customer; 
    }
}
$customer = CustomerFactory::createCustomer('ACME Corp');

静态工厂,通过一个static方法访问,那怎么评判是静态工厂好,还是上面一个工厂好呢?答案是:

It depends

没有最好的,只有更合适的,如果静态方法能满足需求,那就是用静态工厂,如果你是数据源会经常变化,那就使用实例化工厂,并且将需要的依赖注入进来。

Types of Factories
  1. The Factory Method pattern:定义了创建对象的方法,但是具体创建哪个对象,由子类决定
  2. The Abstract Factory pattern:抽象工厂模式的粒度更粗一点,不仅管一个对象的创建,而是管着一组相关对象的创建

talk is cheap,show me the code

让我们上代码的。

class Document {

    public function createPage() {

        return new Page();
    }

}

如果我们又好几种page,怎么办?

class Document {

    public function createPage($type) {
      switch $type {
        case "ResumeDocument":
          return new ResumePage();
        case "PortfolioDocument":
          return new PortfolioPage();
      }
    }

}

上面代码的问题是:我们每次新曾一个类型的page,必须要修改createPage方法,不满足开放封闭原则(OCP),那PHP有个好处是,直接传递给new字符串就能创建对象,看代码:

class Document {

    public function createPage($type) {
      return new $type;
    }
}

问题:我们无法验证传入$type的有效性,而且对createPage返回的类型,我们也无法检查,那怎么办呢?

思路是:将创建逻辑按照关注点分离的逻辑,每个类型的document创建自己的page,这就解决了$type的有效性问题,那对于返回值,我们定义一个公共接口,只有实现这个接口的才是符合预期的。

abstract class AbstractDocument {
    abstract public function createPage():PageInterface;
}
class ResumeDocument extends AbstractDocument {         
  public function createPage():PageInterface {
        return new ResumePage(); 
    }
}
class PortfolioDocument extends AbstractDocument {      
  public function createPage():PageInterface {
        return new PortfolioPage(); 
    }
}
interface PageInterface {}
class ResumePage implements PageInterface {} 
class PortfolioPage implements PageInterface {}

介绍第一个概念The Abstract Factory pattern

抽象工厂就是对于工厂方法的1+1=2的叠加。

如果我们的Document不止创建一个page,还要创建cover,那就会有两个create方法,此时每个子类就多实现一个方法的。

Repository Pattern

仓储模式:该模式在Eric Evan的神书:Domain-Driven Design: Tackling Complexity in the Heart of Software中详细的进行了描述

A REPOSITORY represents all objects of a certain type as a conceptual set (usuallyemulated). It acts like a collection, except with more elaborate querying capability. Domain-Driven Design, Eric Evans, p. 151

仓储类似于一个数据集合,相比较集合有更多精细设计的query,当我们谈论Repository的时候,我们关注的不再是“querying the database”,而是更纯粹的目的:存取数据

常用的读取数据的方法

class MyRepository {
    public function getById($id); 
    public function findById($id); 
    public function find($id); 
    public function retrieve($id);
}

常用的写方法:

class MyRepository {
    public function persist($object); 
    public function save($object);
}

每个Repository对应一个类的存取,有多个类,就会有多个Repository。

一个Repository怎么工作?

Objects of the appropriate type are added and removed, and the machinery behindthe REPOSITORY inserts them or deletes them from the database. Domain-Driven Design, Eric Evans, p. 151

主要给出一些资源:

Dotrine ORM:实现了Date Mapper

Eloquent ORM,Propel:实现了Active Record

Zend Framework 2:提供了Table Data Gateway模式

如果你想要自己实现一个Repository,强烈推荐Patterns of Enterprise Application Architecture

关于数据库的各种模式,推荐一个ppt

Adapter Pattern

直接看代码:

class GoogleMapsApi {
    public function getWalkingDirections($from, $to) {}
}
interface DistanceInterface {
    public function getDistance($from, $to);
}
class WalkingDistance implements DistanceInterface {    
  public function getDistance($from, $to) {
        $api = new GoogleMapsApi();
        $directions = $api->getWalkingDirections($from, $to);
        return $directions->getTotalDistance(); 
    }
}

适配器,非常明确的表名了意图,通过WalkingDistance将GoogleMapsApi适配为了DistanceInterface

Strategy Pattern

也是看代码:

public function invoiceCustomers(array $customers) { 
    foreach ($customers as $customer) {
        $invoice = $this->invoiceFactory->create(
          $customer,
          $this->orderRepository->getByCustomer($customer)
        );
        // send invoice...
    } 
}
// 此处我们根据用仓库里获取到的用户账单,通知用户


interface InvoiceDeliveryInterface { 
  public function send(Invoice $invoice);
}

class EmailDeliveryStrategy implements InvoiceDeliveryInterface { 
    public function send(Invoice $invoice) {
    // Use an email library to send it
    } 
}
class PrintDeliveryStrategy implements InvoiceDeliveryInterface { 
    public function send(Invoice $invoice) {
    // Send it to the printer
    } 
}
// 账单有两种通知方式,一种是发邮件,一种是print

public function invoiceCustomers(array $customers) { 
    foreach ($customers as $customer) {
        $invoice = $this->invoiceFactory->create(
        $customer,
        $this->orderRepository->getByCustomer($customer));
    switch ($customer->getDeliveryMethod()) { 
    case 'email':
        $strategy = new EmailDeliveryStrategy();
        break; 
    case 'print': 
    default:
        $strategy = new PrintDeliveryStrategy();
        break; 
    }
    $strategy->send($invoice);
  }
}
// 通过策略模式:我们可以在runtime,根据不同的账单,选择而不同的发送策略
// 问题:发送策略的选择不应该在外部直接暴露,改选择什么通知策略,应该是用户自己知道的,因此就有了下面的代码:

class InvoiceDeliveryStrategyFactory {
    public function create(Customer $customer) {
        switch ($customer->getDeliveryMethod()) { 
        case 'email':
            return new EmailDeliveryStrategy();
            break; 
        case 'print': 
        default:
            return new PrintDeliveryStrategy();
            break; 
        }
    } 
}
// 此时的客户端,根据最少职责原则,此时invoiceCustomers值负责创建账单,并且发送,并不负责选择什么方式寄送
public function invoiceCustomers(array $customers) {    
  foreach ($customers as $customer) {
    $invoice = $this->invoiceFactory->create(
      $customer,
      $this->orderRepository->getByCustomer($customer));
    $strategy = $this->deliveryMethodFactory->create(
      $customer);
    $strategy->send($invoice);
  }
}

更多的设计模式:

  1. 设计模式:可复用面向对象软件的基础
  2. Head First Design Patterns

请期待下一篇SOLID Design Principles