物件導向的5個基本設計原則

標籤：blog   http   使用   os   io   strong   art   ar   

物件導向的3個基本要素：封裝、繼承、多態

物件導向的5個基本設計原則：

單一職責原則（Single-Resposibility Principle）

    其核心思想為：一個類，最好僅僅做一件事，僅僅有一個引起它的變化。單一職責原則能夠看做是低耦合、高內聚在物件導向原則上的引申，將職責定義為引起變化的原因，以提高內聚性來降低引起變化的原因。職責過多，可能引起它變化的原因就越多，這將導致職責依賴，相互之間就產生影響，從而大大損傷其內聚性和耦合度。通常意義下的單一職責，就是指僅僅有一種單一功能，不要為類實現過多的功能點，以保證實體僅僅有一個引起它變化的原因。
    專註，是一個人優良的品質；相同的，單一也是一個類的優良設計。交雜不清的職責將使得代碼看起來特別彆扭牽一髮而動全身，有失美感和必定導致醜陋的系統錯誤風險。

開放封閉原則（Open-Closed principle）

    其核心思想是：軟體實體應該是可擴充的，而不可改動的。也就是，對擴充開放，對改動封閉的。開放封閉原則主要體如今兩個方面1、對擴充開放，意味著有新的需求或變化時，能夠對現有代碼進行擴充，以適應新的情況。2、對改動封閉，意味著類一旦設計完畢，就能夠獨立完畢其工作，而不要對其進行不論什麼嘗試的改動。
    實現開開放封閉原則的核心思想就是對抽象編程，而不正確詳細編程，由於抽象相對穩定。讓類依賴於固定的抽象，所以改動就是封閉的；而通過物件導向的繼承和多態機制，又能夠實現對抽象類別的繼承，通過覆寫其方法來改變固有行為，實現新的拓展方法，所以就是開放的。
    “需求總是變化”沒有不變的軟體，所以就須要用封閉開放原則來封閉變化滿足需求，同一時候還能保持軟體內部的封裝體系穩定，不被需求的變化影響。

Liskov替換原則（Liskov-Substituion Principle）

    其核心思想是：子類必須可以替換其基類。這一思想體現為對繼承機制的約束規範，僅僅有子類可以替換基類時，才幹保證系統在執行期內識別子類，這是保證繼承複用的基礎。在父類和子類的詳細行為中，必須嚴格把握繼承層次中的關係和特徵，將基類替換為子類，程式的行為不會發生不論什麼變化。同一時候，這一約束反過來則是不成立的，子類可以替換基類，可是基類不一定能替換子類。
    Liskov替換原則，主要著眼於對抽象和多態建立在繼承的基礎上，因此僅僅有遵循了Liskov替換原則，才幹保證繼承複用是可靠地。實現的方法是面向介面編程：將公用部分抽象為基類介面或抽象類別，通過Extract Abstract Class，在子類中通過覆寫父類的方法實現新的方式支援相同的職責。
    Liskov替換原則是關於繼承機制的設計原則，違反了Liskov替換原則就必定導致違反開放封閉原則。
    Liskov替換原則可以保證系統具有良好的拓展性，同一時候實現基於多態的抽象機制，可以降低代碼冗餘，避免執行期的類型判別。

依賴倒置原則（Dependecy-Inversion Principle）

    其核心思想是：依賴於抽象。詳細而言就是高層模組不依賴於底層模組，二者都同依賴於抽象；抽象不依賴於詳細，詳細依賴於抽象。
    我們知道，依賴一定會存在於類與類、模組與模組之間。當兩個模組之間存在緊密的耦合關係時，最好的方法就是分離介面和實現：在依賴之間定義一個抽象的介面使得高層模組調用介面，而底層模組實現介面的定義，以此來有效控制耦合關係，達到依賴於抽象的設計目標。
    抽象的穩定性決定了系統的穩定性，由於抽象是不變的，依賴於抽象是物件導向設計的精髓，也是依賴倒置原則的核心。
    依賴於抽象是一個通用的原則，而某些時候依賴於細節則是在所難免的，必須權衡在抽象和詳細之間的取捨，方法不是一層不變的。依賴於抽象，就是對介面編程，不要對實現編程。

介面隔離原則（Interface-Segregation Principle）

    其核心思想是：使用多個小的專門的介面，而不要使用一個大的總介面。
    詳細而言，介面隔離原則體如今：介面應該是內聚的，應該避免“胖”介面。一個類對另外一個類的依賴應該建立在最小的介面上，不要強迫依賴不用的方法，這是一種介面汙染。
    介面有效地將細節和抽象隔離，體現了對抽象編程的一切優點，介面隔離強調介面的單一性。而胖介面存在明顯的弊端，會導致實現的類型必須全然實現介面的全部方法、屬性等；而某些時候，實作類別型並不是須要全部的介面定義，在設計上這是“浪費”，並且在實施上這會帶來潛在的問題，對胖介面的改動將導致一連串的client程式須要改動，有時候這是一種災難。在這樣的情況下，將胖介面分解為多個特點的定製化方法，使得client只依賴於它們的實際調用的方法，從而解除了client不會依賴於它們不用的方法。
    分離的手段主要有下面兩種：1、託付分離，通過添加?一個新的類型來託付客戶的請求，隔離客戶和介面的直接依賴，可是會添加?系統的開銷。2、多重繼承分離，通過介面多繼承來實現客戶的需求，這樣的方式是較好的。

    以上就是5個主要的物件導向設計原則，它們就像物件導向程式設計中的金科玉律，遵守它們能夠使我們的代碼更加鮮活，易於複用，易於拓展，靈活優雅。不同的設計模式相應不同的需求，而設計原則則代表永恒的靈魂，須要在實踐中時時刻刻地遵守。就如ARTHUR J.RIEL在那邊《OOD啟發錄》中所說的：“你並不必嚴格遵守這些原則，違背它們也不會被處以宗教刑罰。但你應當把這些原則看做警鈴，若違背了當中的一條，那麼警鈴就會響起。”

物件導向設計原則 http://www.cnblogs.com/feipeng/archive/2007/03/02/661840.html