作為一名oop程式設計師，設計原則是必須知道的知識：單一職責，開閉原則，依賴倒置，介面隔離，替換法則。
在看【head first】一書時，突然對依賴倒置有了一些簡單的理解。
先看依賴倒置的定義：要依賴抽象，不要依賴具體類。
其意思是具體類要依賴抽象，抽象不應該依賴具體類，更擴充套件一點就是說具體類也盡量不要依賴具體類。
首先，何為具體類，我的理解，具體類應該就是某個具體的物件，是對現實中的實物或其他的一種反應，即就是類的例項，具體**上就是通過new出來的物件。
比如object obj = new object（）;這樣便產生了乙個具體物件。而若是直接在乙個物件中new另乙個物件，則這兩個物件依賴在了一起，增加了這個類的耦合性。
讓我們先回到依賴倒置上！這個倒是有點像面向介面程式設計，但是這裡更強調的「抽象」，這種抽象可以是乙個介面，也可以是乙個抽象類。這個原則說明了：不能讓
「高層元件」依賴「低層元件」，而且兩者都應該依賴於抽象。
我來舉乙個例子。如果我們要開一家奶茶店，那我們首先想到的是什麼呢，肯定是想到在什麼地方開奶茶店，要多少員工，然後才是賣什麼奶茶。
沒錯，我們的思考方法一般都是從頂端 開始，然後往下才是具體類。但是要開奶茶店又要想怎麼生產奶茶，這是一件很要命的事情。對於乙個奶茶店主來說，並不
想理會奶茶這寫具體類，否則奶茶店將全部依賴這些奶茶具體類。這時候就要倒置我們的思想，先從低端開始，從奶茶開始，抽象出乙個奶茶抽象。
這時候「奶茶店」就是「高層元件」，各種奶茶就是「低層元件」。由於奶茶店是如果買奶茶的具體類，則奶茶店對全部奶茶有了依賴，高層元件與低層有了依賴關係。
這個模式告訴我們：我們應該依賴抽象類，而不應該具體類，無論是高層元件還是低層元件都應該如此。
那麼我們就想到定義乙個奶茶的抽象型別，即為所有的奶茶提供乙個抽象，而奶茶店則只需要面對這個抽象，而不用去管這個抽象的具體類是什麼。即奶茶店只需
要專注於賣奶茶，收錢找錢什麼的，而不用管具體奶茶是什麼。這樣奶茶店就依賴於奶茶的抽象，而不是依賴奶茶的具體類。
class這樣雖然我們建立了乙個抽象，但我們 仍在**中，實際的建立的具體類（******tea），所以，這樣的抽象並不能實現低耦合。teashop
}
這時候，可以使用工廠模式來對**進行進一步重構，來建立乙個teafactory;為了使這個工廠更具有擴充套件型，我們來對工廠進行抽象。
public這時候我們在鄭州開了個奶茶店，則建立乙個鄭州奶茶工廠。class
abstract
teafactory
public
abstract
tea createtea(string tea);
}
public這樣就實現了乙個奶茶的工廠模式。那麼通過奶茶店進行點選奶茶的時候：class zzteafactory extends
teafacory
else }
}
class我們通過工廠模式將奶茶店與奶茶進行解耦，而且通過工廠模式也大大提高了程式的可擴充套件型，比如我們如果要在洛陽也開一家奶茶店的話，但是洛陽奶茶店所賣的teashop
}
奶茶與鄭州的奶茶並不一樣，這時候我們只要實現乙個洛陽的奶茶工廠，實現奶茶工廠的抽象即可，實現了開閉原則。通過這種將例項化延遲到子類中進行的方式。
在次回到依賴倒置上，為什麼使用工廠模式就實現了依賴倒置了呢？
首先我們畫一下類圖：
這時候高層元件（teashop）和低層元件（******tea，othertea）都依賴於tea抽象。想要遵循依賴倒置原則，工廠方法並非是唯一的方法，但卻是
最有效的方法。
如何避免違反依賴倒置原則：
1.變數不可以持有具體類的引用。（持有類的引用即通過new出來的物件）
2.不要讓類派生自具體類。（如果派生自具體類，就產生了依賴，請派生自乙個抽象）
3.不要覆蓋基類中已實現的方法。
但是如果隨時都要遵循這個原則，是不可能的，因為我們如果不new乙個物件，那麼我們是什麼都寫不成的。所以這個原則也有適用行。如果有乙個不像是會改變
的類，則具體類一點問題都沒有的。而常改變的 類則可以使用一些技巧。
永遠不變的是變化本身，我們使用設計原則，設計模式，則是為了更好的應對變化，封裝變化。
對「依賴倒置原則」的理解
上層的意思就是依賴方，例如乙個人出遠門需要依賴交通工具，下層就是被依賴方，如交通工具。交通工具包括大巴 火車 飛機 高鐵等。反例 按照下面uml圖，我們將實現 寫出來 可以看到每個種類的交通工具都需要去過載乙個方法才能執行，要是有100種交通出行方式，則需要寫100個過載，這是非常臃腫的，下面我們使...
OO設計的依賴倒置原則
dependency inversion principle dip oo設計的依賴倒置原則 該文提出了依賴倒置原則的2個重要方針 a.high level modules should not depend upon low level modules.both should depend upo...
設計原則之依賴倒置原則 我的依賴被反轉了
依賴倒置原則 dependency inversion principle dip。這個原則的英文是high level modules shouldn t depend on low level modules.both modules should depend on abstractions....