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

[[287085]]

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

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

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

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

五大基本原則

一、保持簡單的構造函數(shù)

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

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

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

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

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

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

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

三、不要對實現(xiàn)類做任何假設

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

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

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

四、針對抽象類而非實現(xiàn)類的代碼

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

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

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

五、永遠不要創(chuàng)建不該創(chuàng)建的東西

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

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

可創(chuàng)建類 vs 可注入類

那么應該創(chuàng)建什么呢?

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

可創(chuàng)建類指應該繼續(xù)創(chuàng)建的類。是常見的運行庫或?qū)嵱贸绦蝾悺?/p>

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

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

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

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

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

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