PHP 依赖注入(DI) 和 控制反转(IoC)

这两个概念对于 Laravel
的使用者来说应该并不陌生,尤其是当你希望扩展或者替换 Laravel
核心库的时候,理解和合理使用它们可以极大提升 Laravel
的战斗力。这里以创建一个自己的 ServiceProvider 为例理解 Inversion of
Control 和 Facade 在 Laravel 中的应用。

要想理解
PHP 依赖注入 和 控制反转 两个概念,就必须搞清楚如下的两个问题:

控制反转(Inversion of Control)

  • DI —— Dependency Injection 依赖注入
  • IoC —— Inversion of Control 控制反转

什么是 IoC

控制反转(Inversion of
Control,缩写为IoC),是面向对象编程中的一种设计原则,可以用来减低计算机代码之间的耦合度。其中最常见的方式叫做依赖注入(Dependency
Injection,简称DI),还有一种方式叫“依赖查找”(Dependency
Lookup)。通过控制反转,对象在被创建的时候,由一个调控系统内所有对象的外界实体,将其所依赖的对象的引用传递给它。
— 维基百科

简单说来,就是一个类把自己的的控制权交给另外一个对象,类间的依赖由这个对象去解决。依赖注入属于依赖的显示申明,而依赖查找则是通过查找来解决依赖。

什么是依赖注入

没有你我就活不下去,那么,你就是我的依赖。 说白了就是:

不是我自身的,却是我需要的,都是我所依赖的。一切需要外部提供的,都是需要进行依赖注入的。

Laravel 中的使用

注入一个类:

App::bind('foo', function($app)
{
    return new FooBar;
});

这个例子的意思是创建一个别名为 foo 的类,使用时实际实例化的是 FooBar

使用这个类的方法是:

$value = App::make('foo');

$value 实际上是 FooBar 对象。

如果希望使用单例模式来实例化类,那么使用:

App::singleton('foo', function()
{
    return new FooBar;
});

这样的话每次实例化后的都是同一个对象。

注入类的更多例子可以看 Laravel 官网

你可能会疑问上面的代码应该写在哪儿呢?答案是你希望他们在哪儿运行就写在哪儿。0
—— 0 知道写哪儿还用来看这种基础文章么!

依赖注入举例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
class Boy {
  protected $girl;
 
  public function __construct(Girl $girl) {
    $this->girl = $girl;
  }
}
 
class Girl {
  ...
}
 
$boy new Boy();  // Error; Boy must have girlfriend!
 
// 所以,必须要给他一个女朋友才行
$girl new Girl();
 
$boy new Boy($girl); // Right! So Happy!

从上述代码我们可以看到Boy强依赖Girl必须在构造时注入Girl的实例才行。

那么为什么要有依赖注入这个概念,依赖注入到底解决了什么问题?

我们将上述代码修正一下我们初学时都写过的代码:

1
2
3
4
5
6
7
class Boy {
  protected $girl;
 
  public function __construct() {
    $this->girl = new Girl();
  }
}

这种方式与前面的方式有什么不同呢?

我们会发现Boy的女朋友被我们硬编码到Boy的身体里去了。。。
每次Boy重生自己想换个类型的女朋友都要把自己扒光才行。

某天Boy特别喜欢一个LoliGirl ,非常想让她做自己的女朋友。。。怎么办?
重生自己。。。扒开自己。。。把Girl扔了。。。把 LoliGirl塞进去。。。

1
2
3
4
5
6
7
8
9
10
11
12
class LoliGirl {
 
}
 
class Boy {
  protected $girl;
 
  public function __construct() {
      //  $this->girl = new Girl();  // sorry...
      $this->girl = new LoliGirl();
  }
}

某天 Boy迷恋上了御姐….Boy 好烦。。。

是不是感觉不太好?每次遇到真心相待的人却要这么的折磨自己。。。

Boy说,我要变的强大一点。我不想被改来改去的!

好吧,我们让Boy强大一点:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
interface Girl {
  // Boy need knows that I have some abilities.
}
 
class LoliGril implement Girl {
  // I will implement Girl's abilities.
}
 
class Vixen implement Girl {
  // Vixen definitely is a girl, do not doubt it.
}
 
class Boy {
  protected $girl;
 
  public function __construct(Girl $girl) {
    $this->girl = $girl;
  }
}
 
$loliGirl new LoliGirl();
$vixen new Vixen();
 
$boy new Boy($loliGirl);
$boy new Boy($vixen);

Boy很高兴,终于可以不用扒开自己就可以体验不同的人生了。。。So Happy!

澳门新葡亰网址,服务提供器 (Service Providers)

为了让依赖注入的代码不至于写乱,Laravel 搞了一个 服务提供器(Service
Provider)的东西,它将这些依赖聚集在了一块,统一申明和管理,让依赖变得更加容易维护。

依赖注入方式

1、构造器 注入

1
2
3
4
5
6
7
8
<?php
class Book {
  private $db_conn;
  
  public function __construct($db_conn) {
    $this->db_conn = $db_conn;
  }
}

2、setter 注入

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
<?php
class Book {
    private $db;
    private $file;
 
    function setdb($db) {
        $this->db = $db;
    }
 
    function setfile($file) {
        $this->file = $file;
    }
}
 
class file {
}
 
class db {
}
 
// ...
 
class test {
    $book new Book();
    $book->setdb(new db());
    $book->setfile(new file());
}

小结:

因为大多数应用程序都是由两个或者更多的类通过彼此合作来实现业务逻辑,这使得每个对象都需要获取与其合作的对象(也就是它所依赖的对象)的引用。如果这个获取过程要靠自身实现,那么将导致代码高度耦合并且难以维护和调试。

所以才有了依赖注入的概念,依赖注入解决了以下问题:

  • 依赖之间的解耦
  • 单元测试,方便Mock

上面俩种方法代码很清晰,但是当我们需要注入很多个依赖时,意味着又要增加很多行,会比较难以管理。

比较好的解决办法是
建立一个class作为所有依赖关系的container,在这个class中可以存放、创建、获取、查找需要的依赖关系。先来了解一下IOC的概念

Laravel 中的使用

定义一个服务提供器:

use IlluminateSupportServiceProvider;

class FooServiceProvider extends ServiceProvider {

    public function register()
    {
        $this->app->bind('foo', function()
        {
            return new Foo;
        });
    }

}

这个代码也不难理解,就是申明一个服务提供器,这个服务提供器有一个 register的方法。这个方法实现了我们上面讲到的依赖注入。

当我们执行下面代码:

App::register('FooServiceProvider');

我们就完成一个注入了。但是这个还是得手动写,所以怎么让 Laravel
自己来做这事儿呢?

我们只要在 app/config/app.php 中的 providers 数组里面增加一行:

'providers' => [
    …
       ‘FooServiceProvider’,
],

这样我们就可以使用 App::make(‘foo’) 来实例化一个类了。

你不禁要问了,这么写也太难看了吧?莫慌,有办法。

控制反转 (Inversion Of Control, IOC)

控制反转 是面向对象编程中的一种设计原则,可以用来减低计算机代码之间的耦合度。其中最常见的方式叫做 依赖注入(Dependency
Injection, DI), 还有一种叫”依赖查找”(Dependency
Lookup)。通过控制反转,对象在被创建的时候,由一个调控系统内所有对象的外界实体,将其所依赖的对象的引用传递给它。也可以说,依赖被注入到对象中。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
<?php
 
class Ioc {
    protected $db_conn;
 
    public static function make_book() {
        $new_book new Book();
        $new_book->set_db(self::$db_conn);
        //...
        //...
        //其他的依赖注入
        return $new_book;
    }
}

此时,如果获取一个book实例,只需要执行$newone = Ioc::makebook();

以上是container的一个具体实例,最好还是不要把具体的某个依赖注入写成方法,采用registry注册,get获取比较好

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
<?php
/**
 * 控制反转类
 */
class Ioc {
    /**
     * @var array 注册的依赖数组
     */
    protected static $registry array();
 
    /**
     * 添加一个 resolve (匿名函数)到 registry 数组中
     *
     * @param string  $name    依赖标识
     * @param Closure $resolve 一个匿名函数,用来创建实例
     * @return void
     */
    public static function register($name, Closure $resolve) {
        static::$registry[$name] = $resolve;
    }
 
    /**
     * 返回一个实例
     *
     * @param string $name 依赖的标识
     * @return mixed
     * @throws Exception
     */
    public static function resolve($name) {
        if (static::registered($name)) {
            $name static::$registry[$name];
            return $name();
        }
 
        throw new Exception("Nothing registered with that name");
    }
 
    /**
     * 查询某个依赖实例是否存在
     *
     * @param string $name
     * @return bool
     */
    public static function registered($name) {
        return array_key_exists($namestatic::$registry);
    }
}

现在就可以通过如下方式来注册和注入一个

1
2
3
4
5
6
7
8
9
10
11
<?php
Ioc::register("book"function () {
    $book new Book();
    $book->setdb('db');
    $book->setfile('file');
 
    return $book;
});
 
// 注入依赖
$book = Ioc::resolve('book');

发表评论

电子邮件地址不会被公开。 必填项已用*标注

相关文章

网站地图xml地图