如果是第一次接觸這個概念，可能會一時沒有頭緒，網上的各種解釋可能會讓你更加混亂，并覺得它沒那么簡單。其實依賴注入本身是單純、簡單的。

[[287085]]

簡單來說，依賴注入是一種方式、方法或者說手段，是讓被注入者和注入者之間建立關聯的手段。

依賴注入的目的是松耦合，是交互對象之間的松耦合。

今天，小芯帶來的文章主要描述了關于進行依賴注入(dependency injection，DI)的五大原則，具有強大的實用性。

遵循這五大基本思想，在進行DI時，你就無需額外花功夫于編寫代碼啦，超方便。

五大基本原則

一、保持簡單的構造函數

構造函數應該保持簡單。類的構造函數不應該做任何工作——也就是說，除了檢查null、創建可創建類和存儲依賴項供以后使用之外，它們不應該做任何事情。

它們不應該包含任何編碼邏輯。一個類構造函數中沒有檢查null的if子句，那么這個類就會被分成兩個類。(有不涉及if語句檢查nil-value參數的方法。)

復雜的構造函數表明類做的工作太多。保持構造函數簡短、簡單且無邏輯。

二、不要假設接口是抽象的

接口很不錯，我一直對它贊不絕口。然而，重要的是要認識到并非每個接口都是抽象的。

例如，如果接口是公共部分類的精確表示，實際上并沒有抽象任何東西，對嗎? (這些接口被稱為頭接口，類似于c++的頭文件)。從類中提取的接口可以很容易地單獨與該類緊密耦合，使得接口作為抽象類毫無用處。

最后，抽象類可能是有漏洞的——也就是說，它們可以揭示關于實現類的特定細節。有漏洞的抽象類通常也與特定的實現類綁定在一起。

三、不要對實現類做任何假設

當然，如果沒有實現類，接口是毫無用處的。但是，作為開發人員不應對實現類做任何假設。

只該根據接口生成的契約進行編碼。你可能已經編寫了實現，但不應該在考慮實現的情況下針對接口編寫代碼。換句話說，針對接口的代碼就好像一個全新的、更好的接口實現。

一個設計良好的接口會告訴你需要做什么以及如何使用它。該接口的實現對你使用該接口是無關緊要的。

四、針對抽象類而非實現類的代碼

該短語出自“四人幫”之一的埃里希·伽瑪(Erich Gamma)(《設計模式》一書的作者)，是一個重要的想法。如果只能教給新的開發者一件事，那就是這句格言。

抽象類是靈活的——通常是接口但不總是(見下文)。

接口(或抽象類)可以通過多種方式實現。可以在實現完成前對接口進行編碼。如果對實現進行編碼，將創建一個緊密耦合且不靈活的系統。不要把自己限定在單一的實現中。相反，使用抽象，編出可擴展、可重用及靈活的代碼。

五、永遠不要創建不該創建的東西

類別應該遵循單一職責原則——即一個類只做一件事。

如此，就不應再創建事物，否則是做了兩件事。相反，應根據其所需的功能創建和提供該功能。

可創建類 vs 可注入類

那么應該創建什么呢?

我們應該關注兩種不同的對象:可創建類和可注入類。

可創建類指應該繼續創建的類。是常見的運行庫或實用程序類。

通常運行庫中的類被認為是可創建類。這些類應該被創建，而非注入。它們的使用期限很短，通常不超過一種方法的范圍。可創建類在所有類中是必不可少的，可以在構造函數中創建。一個可創建類只能傳遞給構造函數的另一個類。

另一方面，可注入類是我們永遠不想直接創建的類。也是不希望硬編碼依賴項的類，應始終通過DI傳遞。

在構造函數中，它們通常被作為是依賴項。根據以上規則，可注入類應該依賴接口注入的類，而非實例。

它通常是作為業務邏輯而編寫的類。隱藏在抽象類后，通常是接口。還要注意，可注入類可在構造函數中請求其他的可注入類。

適當使用DI對代碼的意義重大。做好這件事并不難，但確實需要有遠見、計劃和設計。

但是，在維護代碼時，小小的工作將帶來大大的回報。修復松散耦合的代碼是維護人員的夢想，我們要努力編寫這樣的代碼，相信事后會收獲滿滿。