Source: http://book.csdn.net/bookfiles/383/10038314337.shtml
“依賴”是和“變化”緊密聯系在一起的概念。由于依賴關系的存在，變化在某處發生時，影響會波及開去，造成很多修改工作，這就是依賴的危害。可以說，變化是始作俑者，依賴是助紂為虐。
我們可以不去擁抱變化嗎？不可以。未來將越來越不可預測，這是新經濟最具挑戰性的方面之一。商務和技術上的瞬息萬變會產生變化，這既可以看作要防范的威脅，也可以看作應該歡迎的機遇。
既然變化不可避免，我們所能做的就是處理好依賴關系，將變化造成的影響的波及范圍盡量減小。
下面總結一下“面向對象設計5大原則”和良性依賴原則在應付變化方面的作用。
單一職責原則（Single-Responsibility Principle）。“對一個類而言，應該僅有一個引起它變化的原因”。本原則是我們非常熟悉地“高內聚性原則”的引申，但是通過將“職責”極具創意地定義為“變化的原因”，使得本原則極具可操作性，盡顯大師風范。同時，本原則還揭示了內聚性和耦合性是“一物兩面”的關系，為了降低耦合性，基本途徑就是提高內聚性；如果一個類承擔的職責過多，那么這些職責就會相互依賴，一個職責的變化可能會影響另一個職責的履行。其實OOD的實質，就是合理地進行類的職責分配。
開放封閉原則（Open-Closed Principle）。“軟件實體應該是可以擴展的，但是不可修改”。本原則緊緊圍繞變化展開，變化來臨時，如果不必改動軟件實體的源代碼，就能擴充它的行為，那么這個軟件實體的設計就是滿足開放封閉原則的。如果我們預測到某種變化，或者某種變化發生了，我們應當創建抽象來隔離以后發生的同類變化。在Java中，這種抽象指抽象基類或接口；在C++中，這種抽象是指抽象基類或純抽象基類。當然，沒有對所有情況都貼切的模型，我們必須對軟件實體應該面對的變化做出選擇。
Liskov替換原則（Liskov-Substitution Principle）。“子類型必須能夠替換掉它們的基類型”。本原則和開放封閉原則關系密切，正是子類型的可替換性，才使得使用基類型的模塊無需修改就可擴充。Liskov替換原則從基于契約的設計演化而來，契約通過為每個方法聲明“先驗條件”和“后驗條件”；定義子類時，必須遵守這些“先驗條件”和“后驗條件”。當前，基于契約的設計發展勢頭正勁，對實現“軟件工廠”的“組裝生產”夢想是一個有力的支持。
依賴倒置原則（Dependency-Inversion Principle）。“抽象不應依賴于細節，細節應該依賴于抽象”。本原則幾乎就是軟件設計的正本清源之道。因為人解決問題的思考過程是先抽象后具體，從籠統到細節的，所以我們先生產出的勢必是抽象程度比較高的實體，而后才是更加細節化的實體。于是，“細節依賴于抽象”就意味著后來的依賴于先前的，這是自然而然的重用之道。而且，抽象的實體代表著籠而統之的認識，人們總是比較容易正確認識它們，而且它們本身也是不易變的，依賴于它們是安全的。依賴倒置原則適應了人類認識過程的規律，是面向對象設計的標志所在。
接口隔離原則（Interface-Segregation Principle）。“多個專用接口優于一個單一的通用接口”。本原則是單一職責原則用于接口設計的自然結果。一個接口應該保證，實現該接口的實例對象可以只呈現為單一的角色；這樣，當某個客戶程序的要求發生變化，而迫使接口發生改變時，影響到其他客戶程序的可能性最小。
良性依賴原則。“不會在實際中造成危害的依賴關系，都是良性依賴”。通過分析不難發現，本原則的核心思想是“務實”，很好地揭示了極限編程（Extreme Programming）中“簡單設計”和“重構”的理論基礎。本原則可以幫助我們抵御“面向對象設計5大原則”以及設計模式的誘惑，以免陷入過度設計（Over-engineering）的尷尬境地，帶來不必要的復雜性。
本博客為學習交流用，凡未注明引用的均為本人作品，轉載請注明出處，如有版權問題請及時通知。由于博客時間倉促，錯誤之處敬請諒解，有任何意見可給我留言，愿共同學習進步。