物件導向三大特性，五大原則

以前一直認為程式中的類有使用到封裝繼承多態就是物件導向設計,其實不然 封裝,繼承,多態只是物件導向的三大特性,但是在設計程式的時候並不是說類的結構使用到了(或是體現出了)這三個特性就是物件導向, 其實真正的物件導向設計是要符合下面的五大原則, 物件導向的五大基本原則
單一職責原則（SRP）
開放封閉原則（OCP） 
裡氏替換原則（LSP） 
依賴倒置原則（DIP） 
介面隔離原則（ISP） 單一職責原則（SRP） •      一個類應該僅有一個引起它變化的原因(最簡單，最容易理解卻最不容易做到的一個設計原則)
職員類例子：
  比如在職員類裡，將工程師、銷售人員、銷售經理這些情況都放在職員類裡考慮，其結果將會非常混亂，在這個假設下，職員類裡的每個方法都要if else判斷是哪種情況，從類結構上來說將會十分臃腫，並且上述三種的職員類型，不論哪一種發生需求變化，都會改變職員類。這個是大家所不願意看到的。

開放封閉原則（OCP） •      既開放又封閉，對擴充是開放的，對更改是封閉的。 •      擴充即擴充現行的模組，當我們軟體的實際應用發生改變時，出現新的需求，就需要我們對模組進行擴充，使其能夠滿足新的需求。

更改封閉即是在我們對模組進行擴充時，勿需對源有程式碼和DLL進行修改或重新編譯檔案。

這個原則對我們在設計類的時候很有協助，堅持這個原則就必須盡量考慮介面封裝，抽象機制和多態技術。


裡氏替換原則（LSP） •      子類可以替換父類並且出現在父類能夠出現的任何地方 •      這個原則也是在貫徹GOF倡導的面向介面編程。
在這個原則中父類應儘可能使用介面或者抽象類別來實現。

子類通過實現了父類介面，能夠替父類的使用地方。
通過這個原則，我們用戶端在使用父類介面的時候，通過子類實現。
意思就是說我們依賴父類介面，在用戶端聲明一個父類介面，通過其子類來實現
這個時候就要求子類必須能夠替換父類所出現的任何地方，這樣做的好處就是，在根據新要求擴充父類介面的新子類的時候而不影響當前用戶端的使用。

依賴倒置原則（DIP） •      傳統的結構化編程中，最上層的模組通常都要依賴下面的子模組來實現，也
稱為高層依賴低層。
所以DIP原則就是要逆轉這種依賴關係，讓高層模組不要依賴低層模組，所以稱之為依賴倒置原則。

ISP 介面隔離原則 •      這個原則的意思是：使用多個專門的介面比使用單個介面要好的多。

這個我有體會，在我實際編程中，為了減少介面的定義，將許多類似的方法都放在一個介面中，最後發現，維護和實現介面的時候花了太多精力，而介面所定義的操作相當於對用戶端的一種承諾，這種承諾當然是越少越好，越精練越好，過多的承諾帶來的就是你的大量精力和時間去維護。

透切理解物件導向三大基本特性是理解物件導向五大基本原則的基礎

三大基本特性：封裝，繼承，多態

封裝，就是把客觀事物封裝成抽象的類，並且類可以把自己的資料和方法只讓可信的類或者對象操作，對不可信的進行資訊隱藏。一個類就是一個封裝了資料以及操作這些資料的代碼的邏輯實體。在一個對象內部，某些代碼或某些資料可以是私人的，不能被外界訪問。通過這種方式，對象對內部資料提供了不同層級的保護，以防止程式中無關的部分意外的改變或錯誤的使用了對象的私人部分。

繼承，指可以讓某個類型的對象獲得另一個類型的對象的屬性的方法。它支援按級分類的概念。繼承是指這樣一種能力：它可以使用現有類的所有功能，並在無需重新編寫原來的類的情況下對這些功能進行擴充。 通過繼承建立的新類稱為“子類”或“衍生類別”，被繼承的類稱為“基類”、“父類”或“超類”。繼承的過程，就是從一般到特殊的過程。要實現繼承，可以通過 “繼承”（Inheritance）和“組合”（Composition）來實現。繼承概念的實現方式有二類：實現繼承與介面繼承。實現繼承是指直接使用 基類的屬性和方法而無需額外編碼的能力；介面繼承是指僅使用屬性和方法的名稱、但是子類必須提供實現的能力。

多態，是指一個類執行個體的相同方法在不同情形有不同表現形式。多態機制使具有不同內部結構的對象可以共用相同的外部介面。這意味著，雖然針對不同對象的具體操作不同，但通過一個公用的類，它們（那些操作）可以通過相同的方式予以調用。

五大基本原則：SPR, OCP, LSP, DIP, ISP

單一職責原則SRP(Single Responsibility Principle)

是指一個類的功能要單一，不能包羅永珍。如同一個人一樣，分配的工作不能太多，否則一天到晚雖然忙忙碌碌的，但效率卻高不起來。

開放封閉原則OCP(Open－Close Principle)

一個模組在擴充性方面應該是開放的而在更改性方面應該是封閉的。比如：一個網路模組，原來只服務端功能，而現在要加入用戶端功能，那麼應當在不用修改服務端功能代碼的前提下，就能夠增加用戶端功能的實現代碼，這要求在設計之初，就應當將服務端和用戶端分開，公用部分抽象出來。

替換原則LSP(the Liskov Substitution Principle LSP)

子類應當可以替換父類並出現在父類能夠出現的任何地方。比如：公司搞年度晚會，所有員工可以參加抽獎，那麼不管是老員工還是新員工，也不管是總部員工還是外派員工，都應當可以參加抽獎，否則這公司就不和諧了。

依賴原則DIP(the Dependency Inversion Principle DIP)

具體依賴抽象，上層依賴下層。假設B是較A低的模組，但B需要使用到A的功能，這個時候，B不應當直接使用A中的具體類： 而應當由B定義一抽象介面，並由A來實現這個抽象介面，B只使用這個抽象介面：這樣就達到了依賴倒置的目的，B也解除了對A的依賴，反過來是A依賴於B定義的抽象介面。通過上層模組難以避免依賴下層模組，假如B也直接依賴A的實現，那麼就可能 造成循環相依性。一個常見的問題就是編譯A模組時需要直接包含到B模組的cpp檔案，而編譯B時同樣要直接包含到A的cpp檔案。

介面分離原則ISP(the Interface Segregation Principle ISP)

模組間要通過抽象介面隔離開，而不是通過具體的類強耦合起來