作為一名oop程序員，設計原則是必須知道的知識：單一職責，開閉原則，依賴倒置，接口隔離，替換法則。
在看【Head First】一書時，突然對依賴倒置有了一些簡單的理解。
先看依賴倒置的定義：要依賴抽象，不要依賴具體類。
其意思是具體類要依賴抽象，抽象不應該依賴具體類，更擴展一點就是說具體類也盡量不要依賴具體類。
首先，何為具體類，我的理解，具體類應該就是某個具體的對象，是對現實中的實物或其他的一種反應，即就是類的實例，具體代碼上就是通過new出來的對象。
比如Object obj = new Object（）;這樣便產生了一個具體對象。而若是直接在一個對象中new另一個對象，則這兩個對象依賴在了一起，增加了這個類的耦合性。
讓我們先回到依賴倒置上！這個倒是有點像面向接口編程，但是這里更強調的“抽象”，這種抽象可以是一個接口，也可以是一個抽象類。這個原則說明了：不能讓
“高層組件”依賴“低層組件”，而且兩者都應該依賴於抽象。
我來舉一個例子。如果我們要開一家奶茶店，那我們首先想到的是什么呢，肯定是想到在什么地方開奶茶店，要多少員工，然后才是賣什么奶茶。
沒錯，我們的思考方法一般都是從頂端 開始，然后往下才是具體類。但是要開奶茶店又要想怎么生產奶茶，這是一件很要命的事情。對於一個奶茶店主來說，並不
想理會奶茶這寫具體類，否則奶茶店將全部依賴這些奶茶具體類。這時候就要倒置我們的思想，先從低端開始，從奶茶開始，抽象出一個奶茶抽象。
這時候“奶茶店”就是“高層組件”，各種奶茶就是“低層組件”。由於奶茶店是如果買奶茶的具體類，則奶茶店對全部奶茶有了依賴，高層組件與低層有了依賴關系。
這個模式告訴我們：我們應該依賴抽象類，而不應該具體類，無論是高層組件還是低層組件都應該如此。
那么我們就想到定義一個奶茶的抽象類型，即為所有的奶茶提供一個抽象，而奶茶店則只需要面對這個抽象，而不用去管這個抽象的具體類是什么。即奶茶店只需
要專注於賣奶茶，收錢找錢什么的，而不用管具體奶茶是什么。這樣奶茶店就依賴於奶茶的抽象，而不是依賴奶茶的具體類。
class TeaShop{ public void sell(){ Tea tea = new SimpleTea(); tea.produce(); } }
這樣雖然我們創建了一個抽象，但我們 仍在代碼中，實際的創建的具體類（SimpleTea），所以，這樣的抽象並不能實現低耦合。
這時候，可以使用工廠模式來對代碼進行進一步重構，來創建一個TeaFactory;為了使這個工廠更具有擴展型，我們來對工廠進行抽象。
public class abstract TeaFactory{ public Tea makeTea(String type){ createTea(type).produce(); } public abstract Tea createTea(String tea); }
這時候我們在鄭州開了個奶茶店，則創建一個鄭州奶茶工廠。
public class ZZTeaFactory extends TeaFacory{ public Tea createTea(String tea){ if(tea.equles("simple")){ return new SimpleTea(); }else{ return new OtherTea(); } } }
這樣就實現了一個奶茶的工廠模式。那么通過奶茶店進行點選奶茶的時候：
class TeaShop{ public void sell(){ TeaFactory factory = new ZZTeaFactory(); Tea tea = factory.makeTea("simple"); } }
我們通過工廠模式將奶茶店與奶茶進行解耦，而且通過工廠模式也大大提高了程序的可擴展型，比如我們如果要在洛陽也開一家奶茶店的話，但是洛陽奶茶店所賣的
奶茶與鄭州的奶茶並不一樣，這時候我們只要實現一個洛陽的奶茶工廠，實現奶茶工廠的抽象即可，實現了開閉原則。通過這種將實例化延遲到子類中進行的方式。
在次回到依賴倒置上，為什么使用工廠模式就實現了依賴倒置了呢？
首先我們畫一下類圖：
這時候高層組件（TeaShop）和低層組件（SimpleTea，OtherTea）都依賴於Tea抽象。想要遵循依賴倒置原則，工廠方法並非是唯一的方法，但卻是
最有效的方法。
如何避免違反依賴倒置原則：
1.變量不可以持有具體類的引用。（持有類的引用即通過new出來的對象）
2.不要讓類派生自具體類。（如果派生自具體類，就產生了依賴，請派生自一個抽象）
3.不要覆蓋基類中已實現的方法。
但是如果隨時都要遵循這個原則，是不可能的，因為我們如果不new一個對象，那么我們是什么都寫不成的。所以這個原則也有適用行。如果有一個不像是會改變
的類，則具體類一點問題都沒有的。而常改變的 類則可以使用一些技巧。
永遠不變的是變化本身，我們使用設計原則，設計模式，則是為了更好的應對變化，封裝變化。
參考資料:《Head First 設計模式》