面向對象的三個基本特征 和 五種設計原則
面向對象的三個基本特征 和 五種設計原則
來源: http://blog.csdn.net/cancan8538/article/details/8057095
一、三個基本特征
面向對象的三個基本特征是：封裝、繼承、多態。
封裝
封裝最好理解了。封裝是面向對象的特征之一，是對象和類概念的主要特性。
封裝，也就是把客觀事物封裝成抽象的類，並且類可以把自己的數據和方法只讓可信的類或者對象操作，對不可信的進行信息隱藏。
繼承
面向對象編程 (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會受到影響。
二、五種設計原則
"面向對象設計五大原則"和良性依賴原則在應付變化方面的作用。
單一職責原則(Single-Resposibility Principle)。"對一個類而言，應該僅有一個引起它變化的原因。"本原則是我們非常熟悉地"高內聚性原則"的引申，但是通過將"職責"極具創意地定義為"變化的原因"，使得本原則極具操作性，盡顯大師風範。同時，本原則還揭示了內聚性和耦合生，基本途徑就是提高內聚性；如果一個類承擔的職責過多，那麽這些職責就會相互依賴，一個職責的變化可能會影響另一個職責的履行。其實OOD的實質，就是合理地進行類的職責分配。
開放封閉原則(Open-Closed principle)。"軟件實體應該是可以擴展的，但是不可修改。"本原則緊緊圍繞變化展開，變化來臨時，如果不必改動軟件實體裁的源代碼，就能擴充它的行為，那麽這個軟件實體設計就是滿足開放封閉原則的。如果說我們預測到某種變化，或者某種變化發生了，我們應當創建抽象類來隔離以後發生的同類變化。在Java中，這種抽象是指抽象基類或接口；在C++中，這各抽象是指抽象基類或純抽象基類。當然，沒有對所有情況都貼切的模型，我們必須對軟件實體應該面對的變化做出選擇。
Liskov替換原則(Liskov-Substituion Principle)。"子類型必須能夠替換掉它們的基類型。"本原則和開放封閉原則關系密切，正是子類型的可替換性，才使得使用基類型模塊無需修改就可擴充。Liskov替換原則從基於契約的設計演化而來，契約通過為每個方法聲明"先驗條件"和"後驗條件"；定義子類時，必須遵守這些"先驗條件"和"後驗條件"。當前基於契的設計發展勢頭正勁，對實現"軟件工廠"的"組裝生產"夢想是一個有力的支持。
依賴倒置原則(Dependecy-Inversion Principle)。"抽象不應依賴於細節，細節應該依賴於抽象。"本原則幾乎就是軟件設計的正本清源之道。因為人解決問題的思考過程是先抽象後具體，從籠統到細節，所以我們先生產出的勢必是抽象程度比較高的實體，而後才是更加細節化的實體。於是，"細節依賴於抽象"就意味著後來的依賴於先前的，這是自然而然的重用之道。而且，抽象的實體代表著籠而統之的認識，人們總是比較容易正確認識它們，而且本身也是不易變的，依賴於它們是安全的。依賴倒置原則適應了人類認識過程的規律，是面向對象設計的標誌所在。
接口隔離原則(Interface-Segregation Principle)。"多個專用接口優於一個單一的通用接口。"本原則是單一職責原則用於接口設計的自然結果。一個接口應該保證，實現該接口的實例對象可以只呈現為單一的角色；這樣，當某個客戶程序的要求發生變化，而迫使接口發生改變時，影響到其他客戶程序的可能生性小。
良性依賴原則。"不會在實際中造成危害的依賴關系，都是良性依賴。"通過分析不難發現，本原則的核心思想是"務實"，很好地揭示了極限編程(Extreme Programming)中"簡單設計"各"重構"的理論基礎。本原則可以幫助我們抵禦"面向對象設計五大原則"以及設計模式的誘惑，以免陷入過度設計(Over-engineering)的尷尬境地，帶來不必要的復雜性。
面向對象的三個基本特征 和 五種設計原則