三個基本特徵
面向對象三個基本特徵：封裝、繼承、多態
——封裝，隱藏內部代碼
——繼承，複用現有代碼
——多態，改寫對象行爲
封裝
封裝，也就是把客觀事物封裝成抽象的類，並且類可以把自己的數據和方法只讓可信的類或者對象操作，對不可信的進行信息隱藏。
繼承
可以使用現有類的所有功能，並在無需重新編寫原來的類的情況下對這些功能進行擴展。
通過繼承創建的新類稱爲“子類”或“派生類”。
被繼承的類稱爲“基類”、“父類”或“超類”。
繼承的過程，就是從一般到特殊的過程。
要實現繼承，可以通過“繼承”（Inheritance）和“組合”（Composition）來實現。
在某些 OOP 語言中，一個子類可以繼承多個基類。但是一般情況下，一個子類只能有一個基類，要實現多重繼承，可以通過多級繼承來實現。
繼承概念的實現方式有三類：實現繼承、接口繼承和可視繼承。
Ø 實現繼承是指使用基類的屬性和方法而無需額外編碼的能力；
Ø 接口繼承是指僅使用屬性和方法的名稱、但是子類必須提供實現的能力；
Ø 可視繼承是指子窗體（類）使用基窗體（類）的外觀和實現代碼的能力。
多態
多態性是允許將父對象設置成爲和一個或更多的子對象相等的技術，賦值之後，父對象就可以根據當前賦值給它的子對象的特性以不同的方式運作。
實現多態，有二種方式，覆蓋，重載。
覆蓋，是指子類重新定義父類的虛函數的做法。
重載，是指允許存在多個同名函數，而這些函數的參數表不同（或許參數個數不同，或許參數類型不同，或許兩者都不同）。
其實，重載的概念並不屬於“面向對象編程”，重載的實現是：編譯器根據函數不同的參數表，對同名函數的名稱做修飾，然後這些同名函數就成了不同的函數（至少對於編譯器來說是這樣的）。如，有兩個同名函數：function func(p:integer):integer;和function func(p:string):integer;。那麼編譯器做過修飾後的函數名稱可能是這樣的：int_func、str_func。對於這兩個函數的調用，在編譯器間就已經確定了，是靜態的（記住：是靜態）。也就是說，它們的地址在編譯期就綁定了（早綁定），因此，重載和多態無關！真正和多態相關的是“覆蓋”。當子類重新定義了父類的虛函數後，父類指針根據賦給它的不同的子類指針，動態（記住：是動態！）的調用屬於子類的該函數，這樣的函數調用在編譯期間是無法確定的（調用的子類的虛函數的地址無法給出）。因此，這樣的函數地址是在運行期綁定的（晚邦定）。結論就是：重載只是一種語言特性，與多態無關，與面向對象也無關！引用一句Bruce Eckel的話：“不要犯傻，如果它不是晚邦定，它就不是多態。”
那麼，多態的作用是什麼呢？
我們知道，封裝可以隱藏實現細節，使得代碼模塊化；繼承可以擴展已存在的代碼模塊（類）；它們的目的都是爲了——代碼重用。而多態則是爲了實現另一個目的——接口重用！多態的作用，就是爲了類在繼承和派生的時候，保證使用“家譜”中任一類的實例的某一屬性時的正確調用。
五種設計原則
單一職責原則(Single-Resposibility Principle)。
“對一個類而言，應該僅有一個引起它變化的原因。”本原則是我們非常熟悉地”高內聚性原則”的引申，但是通過將”職責”極具創意地定義爲”變化的原因”，使得本原則極具操作性，盡顯大師風範。同時，本原則還揭示了內聚性和耦合生，基本途徑就是提高內聚性；如果一個類承擔的職責過多，那麼這些職責就會相互依賴，一個職責的變化可能會影響另一個職責的履行。其實OOD的實質，就是合理地進行類的職責分配。
開放封閉原則(Open-Closed principle)。
“軟件實體應該是可以擴展的，但是不可修改。”本原則緊緊圍繞變化展開，變化來臨時，如果不必改動軟件實體裁的源代碼，就能擴充它的行爲，那麼這個軟件實體設計就是滿足開放封閉原則的。如果說我們預測到某種變化，或者某種變化發生了，我們應當創建抽象類來隔離以後發生的同類變化。在Java中，這種抽象是指抽象基類或接口；在C++中，這各抽象是指抽象基類或純抽象基類。當然，沒有對所有情況都貼切的模型，我們必須對軟件實體應該面對的變化做出選擇。
Liskov替換原則(Liskov-Substituion Principle)。
“子類型必須能夠替換掉它們的基類型。”本原則和開放封閉原則關係密切，正是子類型的可替換性，才使得使用基類型模塊無需修改就可擴充。Liskov替換原則從基於契約的設計演化而來，契約通過爲每個方法聲明”先驗條件”和”後驗條件”；定義子類時，必須遵守這些”先驗條件”和”後驗條件”。當前基於契的設計發展勢頭正勁，對實現”軟件工廠”的”組裝生產”夢想是一個有力的支持。
依賴倒置原則(Dependecy-Inversion Principle)。
“抽象不應依賴於細節，細節應該依賴於抽象。”本原則幾乎就是軟件設計的正本清源之道。因爲人解決問題的思考過程是先抽象後具體，從籠統到細節，所以我們先生產出的勢必是抽象程度比較高的實體，而後纔是更加細節化的實體。於是，”細節依賴於抽象”就意味着後來的依賴於先前的，這是自然而然的重用之道。而且，抽象的實體代表着籠而統之的認識，人們總是比較容易正確認識它們，而且本身也是不易變的，依賴於它們是安全的。依賴倒置原則適應了人類認識過程的規律，是面向對象設計的標誌所在。
接口隔離原則(Interface-Segregation Principle)。
“多個專用接口優於一個單一的通用接口。”本原則是單一職責原則用於接口設計的自然結果。一個接口應該保證，實現該接口的實例對象可以只呈現爲單一的角色；這樣，當某個客戶程序的要求發生變化，而迫使接口發生改變時，影響到其他客戶程序的可能生性小。
良性依賴原則。
“不會在實際中造成危害的依賴關係，都是良性依賴。”通過分析不難發現，本原則的核心思想是”務實”，很好地揭示了極限編程(Extreme Programming)中”簡單設計”各”重構”的理論基礎。本原則可以幫助我們抵禦”面向對象設計五大原則”以及設計模式的誘惑，以免陷入過度設計(Over-engineering)的尷尬境地，帶來不必要的複雜性。
