摘要：在中使用解耦，有兩種注入方式構造函數注入屬性注入。對象的實例化解析依賴信息該方法實質上就是通過的反射機制，通過類的構造函數的參數分析他所依賴的單元。

傳統軟件設計中，上層代碼依賴于下層代碼，當下層出現變動時，上層也要相應變化。

DIP的核心思想是：上層定義接口，下層實現這個接口，從而使的下層依賴于上層，降低耦合。

IoC是DIP的具體思路做法，IoC的核心是將類所依賴的下層單元的實例化過程交由第三方來實現。

一個簡單的特征：類中不對所依賴的單元有諸如$component = new yiicomponentSomeClass()的實例化語句。

DI是IoC的一種設計模式。

DI的核心是把類所依賴的單元的實例化過程，放到類的外面去實現。

當項目比較大時，依賴關系可能很復雜。而IoCC提供了動態地創建、注入依賴單元，映射依賴關系等功能。Yii設計了一個yiidiContainer來實現了DI Container。

SL時IoC的另一種實現方式，其核心是把所有可能用到的依賴單元交給SL進行實例化和操作，把類對依賴單元的依賴，轉換成類對SL的依賴。

Yii2通過DI容器，實現了SL。

DI在web中，常見于使用第三方服務實現特定功能（例：發郵件，推微博）。

假設要實現當訪客在博客上發表評論后，向博文的作者發送Email的功能，通常代碼如下：

// 為郵件服務定義抽象層
interface EmailSenderInterface{
    public function send();
}

// 定義Gmail服務
class GmailSender implements EmailSenderInterface{
    public function send()
}

// 定義評論類
class Comment extend yiidbActiveRecord{
    private $_eEmailSender;
    public function init(){
        $this->_eMailSender = GmailSender::getInstance();
    }
    
    public function afterInsert(){
        $this->_eMailSender->send();
    }
}

這個常見的設計方法有一個問題：Comment對于GmailSender的依賴，突然有一天不用Gmail了，那么必須修改init里的實例化語句。

同時，這個類的復用程度不高，下一個不用Gmail服務的項目，還需要再修改，或者直接去掉該郵件服務。

在Yii中使用DI解耦，有兩種注入方式：構造函數注入、屬性注入。

class Comment extend yiidbActiveRecord{
    private $_eMailSender;
    public function __construct($emailSender){
        $this->_eMailSender = $emailSender;
    }
    
    public function afterInsert(){
        $this->_eMailSender->send();
    }
}

// 實例化兩種不同的郵件服務，都繼承了基類
$sender1 = new GmailSender();
$sender2 = new MyEmailSender();

$comment1 = new Comment($sender1);
$comment1.save();
$comment2 = new Comment($sender2);
$comment2.save();

class Comment extend yiidbActiveRecord{
    private $_eMailSender;
    
    public function setEmailSender($value){
        $this->_eMailSender = $value;
    }
    
    public function afterInsert(){
        $this->_eMailSender->send();
    }
}

實際上，依賴注入就是從外面，將實例打到內部，從而完成整體的功能。

打入的方式有兩種，一種是初始化是通過傳參。另外一種是調用內部set方法，將實例注入屬性，內部方法會調用該屬性，進而完成功能。

一個Web應用的某一組件會依賴于若干單元，這些單元又有可能依賴于基本單元，從而形成依賴嵌套的情形。

那么，這些依賴單元的實例化、注入過程的代碼就會又長又繁雜，前后關系也需要注意。

yiidiContainer，通過DI容器，可以更好的管理對象及對象的所有依賴，以及這些依賴的依賴，進行實例化和配置。

Yii使用yiidiInstance來表示容器中的東西。Yii還將這個類用于Service Locator。

該Instance本質上是DI容器中對于某一個類實例的引用，它的代碼看起來并不復雜：

class Instance{
    // 保存類名，借口名，別名
    public $id;
    
    protected function __construct($id){}
    
    // 靜態方法創建一個Instance實例
    public static function of($id){
        return new static($id);
    }
    
    // 將引用解析成實際的對象，并確保這個對象的類型
    public static function ensure($reference, $type = null, $container = null){}
    
    // 獲取這個實例所引用的實際對象，事實上它調用的是yiidiContainer::get()
    public function get($container = null){}
}

該Instance：

表示的是容器中的內容，代表的是對于實際對象的引用。

DI容器可以通過他獲取所引用的實際對象。

屬性id表示實例的類型.

// 用于保存單例Singleton對象，以對象類型為鍵
private $_singletons = [];

// 用于保存依賴的定義，以對象類型為鍵
private $_definitions = [];

// 用于保存構造函數的參數，以對象類型為鍵
private $_params = [];

// 用于緩存ReflectionClass對象，以類名或接口名為鍵
private $_reflections = [];

// 用于緩存依賴信息，以類名或接口名為鍵
private $_dependencies = [];

使用DI容器，首先要告訴容器，類型及類型之間的依賴關系，聲明這一關系的過程稱為注冊依賴。

使用：yiidiContainer::set() & yiidiContainer::setSinglton()

在DI容器中，依賴關系的定義是唯一的。 后定義的同名依賴，會覆蓋前面定義好的依賴。

對于 set() 而言，還要刪除 $_singleton[] 中的同名依賴。 對于 setSingleton() 而言，則要將 $_singleton[] 中的同名依賴設為 null ， 表示定義了一個Singleton，但是并未實現化。

$container = new yiidiContainer;

// 直接以一個類名注冊一個依賴
// $_definition["yiidbConnection"] = "yiidbConnection";
$container->set("yiidbConnection");

// 注冊一個接口，當一個類依賴于該接口時，定義中的類會自動被實例化，并給有依賴需要的類使用
// $_definition["yiimailMailInterface"] = "yiiswiftmailerMailer";
$container->set("yiimailMailInterface", "yiiswiftmailerMailer");

// 注冊一個別名
$container->set("foo", "yiidbConnection");

// 用callable來注冊一個別名，每次引用這個別名時，該callable都會被調用
$container->set("db", function($container, $params, $config){
    return new yiidbConnectin($config);
});

你可以這么理解：依賴的定義只是往特定的數據結構中寫入有關的信息。

DI容器中裝了兩類實例，一種是單例，每次向容器索取單例類型的實例時，得到的都是同一個實例； 另一類是普通實例，每次向容器索要普通類型的實例時，容器會根據依賴信息創建一個新的實例給你。

yiidiContainer::getDependencies()

該方法實質上就是通過PHP5的反射機制，通過類的構造函數的參數分析他所依賴的單元。然后統統緩存起來備用。

另一個與解析依賴信息相關的方法就是 yiidiContainer::resolveDependencies() 。

$_reflections以類（接口、別名）名為鍵， 緩存了這個類（接口、別名）的ReflcetionClass。一經緩存，便不會再更改。

$_dependencies以類（接口、別名）名為鍵，緩存了這個類（接口、別名）的依賴信息。

這兩個緩存數組都是在yiidiContainer::getDependencies()中完成。這個函數只是簡單地向數組寫入數據。

經過yiidiContainer::resolveDependencies()處理，DI容器會將依賴信息轉換成實例。 這個實例化的過程中，是向容器索要實例。也就是說，有可能會引起遞歸。

yiidiContainer::build()：

DI容器只支持yiiaseObject類。也就是說，你只能向DI容器索要 yiiaseObject 及其子類。 再換句話說，如果你想你的類可以放在DI容器里，那么必須繼承自 yiiaseObject 類。 但Yii中幾乎開發者在開發過程中需要用到的類，都是繼承自這個類。 一個例外就是上面提到的 yiidiInstance 類。但這個類是供Yii框架自己使用的，開發者無需操作這個類。

遞歸獲取依賴單元的依賴在于dependencies = $this－>resolveDependencies($dependencies, $reflection)中。

getDependencies() 和 resolveDependencies() 為 build() 所用。 也就是說，只有在創建實例的過程中，DI容器才會去解析依賴信息、緩存依賴信息。

獲取依賴實例化對象使用yiidiContainer::get()，

在整個實例化過程中，一共有兩個地方會產生遞歸：一是 get() ， 二是 build() 中的 resolveDependencies() 。

namespace appmodels;

use yiiaseObject;
use yiidbConnection;

interface UserFinderInterface{
    function findUser();
}

class UserFinder extends Object implements UserFinderInterface{
    public $db;
    
    // 依賴于Connection
    public function __construct(Connection $db, $config = []){
        $this->db = $db;
        parent::__construct($config);
    }
    
    pubic function findUser(){}
}

class UserLister extends Object{
    public $finder;
    
    // 依賴接口
    public function __construct(UserFinderInterface $finder, $config = []){
        $this->finder = $finder;
        parent::__construct($config);
    }
}

一般做法：

$db = new yiidbConnection(["dsn" => "..."]);
$finder = new UserFinder($db);
$lister = new UserLister($finder);

團隊開發的時候，很多類需要制定為單例模式，否則N個模塊有N個服務就。。

上部代碼改成DI容器

use yiidiContainer;

$container = new Container;

$container->set("yiidbConnection", [...]);

$container->set("appmodelsUserFinderInterface", [
    "class" => "appmodelsUserFinder",
]);

$container->set("userLister", "appmodelsUserLister");

// 獲取該別名class的實例
$lister = $container->get("userLister");

DI容器維護了兩個緩存數組 $_reflections 和 $_dependencies 。這兩個數組只寫入一次，就可以無限次使用。 因此，減少了對ReflectionClass的使用，提高了DI容器解析依賴和獲取實例的效率。

但是，對于典型的Web應用而言， 有許多模塊其實應當注冊為單例的，比如上面的 yiidbConnection。一個Web應用一般使用一個數據庫連接，特殊情況下會用多幾個，所以這些數據庫連接一般是給定不同別名加以區分后， 分別以單例形式放在容器中的。因此，實際獲取實例時，步驟會簡單得。對于單例， 在第一次get()時，直接就返回了。而且，省去不重復構造實例的過程。

參考

http://martinfowler.com/articles/injection.html

http://www.digpage.com/di.html