? ? ? ?依賴注入(Injecting dependencies)經常聽起來會讓人感覺到很難以理解，會讓大家感覺這是很復雜的編程技術，但是事實上并不是這樣，依賴注入非常方便使用，它會讓你的程序非常便于理解，同時也更容易進行測試。

依賴注入的工作方式：

? ? ? ?任何好的程序都是由很多互相協作的類來實現復 雜的邏輯的。在傳統的使用方法中，每個對象都會把自己的引用傳遞給它協作的對象，但是這樣會造成對象間的高度耦合，同時不容易對程序進行測試。接下來我們看一個例子：

? ? ? ?從這個例子中，我們可以看出來，DamselRescuingKnight在容器中創造了他自己的?RescueDamselQuest請求，不過這使得DamselRescuingKnight和?RescueDamselQuest緊緊耦合，同時也限制了騎士能做的事情，如果美少女需要救援，騎士可以輕松勝任，但是如果惡龍需要治服，或者...其他各種事情，這時騎士根本無能為力。除此之外，這樣的設計也很難去進行測試，在這個例子中當?embarkOnQuest()被調用，又調用到?embark()到時，需要我們在?embark()中插入斷點，但是這很難實現，也就是說我們沒法很好的測試DamselRescuingKnight的功能。

? ? ? ?耦合是一個雙頭怪獸，一方面，它高耦合的代碼很難測試，很難復用，同時也很難理解。而且它還可能造成whack-a-mole這樣的bug(就像我們在打鼴鼠時一樣，我們注重一處的代碼，可是在其他地方卻引發了更多的bug)，另一方面，其實一些適當的耦合其實也是有用的，完全的飛耦合讓我們很難實現有些功能。為了能夠高效的開發，類之間必須能夠互相了解， 適當的耦合是必須的，但是必須要控制好這個度。通過使用DI，對象所需要的依賴會在創建時由熟悉各個對象的第三方提供，也就是將每個對象需要的依賴在它在創建時注入給它。接下來我們將看到一個真正全能的騎士，他不僅能夠擊敗邪惡勢力拯救美少女，同時也能夠下廚做美食，他能夠回應你的各種請求。

? ? ? ?如上面所示，BraveKnight并不像DamselRescuingKnight，它不需要創建任何請求，取而代之的是在構造器中或獲取它需要的request。這種DI一般被稱為constructor injection。不僅如此，上面的quest如果是個接口，那么我們可以實現任何形式的request。

? ? ? ?重點是BraveKnight不需要和任何已實現的Quest耦合，它并不需要去了解這個接口是如何實現的。這就是DI最重要的特性-----低耦合性。這個特性的一個很重要的用途是我們在進行測試時可以可mock掉這個接口。而在高耦合的設計中這很難實現。

? ? ? ?在這里，使用了叫做Mockitode的mock對象framework，通過它，我們可以創造一個實現了Quest接口的mock，利用來實例化BraveKnight，并且通過構造函數注入mockquest，這時我們就可以調用embarkOnQuest()方法，并且去驗證embark()是否確實被調用了一次。