The Clean Architecture in PHP 读书

2016-11-03 本文已影响234人小聪明李良才

Dependency Injection

上篇最重要的是介绍了去耦的工具之一设计原则SOLID，本篇将继续介绍去耦工具：依赖注入。

本文为系列文章的第四篇，前3篇地址是

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

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

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

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

到目前为止，我们在面向对象中遇到的最坏的code是：直接在一个类中实例化出另一个类，然后使用的。看代码：

class CustomerController {

    public function viewAction()
    {
        $repository = new CustomerRepository();
        $customer   = $repository->getById( 1001 );
        return $customer;
    }
}

此处CustomerController类如果脱离了CustomerRepository类，将无法正常执行，对CustomerRepository是强依赖。

这种通过new class直接实例化出类来使用，带来的问题有：

It makes it hard to make changes later

由于依赖于一个具体的实现，具体的东西一般都是易变的，根据SOLID中D(Dependency Inversion Principle)原则，这显然会导致代码不易重构
It makes it hard to test

由于内部生成使用的类，我们测试的时候无法去除易变量，保证不了测试的时候只有一个可变部分
We have no control over dependencies

由于使用new来新建类，我们无法根据条件，选择性的使用依赖类

控制反转

首先我们回答第一个问题：控制反转是什么？

原先我们在类中直接new出我们依赖的类，如前面CustomerController中直接创建了CustomerRepository；此时我们为了获得一定的灵活性，可能通过配置的方式来实例化出需要的Repository来，简单的配置方式就是一些if,else语句，现在我们再进一步，将这些if,else配置移出CustomerController类，通过一些外部的手段来达到相同的目的。

而上面我们介绍的这一个过程从类内部到类外部的过程就是所谓的：控制反转。上面提到的外部的手段主要有两种：

服务定位模式（Service Locator Pattern）
依赖注入（dependency injection）

下面先介绍第一个手段：服务定位模式

服务定位模式

先上代码，有个感性认识

public function viewAction()
{
  $repository = $this->serviceLocator->get( 'CustomerRepository' );
  $customer   = $repository->getById( 1001 );
  return $customer;
}

$serviceLocator->setFactory( 'CustomerRepository', function ( $sl ) {
    return new Path\To\CustomerRepository(
        $sl->get( 'Connection' )
    );
} );

此时我们不会在viewAction内部直接new出CustomerRepository，而是向serviceLocator请求，这么做的好处是：

收敛了CustomerRepository的创建，一旦创建CustomerRepository需要改变什么，可以只要一处修改就可以了
方便测试，我们可以根据测试要求，返回我们需要的CustomerRepository，如下面代码所示：

$serviceLocator->setFactory( 'CustomerRepository', function () {
    return new Path\To\MockCustomerRepository(
        [
            1001 => ( new Customer() )->setName( 'ACME Corp' ),
        ] );
} );

到这边是不是已经是做合理的代码了呢？我们能不能进一步优化呢？答案是：yes！

我们来看下现在的实现还存在的问题：

仍然需要自己在需要时候，像serviceLocator请求
为了测试，我们需要修改setFactory的方法，给出测试的实现

那有没有办法解决呢，当然有，那就是下面介绍的依赖注入

依赖注入

依赖注入是一个过程：将类它所依赖的外部类由它自己管理变为从外部注入。

下面会介绍两种注入方法：

Setter injection
Constructor injection

使用setter injection

此时前面的代码会变为:

$controller = new CustomerController();
$controller->setCustomerRepository( new CustomerRepository() );
$customer = $controller->viewAction();

class CustomerController {
    protected $repository;
    public function setCustomerRepository( CustomerRepository $repo )
    {
        $this->repository = $repo;
    }
    public function viewAction()
    {
        $customer = $this->repository->getById( 1001 );
        return $customer;
    }
}

依赖是通过setter方法注入的。

此时测试的时候，我们只需要通过setter方法设置MockCustomerRepository即可。

这种方法有一个缺点：如果我们忘记了调用setter方法，那就完蛋了。

$controller = new CustomerController();
$customer   = $controller->viewAction();

上面这种代码，只能等着fatal了。

使用Constructor injection

此时的代码长这个样子：

$controller = new CustomerController( new CustomerRepository() );
$customer   = $controller->viewAction();

class CustomerController {
    protected $repository;
    public function __construct( CustomerRepository $repo )
    {
        $this->repository = $repo;
    }
    public function viewAction()
    {
        $customer = $this->repository->getById( 1001 );
        return $customer;
    }
}

我们不会出现之前setter injection那种忘了设计的问题了，因为我们通过构造函数声明了我们的规则，必须遵守。

讲了这么多依赖注入了，那我们什么时候使用呢？

什么时候使用依赖注入

依赖注入解决的是依赖问题，目的是去耦，那自然有耦合的地方就会有依赖注入，主要的场景有下面4个：

When the dependency is used by more than one component

当有多个地方都去new同一个类，并且构建需要一些额外动作的时候，我们就要考虑将构建这个动作封装起来了，核心点是：代码复用
The dependency has different configurations in different contexts

当创建的逻辑变得复杂的时候，我们需要将创建抽取出来，核心点是：单一职责，关注点分离
When you need a different configuration to test a component

如果为了测试需要依赖类返回不同的测试数据，这就要将依赖变为注入的，核心点是：可测性
When the dependency being injected is part of a third party library

当我们使用的依赖是第三方库的时候，我们更应该使用依赖注入，核心点是：依赖抽象，不变的

有那么多适合使用依赖注入的场景，那自然会有不适合的地方，如果需要构建的依赖足够简单，没有配置，我们无需引入依赖注入，依赖注入的引入是为了解决问题，而不是为了增加代码复杂性。

使用工厂来创建依赖

class CustomerController {

    protected $repository;
    protected $responseFactory;
    public function __construct( CustomerRepository $repo, ResponseFactory $factory )
    {
        $this->repository      = $repo;
        $this->responseFactory = $factory;
    }
    public function viewAction()
    {
        $customer = $this->repository->getById( 1001 );
        $response = $this->responseFactory->create( $this->params( 'context' ) );
        $response->setData( 'customer', $customer );
        return $response;
    }
}

上面的需求是：我们希望能够根据参数的不同，创建不同的响应，可能是Html的，也可能是Json或者XML的，此时我们传入一个工厂，让工厂来负责根据不同的参数来产生不同的对象，核心点还是说依赖抽象的，不变的，易变的东西我们都不要。

处理很多依赖

依赖处理不好，很容易出现下面的代码：

public function __construct(
    CustomerRepository $customerRepository,
    ProductRepository $productRepository,
    UserRepository $userRepository,
    TaxService $taxService,
    InvoiceFactory $invoiceFactory, 
    ResponseFactory $factory,
// ...
){
    // ...
}

出现上面的原因是因为类违反了单一职责原则。没有一个硬性的指标说我们应该依赖多少类，但是一般来说是越少越好，意味着职责更专一。

我们仍然耦合嘛？

我们上面介绍了这么多依赖注入，目的都是为了去耦，回过头来看下，我们做了这么多是否去耦了呢？

最初我们的代码是：

public function viewAction()
{
  $repository = new CustomerRepository();
  $customer   = $repository->getById( 1001 );
  return $customer;
}

重构后是：

class CustomerController {

    protected $repository;

    public function __construct( CustomerRepository $repo )
    {
        $this->repository = $repo;
    }

    public function viewAction()
    {
        $customer = $this->repository->getById( 1001 );
        return $customer;
    }
}

此时CustomerController仍然依赖于CustomerRepository，具体是实现那就是易变的，我们的原则是依赖不变的，抽象的，因此，我们需要将进一步的去耦，这就是下面要介绍的：通过接口来定义契约。

最后给出一些讲依赖注入非常好的几篇文章：

Dependency "Injection" Considered Harmful

依赖注入那些事儿

laravel 学习笔记 —— 神奇的服务容器

ioc

如果大家对第一篇英文文章感兴趣，有时间我可以翻译下，通俗的给讲一下的。

这是The Clean Architecture in PHP的第四篇，你的鼓励是我继续写下去的动力，期待我们共同进步。