面向對象的5條基本設計原則

這幾天從新看了一遍《大話設計模式》，發現果真有不一樣的感悟，並且本身也上網找了《敏捷軟件開發—原則、模式與實踐》一書來看，那本書的序言中有一段話我以爲頗有道理：「美的東西比醜的東西建立起來更廉價，也更快捷。」設計一個軟件不關要追求代碼的優雅問題，更關乎生產成本等。技術大師們在對軟件架構的研究中經歷了很長時間的摸索，從面向過程到面向對象，從設計原則到設計模式，總結了許多設計上的經典法則，而咱們就只是站在巨人的肩膀上眺望遠方而已。

　　從《大話設計模式》中，你們必定會發現其中的經典的23個模式背後，其實都遵循着一些基本的原則的。而設計原則又由設計模式來實現，這就是兩者相輔相成的關係，因此瞭解原則對於瞭解模式具備絕對的指導意義。如下是我在閱讀過程當中的一些學習筆記，自覺得有必定道理。

　　最基本的設計原則有5條，分別是：單一職責原則、開放封閉原則、依賴倒置原則、接口隔離原則和Liskov替換原則。

　　單一職責原則

　　對於單一職責原則，其核心思想爲：一個類，最好只作一件事，只有一個引發它的變化。單一職責原則能夠看作是低耦合、高內聚在面向對象原則上的引伸，將職責定義爲引發變化的緣由，以提升內聚性來減小引發變化的緣由。職責過多，可能引發它變化的緣由就越多，這將致使職責依賴，相互之間就產生影響，從而大大損傷其內聚性和耦合度。一般意義下的單一職責，就是指只有一種單一功能，不要爲類實現過多的功能點，以保證明體只有一個引發它變化的緣由。

　　專一，是一我的優良的品質；一樣的，單一也是一個類的優良設計。交雜不清的職責將使得代碼看起來特別彆扭牽一髮而動全身，有失美感和必然致使醜陋的系統錯誤風險。

　　開放封閉原則

　　對於開放封閉原則，它是面向對象全部原則的核心，軟件設計說到底追求的目標就是封裝變化、下降耦合，而開放封閉原則就是這一目標的最直接體現。

開放封閉原則，其核心思想是：軟件實體應該是可擴展的，而不可修改的。也就是，對擴展開放，對修改封閉的。

　　所以，開放封閉原則主要體如今兩個方面：一、對擴展開放，意味着有新的需求或變化時，能夠對現有代碼進行擴展，以適應新的狀況。二、對修改封閉，意味着類一旦設計完成，就能夠獨立完成其工做，而不要對其進行任未嘗試的修改。

　　實現開開放封閉原則的核心思想就是對抽象編程，而不對具體編程，由於抽象相對穩定。讓類依賴於固定的抽象，因此修改就是封閉的；而經過面向對象的繼承和多態機制，又能夠實現對抽象類的繼承，經過覆寫其方法來改變固有行爲，實現新的拓展方法，因此就是開放的。

　　「需求老是變化」沒有不變的軟件，因此就須要用封閉開放原則來封閉變化知足需求，同時還能保持軟件內部的封裝體系穩定，不被需求的變化影響。

　　依賴倒置原則

　　對於依賴倒置原則，其核心思想是：依賴於抽象。具體而言就是高層模塊不依賴於底層模塊，兩者都同依賴於抽象；抽象不依賴於具體，具體依賴於抽象。

　　咱們知道，依賴必定會存在於類與類、模塊與模塊之間。當兩個模塊之間存在緊密的耦合關係時，最好的方法就是分離接口和實現：在依賴之間定義一個抽象的接口使得高層模塊調用接口，而底層模塊實現接口的定義，以此來有效控制耦合關係，達到依賴於抽象的設計目標。

　　抽象的穩定性決定了系統的穩定性，由於抽象是不變的，依賴於抽象是面向對象設計的精髓，也是依賴倒置原則的核心。

　　依賴於抽象是一個通用的原則，而某些時候依賴於細節則是在所不免的，必須權衡在抽象和具體之間的取捨，方法不是一層不變的。依賴於抽象，就是對接口編程，不要對實現編程。

　　接口隔離原則

　　對於接口隔離原則，其核心思想是：使用多個小的專門的接口，而不要使用一個大的總接口。

　　具體而言，接口隔離原則體如今：接口應該是內聚的，應該避免「胖」接口。一個類對另一個類的依賴應該創建在最小的接口上，不要強迫依賴不用的方法，這是一種接口污染。

　　接口有效地將細節和抽象隔離，體現了對抽象編程的一切好處，接口隔離強調接口的單一性。而胖接口存在明顯的弊端，會致使實現的類型必須徹底實現接口的全部方法、屬性等；而某些時候，實現類型並不是須要全部的接口定義，在設計上這是「浪費」，並且在實施上這會帶來潛在的問題，對胖接口的修改將致使一連串的客戶端程序須要修改，有時候這是一種災難。在這種狀況下，將胖接口分解爲多個特色的定製化方法，使得客戶端僅僅依賴於它們的實際調用的方法，從而解除了客戶端不會依賴於它們不用的方法。

　　分離的手段主要有如下兩種：一、委託分離，經過增長一個新的類型來委託客戶的請求，隔離客戶和接口的直接依賴，可是會增長系統的開銷。二、多重繼承分離，經過接口多繼承來實現客戶的需求，這種方式是較好的。

　　Liskov替換原則

　　對於Liskov替換原則，其核心思想是：子類必須可以替換其基類。這一思想體現爲對繼承機制的約束規範，只有子類可以替換基類時，才能保證系統在運行期內識別子類，這是保證繼承複用的基礎。在父類和子類的具體行爲中，必須嚴格把握繼承層次中的關係和特徵，將基類替換爲子類，程序的行爲不會發生任何變化。同時，這一約束反過來則是不成立的，子類能夠替換基類，可是基類不必定能替換子類。

　　Liskov替換原則，主要着眼於對抽象和多態創建在繼承的基礎上，所以只有遵循了Liskov替換原則，才能保證繼承複用是可靠地。實現的方法是面向接口編程：將公共部分抽象爲基類接口或抽象類，經過Extract Abstract Class，在子類中經過覆寫父類的方法實現新的方式支持一樣的職責。

　　Liskov替換原則是關於繼承機制的設計原則，違反了Liskov替換原則就必然致使違反開放封閉原則。

　　Liskov替換原則可以保證系統具備良好的拓展性，同時實現基於多態的抽象機制，可以減小代碼冗餘，避免運行期的類型判別。

　　以上就是5個基本的設計原則，它們就像面向對象程序設計中的金科玉律，遵照它們可使咱們的代碼更加鮮活，易於複用，易於拓展，靈活優雅。不一樣的設計模式對應不一樣的需求，而設計原則則表明永恆的靈魂，須要在實踐中時時刻刻地遵照。就如ARTHUR J.RIEL在那邊《OOD啓示錄》中所說的：「你並沒必要嚴格遵照這些原則，違背它們也不會被處以宗教刑罰。但你應當把這些原則看作警鈴，若違背了其中的一條，那麼警鈴就會響起。」

　　請記住這些技術大師的名字和做品，並深刻研習其中的招式和經驗，正是他們讓面向對象程序設計變得如此光彩奪目，沿着這些智慧的道路一直走下去，我以爲，咱們會不只僅提升了技術，還會發現設計之外的東西，由於OOP還蘊含着人生的不少智慧。