掌握依賴注入5大原則，無需額外編代碼！

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

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

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

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

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

一、保持簡單的構造函數

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

可建立類 vs 可注入類

那麼應該建立什麼呢?

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

可建立類指應該繼續建立的類。 是常見的運作庫或實用程式類。

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

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

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

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

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

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