本文首發於本人微博。這裡做備份整理。
閱讀完spring in action 第四版 前半部的一些總結。
一些關於 DI 的理解。
什麼是依賴注入呢？其實這個名稱是英文直譯，到是不存在什麼因為翻譯不好所以理解不對的情況。（耦合這個詞或許令人難以理解。）
去年嘗試看了，今年上半年嘗試看了，可能對於物件導向程式設計的理解不到家，當時一直是無法很好的理解。
今天又認真看了，所以乾脆記下來自己的理解吧。
肯定會有一些問題，也望懂行的家人們補充。
其實就是一個關於主動權的問題。
設想我們設計一個程式，大的整體實際上是有無數的小的模組構成的。其中包含無數個方法、函式。
想要一個程式的邏輯是貫通的，那麼這些個方法、函式肯定都不是一座“孤島”。
而連線這些方法、函式的方式有很多種，不存在什麼對錯，因為程式碼不報錯就是第一步成功對吧？但更加重要的還是，一份程式碼更新、維護起來的費勁程度。
不好的連線的方式會導致我們需要花費更多的時間去進行維護。
因為方法之間的聯絡太過緊密了，我們無法很好的保證修改這裡的程式碼，別的地方的程式碼不會崩掉。
這樣的程式我們稱之為耦合性強的程式。牽一髮而動全身，對程式設計師維護程式而言是一種極其痛苦的體驗。
想要減少程式碼維護的難度，我們需要對程式進行重新的設計了，至少說明先前多個方法之間的連線方式是不太合理的。
想要降低維護難度，其實只需要讓方法與方法之間的連線不那麼緊不就好了？但是這肯定不是絕對的，因為完全沒有聯絡的方法是無法組成一個程式的。
因此我們要做的只能是減少聯絡，而不是完全不聯絡。
這就是所謂的降低耦合度。
那麼要怎麼做到降低耦合度呢？
這裡來看兩份相對簡單的程式碼吧。（是spring in action 第四版的例子，此書的第5版寫的不太好，這裡推薦第4版）
例子
由我來講解關於這個程式碼的故事吧。
現在我們要製作一款遊戲，是關於中世紀的冒險遊戲。
你現在擁有騎士這一角色，你可以為給騎士釋出任務。騎士在執行任務之前要先彙報自己開始了任務。
那麼，我現在要建立一個能夠執行營救少女這項任務的騎士。
那麼這裡有兩份程式碼。分別是 p1 和 p2 。
我們首先來閱讀p1：
我是一個專門接收營救少女任務的騎士。
我可以建立關於營救少女的任務。
也可以宣佈自己開始任務了。
似乎挺對的，沒發現什麼問題。
我又改變了需求，我希望有一位騎士可以幫我解決其他的問題，比如除惡龍。
那這樣的話，豈不是要再生成一個專門用來除惡龍的騎士？
嗯，這麼想也沒錯。但是程式碼是否要寫很多？而且不覺得很奇怪麼，只要任務不同就要迭代一次程式碼，更新出一位新的騎士，這樣下來，程式碼維護起來相當的麻煩。
那麼我們要怎麼修改這份程式碼，讓它能夠扛住更多的任務？
一起來看看p2吧。
我是一位騎士，我接受並響應任務。
沒錯，現在我們無所謂到底是什麼樣的騎士，我們也不需要在意到底什麼什麼樣子的任務了，因為我們要做的只有，接收任務並響應“我開始任務了！”就夠了。
至於到底是什麼任務？我不需要知道，為我提供就好了，我自己接收。
這樣的程式碼，適合各種情況（萬能的騎士至少比 p1 這種只能做哪件事的騎士靠譜吧。）
總結
因此依賴注入（DI）本質其實就是，創造出方法與方法之間連線較少的程式碼。（降低耦合度）
而最常用的操作便是：
主動權不在我，你給我提供現成的就好了！我需要這東西的時候直接用就好了，而不是我需要這東西的時候，我還得自己現把它做出來！
本作品採用《CC 協議》，轉載必須註明作者和本文連結