一、三個基本特徵

面向物件的三個基本特徵是：封裝、繼承、多型。

封裝

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

封裝，也就是把客觀事物封裝成抽象的類，並且類可以把自己的資料和方法只讓可信的類或者物件操作，對不可信的進行資訊隱藏。

繼承

面向物件程式設計 (OOP) 語言的一個主要功能就是“繼承”。繼承是指這樣一種能力：它可以使用現有類的所有功能，並在無需重新編寫原來的類的情況下對這些功能進行擴充套件。

通過繼承建立的新類稱為“子類”或“派生類”。

被繼承的類稱為“基類”、“父類”或“超類”。

繼承的過程，就是從一般到特殊的過程。

要實現繼承，可以通過“繼承”（Inheritance）和“組合

在某些 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會受到影響。

"面向物件設計五大原則"和良性依賴原則在應付變化方面的作用。

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

開放封閉原則(Open-Closed principle)。"軟體實體應該是可以擴充套件的，但是不可修改。"本原則緊緊圍繞變化展開，變化來臨時，如果不必改動軟體實體裁的原始碼，就能擴充它的行為，那麼這個軟體實體設計就是滿足開放封閉原則的。如果說我們預測到某種變化，或者某種變化發生了，我們應當建立抽象類來隔離以後發生的同類變化。在Java中，這種抽象是指抽象基類或介面；在C++中，這各抽象是指抽象基類或純抽象基類。當然，沒有對所有情況都貼切的模型，我們必須對軟體實體應該面對的變化做出選擇。

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

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

介面隔離原則(Interface-Segregation Principle)。"多個專用介面優於一個單一的通用介面。"本原則是單一職責原則用於介面設計的自然結果。一個介面應該保證，實現該介面的例項物件可以只呈現為單一的角色；這樣，當某個客戶程式的要求發生變化，而迫使介面發生改變時，影響到其他客戶程式的可能生性小。

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