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

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直接实例化出类来使用,带来的问题有:

  1. It makes it hard to make changes later 由于依赖于一个具体的实现,具体的东西一般都是易变的,根据SOLID中D(Dependency Inversion Principle)原则,这显然会导致代码不易重构
  2. It makes it hard to test 由于内部生成使用的类,我们测试的时候无法去除易变量,保证不了测试的时候只有一个可变部分
  3. 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请求,这么做的好处是:

  1. 收敛了CustomerRepository的创建,一旦创建CustomerRepository需要改变什么,可以只要一处修改就可以了
  2. 方便测试,我们可以根据测试要求,返回我们需要的CustomerRepository,如下面代码所示:
$serviceLocator->setFactory( 'CustomerRepository', function () {
    return new Path\To\MockCustomerRepository(
        [
            1001 => ( new Customer() )->setName( 'ACME Corp' ),
        ] );
} );

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

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

  1. 仍然需要自己在需要时候,像serviceLocator请求
  2. 为了测试,我们需要修改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个:

  1. When the dependency is used by more than one component 当有多个地方都去new同一个类,并且构建需要一些额外动作的时候,我们就要考虑将构建这个动作封装起来了,核心点是:代码复用
  2. The dependency has different configurations in different contexts 当创建的逻辑变得复杂的时候,我们需要将创建抽取出来,核心点是:单一职责,关注点分离
  3. When you need a different configuration to test a component 如果为了测试需要依赖类返回不同的测试数据,这就要将依赖变为注入的,核心点是:可测性
  4. 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的第四篇,你的鼓励是我继续写下去的动力,期待我们共同进步。

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏分布式系统和大数据处理

HttpHandler介绍

在 Http请求处理流程 一文中,我们了解了Http请求的处理过程以及其它一些运作原理。我们知道Http管道中有两个可用接口,一个是IHttpHandler,一...

14320
来自专栏FD的专栏

Brainfuck JIT Compiler in Rust

我们都知道,对于解释型的语言实现来说,性能是大家关注的焦点。比如,这位 Tondbal ik Ni 曾经还说过:

17530
来自专栏熊二哥

快速入门系列--MVC--05行为

    Action执行包含内容比较多,主要有同步/异步Action的概念和执行过程,Authorationfilter, ActionFiltor, Resu...

20170
来自专栏学习力

《Java从入门到放弃》框架入门篇:hibernate中的多表对应关系

23970
来自专栏丑胖侠

《Drools7.0.0.Final规则引擎教程》第4章 global全局变量

global 全局变量 global用来定义全局变量,它可以让应用程序的对象在规则文件中能够被访问。通常,可以用来为规则文件提供数据或服务。特别是用来操作规则执...

32760
来自专栏iOS技术

YYCache 源码剖析:一览亮点

YYCache 作为当下 iOS 圈最流行的缓存框架,有着优越的性能和绝佳的设计。笔者花了些时间对其“解剖”了一番,发现了很多有意思的东西,所以写下本文分享一下...

52150
来自专栏网络

HttpClient使用心得

做过Java web开发的朋友们,应该大部分都用过Apatch HttpClient工具类库,最近在维护公司一个老项目时,遇到了由于HttpClient使用不当...

41990
来自专栏圣杰的专栏

ASP.NET Core 中断请求了解一下(翻译)

假设有一个耗时的Action,在浏览器发出请求返回响应之前,如果刷新了页面,对于浏览器(客户端)来说前一个请求就会被终止。而对于服务端来说,又是怎样呢?前一个请...

15330
来自专栏大内老A

WCF后续之旅(6): 通过WCF Extension实现Context信息的传递

在上一篇文章中,我们讨论了如何通过CallContextInitializer实现Localization的例子,具体的做法是将client端的culture通...

28360
来自专栏hotqin888的专栏

DOC文件中法规对标系统完成

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/hotqin888/article/det...

8210

扫码关注云+社区

领取腾讯云代金券