PHP程序员如何理解IoC/DI

转载 2016年05月31日 11:25:28

本文转自:https://segmentfault.com/a/1190000002411255

非侵入性 No intrusive

  • 框架的目标之一是非侵入性(No intrusive)

  • 组件可以直接拿到另一个应用或框架之中使用

  • 增加组件的可重用性(Reusability)

容器(Container)

  • 管理对象的生成、资源取得、销毁等生命周期

  • 建立对象与对象之间的依赖关系

  • 启动容器后,所有对象直接取用,不用编写任何一行代码来产生对象,或是建立对象之间的依赖关系。

IoC

  • 控制反转 Inversion of Control

  • 依赖关系的转移

  • 依赖抽象而非实践

DI

  • 依赖注入 Dependency Injection

  • 不必自己在代码中维护对象的依赖

  • 容器自动根据配置,将依赖注入指定对象

AOP

  • Aspect-oriented programming

  • 面向方面编程

  • 无需修改任何一行程序代码,将功能加入至原先的应用程序中,也可以在不修改任何程序的情况下移除。

分层

表现层:提供服务,显示信息。
领域层:逻辑,系统中真正的核心。
数据源层:与数据库、消息系统、事务管理器及其它软件包通信。
——《企业应用架构模式》P.14

代码演示IoC

假设应用程序有储存需求,若直接在高层的应用程序中调用低层模块API,导致应用程序对低层模块产生依赖。

/**
 * 高层
 */
class Business
{
    private $writer;

    public function __construct()
    {
        $this->writer = new FloppyWriter();
    }

    public function save()
    {
        $this->writer->saveToFloppy();
    }
}

/**
 * 低层,软盘存储
 */
class FloppyWriter
{
    public function saveToFloppy()
    {
        echo __METHOD__;
    }
}

$biz = new Business();
$biz->save(); // FloppyWriter::saveToFloppy

假设程序要移植到另一个平台,而该平台使用USB磁盘作为存储介质,则这个程序无法直接重用,必须加以修改才行。本例由于低层变化导致高层也跟着变化,不好的设计。

正如前方提到的

控制反转 Inversion of Control
依赖关系的转移
依赖抽象而非实践

程序不应该依赖于具体的实现,而是要依赖抽像的接口。请看代码演示

/**
 * 接口
 */
interface IDeviceWriter
{
    public function saveToDevice();
}

/**
 * 高层
 */
class Business
{
    /**
     * @var IDeviceWriter
     */
    private $writer;

    /**
     * @param IDeviceWriter $writer
     */
    public function setWriter($writer)
    {
        $this->writer = $writer;
    }

    public function save()
    {
        $this->writer->saveToDevice();
    }
}

/**
 * 低层,软盘存储
 */
class FloppyWriter implements IDeviceWriter
{

    public function saveToDevice()
    {
        echo __METHOD__;
    }
}

/**
 * 低层,USB盘存储
 */
class UsbDiskWriter implements IDeviceWriter
{

    public function saveToDevice()
    {
        echo __METHOD__;
    }
}

$biz = new Business();
$biz->setWriter(new UsbDiskWriter());
$biz->save(); // UsbDiskWriter::saveToDevice

$biz->setWriter(new FloppyWriter());
$biz->save(); // FloppyWriter::saveToDevice

控制权从实际的FloppyWriter转移到了抽象的IDeviceWriter接口上,让Business依赖于IDeviceWriter接口,且FloppyWriter、UsbDiskWriter也依赖于IDeviceWriter接口。

这就是IoC,面对变化,高层不用修改一行代码,不再依赖低层,而是依赖注入,这就引出了DI。

比较实用的注入方式有三种:

  • Setter injection 使用setter方法

  • Constructor injection 使用构造函数

  • Property Injection 直接设置属性

事实上不管有多少种方法,都是IoC思想的实现而已,上面的代码演示的是Setter方式的注入。

依赖注入容器 Dependency Injection Container

  • 管理应用程序中的『全局』对象(包括实例化、处理依赖关系)。

  • 可以延时加载对象(仅用到时才创建对象)。

  • 促进编写可重用、可测试和松耦合的代码。

理解了IoC和DI之后,就引发了另一个问题,引用Phalcon文档描述如下:

如果这个组件有很多依赖, 我们需要创建多个参数的setter方法​​来传递依赖关系,或者建立一个多个参数的构造函数来传递它们,另外在使用组件前还要每次都创建依赖,这让我们的代码像这样不易维护

//创建依赖实例或从注册表中查找
$connection = new Connection();
$session = new Session();
$fileSystem = new FileSystem();
$filter = new Filter();
$selector = new Selector();

//把实例作为参数传递给构造函数
$some = new SomeComponent($connection, $session, $fileSystem, $filter, $selector);

// ... 或者使用setter

$some->setConnection($connection);
$some->setSession($session);
$some->setFileSystem($fileSystem);
$some->setFilter($filter);
$some->setSelector($selector);

假设我们必须在应用的不同地方使用和创建这些对象。如果当你永远不需要任何依赖实例时,你需要去删掉构造函数的参数,或者去删掉注入的setter。为了解决这样的问题,我们再次回到全局注册表创建组件。不管怎么样,在创建对象之前,它增加了一个新的抽象层:

class SomeComponent
{

    // ...

    /**
     * Define a factory method to create SomeComponent instances injecting its dependencies
     */
    public static function factory()
    {

        $connection = new Connection();
        $session = new Session();
        $fileSystem = new FileSystem();
        $filter = new Filter();
        $selector = new Selector();

        return new self($connection, $session, $fileSystem, $filter, $selector);
    }

}

瞬间,我们又回到刚刚开始的问题了,我们再次创建依赖实例在组件内部!我们可以继续前进,找出一个每次能奏效的方法去解决这个问题。但似乎一次又一次,我们又回到了不实用的例子中。

一个实用和优雅的解决方法,是为依赖实例提供一个容器。这个容器担任全局的注册表,就像我们刚才看到的那样。使用依赖实例的容器作为一个桥梁来获取依赖实例,使我们能够降低我们的组件的复杂性:

class SomeComponent
{

    protected $_di;

    public function __construct($di)
    {
        $this->_di = $di;
    }

    public function someDbTask()
    {

        // 获得数据库连接实例
        // 总是返回一个新的连接
        $connection = $this->_di->get('db');

    }

    public function someOtherDbTask()
    {

        // 获得共享连接实例
        // 每次请求都返回相同的连接实例
        $connection = $this->_di->getShared('db');

        // 这个方法也需要一个输入过滤的依赖服务
        $filter = $this->_di->get('filter');

    }

}

$di = new Phalcon\DI();

//在容器中注册一个db服务
$di->set('db', function() {
    return new Connection(array(
        "host" => "localhost",
        "username" => "root",
        "password" => "secret",
        "dbname" => "invo"
    ));
});

//在容器中注册一个filter服务
$di->set('filter', function() {
    return new Filter();
});

//在容器中注册一个session服务
$di->set('session', function() {
    return new Session();
});

//把传递服务的容器作为唯一参数传递给组件
$some = new SomeComponent($di);

$some->someTask();

这个组件现在可以很简单的获取到它所需要的服务,服务采用延迟加载的方式,只有在需要使用的时候才初始化,这也节省了服务器资源。这个组件现在是高度解耦。例如,我们可以替换掉创建连接的方式,它们的行为或它们的任何其他方面,也不会影响该组件。

参考文章

补充

很多代码背后,都是某种哲学思想的体现。

以下引用《面向模式的软件架构》卷1模式系统第六章模式与软件架构

软件架构支持技术(开发软件时要遵循的基本原则)

  1. 抽象

  2. 封装

  3. 信息隐藏

  4. 分离关注点

  5. 耦合与内聚

  6. 充分、完整、简单

  7. 策略与实现分离

    • 策略组件负责上下文相关决策,解读信息的语义和含义,将众多不同结果合并或选择参数值

    • 实现组件负责执行定义完整的算法,不需要作出与上下文相关的决策。上下文和解释是外部的,通常由传递给组件的参数提供。

  8. 接口与实现分离

    • 接口部分定义了组件提供的功能以及如何使用该组件。组件的客户端可以访问该接口。

    • 实现部分包含实现组件提供的功能的实际代码,还可能包含仅供组件内部使用的函数和数据结构。组件的客户端不能访问其实现部分。

  9. 单个引用点

    • 软件系统中的任何元素都应只声明和定义一次,避免不一致性问题。
      10. 分而治之

软件架构的非功能特性

  1. 可修改性

    • 可维护性

    • 可扩展性

    • 重组

    • 可移植性

  2. 互操作性

    • 与其它系统或环境交互

  3. 效率

  4. 可靠性

    • 容错:发生错误时确保行为正确并自行修复

    • 健壮性:对应用程序进行保护,抵御错误的使用方式和无效输入,确保发生意外错误时处于指定状态。

  5. 可测试性

  6. 可重用性

    • 通过重用开发软件

    • 开发软件时考虑重用

IOC和DI本质理解

IoC   IoC: Inversion of Control,控制反转, 控制权从应用程序转移到框架(如IoC容器),是框架共有特性   1、为什么需要IoC容器 1.1、应用...
  • cws1214
  • cws1214
  • 2016年08月04日 13:29
  • 2149

浅谈对Spring IOC以及DI的理解

浅谈对Spring IOC以及DI的理解
  • luoyepiaoxue2014
  • luoyepiaoxue2014
  • 2017年05月17日 19:40
  • 378

我对IoC/DI的理解

IoC   IoC: Inversion of Control,控制反转, 控制权从应用程序转移到框架(如IoC容器),是框架共有特性   1、为什么需要IoC容器 ...
  • u013700340
  • u013700340
  • 2014年12月23日 22:58
  • 904

谈谈Spring中的IOC、DI和AOP概念

看了大神的解释感觉受益匪浅,所以就将其保存,方便自己看,并最后总结出自己的理解 1. IOC(Inverse of Control):控制反转,也可以称为依赖倒置。      ...
  • Santiago_M
  • Santiago_M
  • 2017年05月05日 10:38
  • 332

IOC、DI、AOP是什么,为什么使用,怎么用

IOC、DI、AOP是什么,为什么使用,怎么用 Spring中加载配置文件的两种方法,可以加载多个配置文件吗?单例模式、和工厂模式定义 依赖注入的三种方法 1.IOC IOC为控制反转...
  • maidaogo
  • maidaogo
  • 2014年11月25日 09:58
  • 623

对IOC和DI的通俗理解

学习过spring框架的人一定都会听过Spring的IoC(控制反转) 、DI(依赖注入)这两个概念,对于初学Spring的人来说,总觉得IoC 、DI这两个概念是模糊不清的,是很难理解的,今天和大家...
  • fuzhongmin05
  • fuzhongmin05
  • 2017年02月19日 10:41
  • 387

如何理解IOC 依赖注入的思想(目前见过最好的对DI的描述)

1 IoC理论的背景 我们都知道,在采用面向对象方法设计的软件系统中,它的底层实现都是由N个对象组成的,所有的对象通过彼此的合作,最终实现系统的业务逻辑。 图1:软件系统中耦合的对象 如果我们打开...
  • xz0125pr
  • xz0125pr
  • 2015年10月14日 19:27
  • 2707

理解PHP 依赖注入|Laravel IoC容器

看Laravel的IoC容器文档只是介绍实例,但是没有说原理,之前用MVC框架都没有在意这个概念,无意中在phalcon的文档中看到这个详细的介绍,感觉豁然开朗,复制粘贴过来,主要是好久没有写东西了,...
  • realghost
  • realghost
  • 2014年06月27日 08:57
  • 15076

ioc 与 DI | 区别简介

看到一个对这个概念很好诠释的帖子,特转发过来供大家一起学习 转载地址http://www.iteye.com/topic/692793    在android butterknife...
  • java_goodstudy
  • java_goodstudy
  • 2016年10月02日 00:26
  • 893

控制反转(IOC)和依赖注入(DI)的区别

IOC   inversion of control  控制反转 DI   Dependency Injection  依赖注入 要理解这两个概念,首先要搞清楚以下几个问题: 参与者都有谁?依赖:...
  • doris_crazy
  • doris_crazy
  • 2014年01月16日 11:23
  • 25613
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:PHP程序员如何理解IoC/DI
举报原因:
原因补充:

(最多只允许输入30个字)