面向對象的三個基本特徵 和 五種設計原則

 

1、三個基本特徵

 

面向對象的三個基本特徵是：封裝、繼承、多態。

封裝

封裝最好理解了。封裝是面向對象的特徵之一，是對象和類概念的主要特性。

封裝，也就是把客觀事物封裝成抽象的類，而且類能夠把本身的數據和方法只讓可信的類或者對象操做，對不可信的進行信息隱藏。

繼承

面向對象編程 (OOP) 語言的一個主要功能就是「繼承」。繼承是指這樣一種能力：它可使用現有類的全部功能，並在無需從新編寫原來的類的狀況下對這些功能進行擴展。

經過繼承建立的新類稱爲「子類」或「派生類」。

被繼承的類稱爲「基類」、「父類」或「超類」。

繼承的過程，就是從通常到特殊的過程。

要實現繼承，能夠經過「繼承」（Inheritance）和「組合」（Composition）來實現。

在某些 OOP 語言中，一個子類能夠繼承多個基類。可是通常狀況下，一個子類只能有一個基類，要實現多重繼承，能夠經過多級繼承來實現。

 

繼承概念的實現方式有三類：實現繼承、接口繼承和可視繼承。

Ø         實現繼承是指使用基類的屬性和方法而無需額外編碼的能力；

Ø         接口繼承是指僅使用屬性和方法的名稱、可是子類必須提供實現的能力；

Ø         可視繼承是指子窗體（類）使用基窗體（類）的外觀和實現代碼的能力。

在考慮使用繼承時，有一點須要注意，那就是兩個類之間的關係應該是「屬於」關係。例如，Employee 是一我的，Manager 也是一我的，所以這兩個類均可以繼承 Person 類。可是 Leg 類卻不能繼承 Person 類，由於腿並非一我的。

抽象類僅定義將由子類建立的通常屬性和方法，建立抽象類時，請使用關鍵字 Interface 而不是 Class。

OO開發範式大體爲：劃分對象→抽象類→將類組織成爲層次化結構(繼承和合成) →用類與實例進行設計和實現幾個階段。

 

多態

多態性（polymorphisn）是容許你將父對象設置成爲和一個或更多的他的子對象相等的技術，賦值以後，父對象就能夠根據當前賦值給它的子對象的特性以不一樣的方式運做。簡單的說，就是一句話：容許將子類類型的指針賦值給父類類型的指針。

實現多態，有二種方式，覆蓋，重載。

覆蓋，是指子類從新定義父類的虛函數的作法。

重載，是指容許存在多個同名函數，而這些函數的參數表不一樣（或許參數個數不一樣，或許參數類型不一樣，或許二者都不一樣）。

其實，重載的概念並不屬於「面向對象編程」，重載的實現是：編譯器根據函數不一樣的參數表，對同名函數的名稱作修飾，而後這些同名函數就成了不一樣的函數（至少對於編譯器來講是這樣的）。如，有兩個同名函數：function func(p:integer):integer;和function func(p:string):integer;。那麼編譯器作過修飾後的函數名稱多是這樣的：int_func、str_func。對於這兩個函數的調用，在編譯器間就已經肯定了，是靜態的（記住：是靜態）。也就是說，它們的地址在編譯期就綁定了（早綁定），所以，重載和多態無關！真正和多態相關的是「覆蓋」。當子類從新定義了父類的虛函數後，父類指針根據賦給它的不一樣的子類指針，動態（記住：是動態！）的調用屬於子類的該函數，這樣的函數調用在編譯期間是沒法肯定的（調用的子類的虛函數的地址沒法給出）。所以，這樣的函數地址是在運行期綁定的（晚邦定）。結論就是：重載只是一種語言特性，與多態無關，與面向對象也無關！引用一句Bruce Eckel的話：「不要犯傻，若是它不是晚邦定，它就不是多態。」

那麼，多態的做用是什麼呢？

咱們知道，封裝能夠隱藏實現細節，使得代碼模塊化；繼承能夠擴展已存在的代碼模塊（類）；它們的目的都是爲了——代碼重用。而多態則是爲了實現另外一個目的——接口重用！多態的做用，就是爲了類在繼承和派生的時候，保證使用「家譜」中任一類的實例的某一屬性時的正確調用。

 

概念講解

泛化（Generalization）

圖表 1 泛化

在上圖中，空心的三角表示繼承關係（類繼承），在UML的術語中，這種關係被稱爲泛化（Generalization）。Person(人)是基類，Teacher(教師)、Student(學生)、Guest(來賓)是子類。

若在邏輯上B是A的「一種」，而且A的全部功能和屬性對B而言都有意義，則容許B繼承A的功能和屬性。

例如，教師是人，Teacher 是Person的「一種」（a kind of ）。那麼類Teacher能夠從類Person派生（繼承）。

若是A是基類，B是A的派生類，那麼B將繼承A的數據和函數。

若是類A和類B絕不相關，不能夠爲了使B的功能更多些而讓B繼承A的功能和屬性。

若在邏輯上B是A的「一種」（a kind of ），則容許B繼承A的功能和屬性。

 

聚合（組合）

圖表 2 組合

若在邏輯上A是B的「一部分」（a part of），則不容許B從A派生，而是要用A和其它東西組合出B。

例如，眼（Eye）、鼻（Nose）、口（Mouth）、耳（Ear）是頭（Head）的一部分，因此類Head應該由類Eye、Nose、Mouth、Ear組合而成，不是派生（繼承）而成。

 

聚合的類型分爲無、共享(聚合)、複合(組合)三類。

 

聚合（aggregation）

 

圖表 3 共享

上面圖中，有一個菱形（空心）表示聚合（aggregation）（聚合類型爲共享），聚合的意義表示has-a關係。聚合是一種相對鬆散的關係，聚合類B不須要對被聚合的類A負責。

 

組合（composition）

圖表 4 複合

這幅圖與上面的惟一區別是菱形爲實心的，它表明了一種更爲堅固的關係——組合（composition）（聚合類型爲複合）。組合表示的關係也是has-a，不過在這裏，A的生命期受B控制。即A會隨着B的建立而建立，隨B的消亡而消亡。

 

依賴(Dependency)

圖表 5 依賴

這裏B與A的關係只是一種依賴(Dependency)關係，這種關係代表，若是類A被修改，那麼類B會受到影響。

2、五種設計原則

 

 

"面向對象設計五大原則"和良性依賴原則在應付變化方面的做用。

單一職責原則(Single-Resposibility Principle)。"對一個類而言，應該僅有一個引發它變化的緣由。"本原則是咱們很是熟悉地"高內聚性原則"的引伸，可是經過將"職責"極具創意地定義爲"變化的緣由"，使得本原則極具操做性，盡顯大師風範。同時，本原則還揭示了內聚性和耦合生，基本途徑就是提升內聚性；若是一個類承擔的職責過多，那麼這些職責就會相互依賴，一個職責的變化可能會影響另外一個職責的履行。其實OOD的實質，就是合理地進行類的職責分配。

開放封閉原則(Open-Closed principle)。"軟件實體應該是能夠擴展的，可是不可修改。"本原則牢牢圍繞變化展開，變化來臨時，若是沒必要改動軟件實體裁的源代碼，就能擴充它的行爲，那麼這個軟件實體設計就是知足開放封閉原則的。若是說咱們預測到某種變化，或者某種變化發生了，咱們應當建立抽象類來隔離之後發生的同類變化。在Java中，這種抽象是指抽象基類或接口；在C++中，這各抽象是指抽象基類或純抽象基類。固然，沒有對全部狀況都貼切的模型，咱們必須對軟件實體應該面對的變化作出選擇。

Liskov替換原則(Liskov-Substituion Principle)。"子類型必須可以替換掉它們的基類型。"本原則和開放封閉原則關係密切，正是子類型的可替換性，才使得使用基類型模塊無需修改就可擴充。Liskov替換原則從基於契約的設計演化而來，契約經過爲每一個方法聲明"先驗條件"和"後驗條件"；定義子類時，必須遵照這些"先驗條件"和"後驗條件"。當前基於契的設計發展勢頭正勁，對實現"軟件工廠"的"組裝生產"夢想是一個有力的支持。

依賴倒置原則(Dependecy-Inversion Principle)。"抽象不該依賴於細節，細節應該依賴於抽象。"本原則幾乎就是軟件設計的正本清源之道。由於人解決問題的思考過程是先抽象後具體，從籠統到細節，因此咱們先生產出的勢必是抽象程度比較高的實體，然後纔是更加細節化的實體。因而，"細節依賴於抽象"就意味着後來的依賴於先前的，這是天然而然的重用之道。並且，抽象的實體表明着籠而統之的認識，人們老是比較容易正確認識它們，並且自己也是不易變的，依賴於它們是安全的。依賴倒置原則適應了人類認識過程的規律，是面向對象設計的標誌所在。

接口隔離原則(Interface-Segregation Principle)。"多個專用接口優於一個單一的通用接口。"本原則是單一職責原則用於接口設計的天然結果。一個接口應該保證，實現該接口的實例對象能夠只呈現爲單一的角色；這樣，當某個客戶程序的要求發生變化，而迫使接口發生改變時，影響到其餘客戶程序的可能生性小。

良性依賴原則。"不會在實際中形成危害的依賴關係，都是良性依賴。"經過分析不難發現，本原則的核心思想是"務實"，很好地揭示了極限編程(Extreme Programming)中"簡單設計"各"重構"的理論基礎。本原則能夠幫助咱們抵禦"面向對象設計五大原則"以及設計模式的誘惑，以避免陷入過分設計(Over-engineering)的尷尬境地，帶來沒必要要的複雜性。