牢記面向對象五個基本原則

櫻桃大丸子 8年前發布 | 21K 次閱讀 面向對象

寫在前面:面向對象的三個基本要素和五個基本原則,很早以前就知道.但是一直沒有當做很重要的東西去理解,以為就是概念性的東西知道就好了.最近再看代碼重構的知識.發現要想寫出干凈的代碼,就一定要遵守這五個原則.

 

單一職責原則(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)

其核心思想是:使用多個小的專門的接口,而不要使用一個大的總接口。
具體而言,接口隔離原則體現在:接口應該是內聚的,應該避免“胖”接口。一個類對另外一個類的依賴應該建立在最小的接口上,不要強迫依賴不用的方法,這是一種接口污染。
接口有效地將細節和抽象隔離,體現了對抽象編程的一切好處,接口隔離強調接口的單一性。而胖接口存在明顯的弊端,會導致實現的類型必須完全實現接口的所有方法、屬性等;而某些時候,實現類型并非需要所有的接口定義,在設計上這是“浪費”,而且在實施上這會帶來潛在的問題,對胖接口的修改將導致一連串的客戶端程序需要修改,有時候這是一種災難。在這種情況下,將胖接口分解為多個特點的定制化方法,使得客戶端僅僅依賴于它們的實際調用的方法,從而解除了客戶端不會依賴于它們不用的方法。
分離的手段主要有以下兩種:1、委托分離,通過增加一個新的類型來委托客戶的請求,隔離客戶和接口的直接依賴,但是會增加系統的開銷。2、多重繼承分離,通過接口多繼承來實現客戶的需求,這種方式是較好的。

以上就是5個基本的面向對象設計原則,它們就像面向對象程序設計中的金科玉律,遵守它們可以使我們的代碼更加鮮活,易于復用,易于拓展,靈活優雅。不同的設計模式對應不同的需求,而設計原則則代表永恒的靈魂,需要在實踐中時時刻刻地遵守。就如ARTHUR J.RIEL在那邊《OOD啟示錄》中所說的:“你并不必嚴格遵守這些原則,違背它們也不會被處以宗教刑罰。但你應當把這些原則看做警鈴,若違背了其中的一條,那么警鈴就會響起。”</code></pre>

來源:http://www.hollischuang.com/archives/220 

 本文由用戶 櫻桃大丸子 自行上傳分享,僅供網友學習交流。所有權歸原作者,若您的權利被侵害,請聯系管理員。
 轉載本站原創文章,請注明出處,并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺,歡迎各類分享!