一、面向對象設計的三個基本要素#
面向對象的三個基本特征是：封裝、繼承、多態。
1·封裝性##
封裝性是一種信息隱蔽技術，他體現於類的說明，是對象重要的特性。封裝使得數據和操作數據的方法封裝為一個整體，想成獨立性很強的模塊，使得用戶只能看到對象的外部特性（對象可以接受拿些信息，可以進行何種處理），而對象的內部特性（內部私有屬性和實現處理能力的算法）用戶是看不到的。簡而言之就是說，封裝使對象的設計者與對象的使用者分開，使用者只要知道對象可以做什么就可以了，無需知道具體是怎么實現的。借助封裝有助於提高類和系統的安全性。
2·繼承性##
繼承是一種由已有類創建子類的機制，利用繼承，可以先創建一個共有屬性的一般類，根據這個類再創建具有特殊屬性的子類，被繼承的類成為父類，當然子類也可以成為父類來繼續向下擴展。
3·多態性##
同一個信息被不同的對象接收到時可能產生不同的行為，這就是多態性。有繼承（接口）有重寫，父類引用指向子類對象，就會產生多態。多態可以改善程序的組織架構，提高程序的可擴展性。
二、面向對象設計的五個基本設計原則#
面向對象設計的五個基本設計原則是：單一職責原則（SRP）、開放封閉原則（OCP）、Liskov替換原則（LSP）、依賴倒置原則（DIP）、接口隔離原則（ISP）
1·單一職責原則（Single-Responsibility Principle）##
其核心思想為：一個類只做一件事情，只有一個引起他的變化。單一職責原則可以看做是低耦合，高內聚在面向對象原則上的隱身，將職責定義為引起變化的原因，以提高內舉行來減少引起變化的原因。職責過多可能引起他變化的原因也就越多，這將導致職責依賴，相互之間產生影響，從而大大損傷內聚性和耦合度。單一職責就是指，只有一種單一的功能，不要為類實現過多的功能點，有些功能可以定義為接口來實現，以保證只有一個引起他變化的原因。
專注是一個人優良的品質。同樣的，單一也是一個類的優良設計，雜交不清的職責將使得代碼看起來特別別扭，牽一發動全身，有失沒敢和必然導致丑陋的系統錯誤風險。
2·開放封閉原則（Open-Closeed Principle）##
其核心思想是：軟件實體應該是可擴展的，而不可修改的。也就是，對擴展開放，對修改封閉。開放封閉原則主要體現在兩個方面
1、對擴展開放，意味着有新的需求或者變化時，可以對現有代碼進行擴展，以適應新的情況。
2、對修改封閉，意味着一旦設計完成，就可以獨立完成其工作，而不要對其進行任何嘗試的修改。
實現開放封閉原則的核心思想就是對抽象編程，而不是具體編程，因為抽象相對穩定。讓類依賴於固定的抽象類或者接口，所以修改就是封閉的。而通多面向對象的繼承和多態機制，又可以繼承抽象類或者實現接口，通過重寫其方法來改變固有的行為，實現方法新的拓展，所以就是開放的。
需求總是變化的，沒有不變的軟件，所以就需要用OCP來封閉變化，滿足需求，同時還能保持軟件內部的封裝體系的穩定，不被需求的變化影響。
3·里氏替換原則（Liskov-Substituion Principle）##
核心思想：子類必須能夠替換其父類。這一思想體現為對繼承機制的約束規范，只有子類能夠替換父類時才能保證系統在運行期內識別子類，這是保證繼承復用的基礎。在父類和子類的具體行為中，必須嚴格把握繼承層次中的關系和特征，將父類替換為子類，程序的行為不會發生任何變化。同時，這一約束反過來則是不成立的，子類可以替換父類，但是父類不一定能替換子類。
Liskov替換原則，主要着眼於對抽象和多態建立在繼承的基礎上，因此只有遵循了Liskov替換原則，才能保證繼承復用是可靠地。實現的方法是面向接口編程：將公共部分抽象為基類接口或抽象類，通過Extract Abstract Class，在子類中通過覆寫父類的方法實現新的方式支持同樣的職責。
Liskov替換原則是關於繼承機制的設計原則，違反了Liskov替換原則就必然導致違反開放封閉原則。
Liskov替換原則能夠保證系統具有良好的拓展性，同時實現基於多態的抽象機制，能夠減少代碼冗余，避免運行期的類型判別。
4·依賴倒置原則（Dependecy-Inversion Principle）##
其核心思想是：依賴於抽象。具體而言就是高層模塊不依賴於底層模塊，二者都同依賴於抽象；抽象不依賴於具體，具體依賴於抽象。
我們知道，依賴一定會存在於類與類、模塊與模塊之間。當兩個模塊之間存在緊密的耦合關系時，最好的方法就是分離接口和實現：在依賴之間定義一個抽象的接口使得高層模塊調用接口，而底層模塊實現接口的定義，以此來有效控制耦合關系，達到依賴於抽象的設計目標。
抽象的穩定性決定了系統的穩定性，因為抽象是不變的，依賴於抽象是面向對象設計的精髓，也是依賴倒置原則的核心。
依賴於抽象是一個通用的原則，而某些時候依賴於細節則是在所難免的，必須權衡在抽象和具體之間的取舍，方法不是不變的。依賴於抽象，就是對接口編程，不要對實現編程。
5·接口隔離原則（Interface-Segregation Principle）##
其核心思想是：使用多個小的專門的接口，而不要使用一個大的總接口。
具體而言，接口隔離原則體現在：接口應該是內聚的，應該避免“胖”接口。一個類對另外一個類的依賴應該建立在最小的接口上，不要強迫依賴不用的方法，這是一種接口污染。
接口有效地將細節和抽象隔離，體現了對抽象編程的一切好處，接口隔離強調接口的單一性。而胖接口存在明顯的弊端，會導致實現的類型必須完全實現接口的所有方法、屬性等；而某些時候，實現類型並非需要所有的接口定義，在設計上這是“浪費”，而且在實施上這會帶來潛在的問題，對胖接口的修改將導致一連串的客戶端程序需要修改，有時候這是一種災難。在這種情況下，將胖接口分解為多個特點的定制化方法，使得客戶端僅僅依賴於它們的實際調用的方法，從而解除了客戶端不會依賴於它們不用的方法。
分離的手段主要有以下兩種：1、委托分離，通過增加一個新的類型來委托客戶的請求，隔離客戶和接口的直接依賴，但是會增加系統的開銷。2、多重繼承分離，通過接口多繼承來實現客戶的需求，這種方式是較好的。