第六篇： 設計模式六大原則： 老闆是如何減輕負擔的 -- 依賴倒置原則
很多創業公司都對外宣稱「扁平化管理」，什麼是「扁平化管理」呢？請看下面這張架構圖：
因爲人少，老闆直接管理着採購、銷售、人力跟 IT 等人員，雖然累了點，但部門少、人不多也還好。
但是隨着公司規模發展，每次新加入人員老闆都要去認識、溝通，出現問題還得去約出去喝個茶，老闆發現自己的時間都浪費在這些瑣事，容易耽擱事不說，還發揮不出更大價值。
這時他決定招一些經理替自己分別管理各個部門，自己只要管理這些經理就好了。
於是新的架構圖是這樣的：
老闆這下子省心多了，有問題直接找部門經理就好了。至於哪個部門有召新人、或者員工不好好幹開除了，他都不用操心。
傳統軟件開發中，類A直接依賴類B，假如要將類A改爲依賴類C，則必須通過修改類A的代碼來達成。這種場景下，類A一般是高層模塊，負責複雜的業務邏輯；類B和類C是低層模塊，負責基本的原子操作；假如修改類A，會給程序帶來不必要的風險。參考自這裏
這對應創業初期公司的「扁平化」，老闆就是高層類A，高層一旦對低層的具體有依賴，將來低層變動 時高層就需要修改，這很類，也容易出錯。
而老闆負擔能夠減輕，正是依賴倒置原則的作用。
高層模塊不應該依賴具體底層模塊，兩個都應該依賴接口。簡單的說就是面向接口編程，而不是面向具體實現。
任何變量都不應該持有一個指向具體類的指針或引用。
在實際編程中，我們一般需要做到如下3點：
- 低層模塊儘量都要有抽象類或接口，或者兩者都有。
- 變量的聲明類型儘量是抽象類或接口。
- 使用繼承時遵循里氏替換原則。
依賴倒置有三種方式來實現
- 通過構造函數傳遞依賴對象；
比如在構造函數中的需要傳遞的參數是抽象類或接口的方式實現。 - 通過setter方法傳遞依賴對象；
即在我們設置的setXXX方法中的參數爲抽象類或接口，來實現傳遞依賴對象。 - 接口聲明實現依賴對象，也叫接口注入；
即在函數聲明中參數爲抽象類或接口，來實現傳遞依賴對象，從而達到直接使用依賴對象的目的。
依賴倒置原則的核心就是要我們面向接口編程，理解了面向接口編程，也就理解了依賴倒置。
代碼地址點這裏
感謝
《大話設計模式》
http://blog.csdn.net/imyfriend/article/details/7465596
http://blog.csdn.net/zhengzhb/article/details/7289269