面向對象的三大基本特徵和六大基本原則

面向對象三大特徵:

(1)封裝(Encapsulation)

所謂封裝,也就是把客觀事物封裝成抽象的類,並且類可以把自己的數據和方法只讓可信的類或者對象操作,對不可信的進行信息隱藏。封裝是面向對象的特徵之一,是對象和類概念的主要特性。簡單的說,一個類就是一個封裝了數據以及操作這些數據的代碼的邏輯實體。在一個對象內部,某些代碼或某些數據可以是私有的,不能被外界訪問。通過這種方式,對象對內部數據提供了不同級別的保護,以防止程序中無關的部分意外的改變或錯誤的使用了對象的私有部分。

(2)繼承(Inheritance)

繼承是指這樣一種能力:它可以使用現有類的所有功能,並在無需重新編寫原來的類的情況下對這些功能進行擴展。通過繼承創建的新類稱爲“子類”或“派生類”,被繼承的類稱爲“基類”、“父類”或“超類”。繼承的過程,就是從一般到特殊的過程。要實現繼承,可以通過“繼承”(Inheritance)和“組合”(Composition)來實現。繼承概念的實現方式有二類:實現繼承與接口繼承。實現繼承是指直接使用基類的屬性和方法而無需額外編碼的能力;接口繼承是指僅使用屬性和方法的名稱、但是子類必須提供實現的能力;

(3)多態(Polymorphism)

所謂多態就是指一個類實例的相同方法在不同情形有不同表現形式。多態機制使具有不同內部結構的對象可以共享相同的外部接口。這意味着,雖然針對不同對象的具體操作不同,但通過一個公共的類,它們(那些操作)可以通過相同的方式予以調用。

最常見的多態就是將子類傳入父類參數中,運行時調用父類方法時通過傳入的子類決定具體的內部結構或行爲。

 

單一職責原則(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、多重繼承分離,通過接口多繼承來實現客戶的需求,這種方式是較好的。

 

迪米特原則(Law of Demeter)

就是說一個對象對另一個對象瞭解的儘可能的少。原因,如果類之間的依賴越多,導致耦合度越來越高,一旦修改某個類,則他所被依賴的類也要跟着修改。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章