一．面向對象設計的七大原則是什么？

1.開放封閉原則

2.里氏轉換原則

3.依賴倒轉原則

4.組合/聚合原則

5.接口隔離原則

6.“迪米特”法則

7.單一職責原則

二．七大原則是什么含義？

序號	面向對象設計七大原則	偶的理解
1	開放封閉原則	面向擴展開放，面向修改關閉
2	里氏轉換原則	超類存在的地方，子類是可以替換的
3	依賴倒轉原則	實現盡量依賴抽象，不依賴具體實現
4	組合/聚合原則	要盡量使用合成/聚合達到復用，而不是繼承關系達到復用的目的。
5	接口隔離原則	應當為客戶端提供盡可能小的單獨的接口，而不是提供大的總的接口
6	“迪米特”法則	又叫最少知識原則，一個軟件實體應當盡可能少的與其他實體發生相互作用
7	單一職責原則	每一個類應該專注于做一件事情

?

三．解讀七大原則：

1.開放封閉原則

偶的理解

偶是做底層的設計與編碼，譬如：車載導航系統的引擎的。該引擎系統包括地圖數據格式的解析，圖層添加、修改、刪除等；地圖符號的編輯、顯示與潤色，基于兩個地點之間的最短時間/最短距離的路徑規劃等等功能。

?

做車載導航系統的應用層的同事，不能修改偶核心層代碼，也就是說您不能修改偶的接口，但是您可以針對偶的接口做一些擴展。也就是：對接口的修改是封閉，但是對接口的擴展是開放。

為什么這樣？

1.同事修改偶的核心層代碼不合適，畢竟這些偶是專門整天研究這個的，偶專業呀；

2.同事為了自己的一己私利，修改了接口（如添加參數，修改了參數數據類型或者去掉某個參數），但是基于偶的核心車載導航引擎的，不只同事一個人用，好多同事與第三方公司都編譯不過，一堆會找上門來，罵你個狗血噴頭；

3.但是同事，將偶的引擎接口擴展了，自己用，影響不到其他人，多好的一件事情；

2.里氏轉換原則

任何基類可以出現的地方，子類一定可以出現。即超類存在的地方，子類是可以替換的。替換后行為不變，結果會變化。調用子類行為。

子類和父類必須有相同行為才能完全地實現替換。

實現開閉原則的關鍵是抽象化，而里氏代換原則中的基類和子類的繼承關系正是抽象化的具體體現，所以里氏代換原則是對實現抽象化的具體步驟的規范。違反里氏代換原則

偶的理解

想通過基類的指針，調用虛擬函數，搞多態，讓一個函數，針對不同的派生類指針，會有不同的表現行為。派生類的虛擬函數，不能搞特殊。派生類的指針不能賦值給基類，哪就胡扯。

?

里氏代換原則是要求我們在使用繼承時，必須滿足一定的條件。不能為了復用，一味去繼承。

3.依賴倒轉原則

抽象不應該依賴細節。細節應該依賴抽象。

偶的理解

設計接口的時候，不應該說俺設計的這一個接口，就是給這個某一個具體實現功能而設計。

哪就不叫面向對象設計了，抽象了也啥意思。因為你只為某一個具體功能而設計。

?

但是具體編碼實現某一個功能，還是要依賴于某一具體的接口的。

?

注意這是面向對象設計，設計什么呢？設計接口。接口是一個一對多的關系。一對多啥意思，就是一個接口，有多種實現。

?

哦！明白了。多態，講的就是這個意思，一個接口，多種行為方式。掛上鉤了。O(∩_∩)O~。

類似：活著與吃飯的關系

活著不是為了吃飯，但是吃飯為了活著。

4.組合/聚合原則

偶的理解

《設計模式》里23個模式，就是整篇整篇地講如何類與類之間的組合/聚合。

?

如果為了復用，便使用繼承的方式將兩個不相干的類聯系在一起，違反里氏代換原則，哪是生搬硬套，忽略了繼承了缺點。

?

繼承的缺點有：

?

1、繼承復用破壞數據封裝性，將基類的實現細節全部暴露給了派生類，基類的內部細節常常對派生類是透明的，白箱復用。

雖然簡單，但不安全，不能在程序的運行過程中隨便改變。

?

2、基類的實現發生了改變，派生類的實現也不得不改變。

?

3、從基類繼承而來的派生類是靜態的，不可能在運行時間內發生改變，因此沒有足夠的靈活性。

5.接口隔離原則

應當為客戶端提供盡可能小的單獨接口，而不要提供大的總接口。暴露行為讓后面的實現類知道的越少越好。

偶的理解

人家需要什么，你給人家提供什么。

否則如果接口給人家提供多了，暴露多了，自己的麻煩不少。人家會問：

1.這個接口是干什么的，怎么用啊；

2.這個接口與另外一個接口有什么區別啊？又有什么聯系啊？什么情況下用這個接口，什么情況下用另外一個接口；

?

總之，問得你煩死了，煩透了。最后，沒辦法，只好弄一個版本，就是提供客戶需要的接口，告訴他如何使用，一了百了。清閑自在多了。

?

真是你好！我好！大家好！

?

一旦某個漂亮的女孩子穿衣服，要是暴露多了，又露胸，又露屁股，被人家一陣狂扁，“看哪個不要臉的狐貍精”，“傷風敗俗，缺家教”，“看又一個暴露狂”。搞的人家MM都要奔潰，跳黃河自殺。偶算明白了。技術原理來源于生活。道理都是相通的。O(∩_∩)O~

6.“迪米特”法則

又叫最少知識原則，一個對象對另一個對象知道的越少越好，即一個軟件實體應當盡可能少的與其他實體發生相互作用。

?

如果兩個類不必彼此直接通信，那么這兩個類就不應當發生直接的相互作用。如果其中一個類需要調用另一個類的某一方法的話，可以通過第三者轉發這個調用。

偶的理解

一個類包裝好自己的private狀態和方法，不需要讓別的類知道字段或者行為，就不要公開喲！

?

強調類之間的松耦合。

?

類與類之間的耦合性越低，一旦一個處于弱耦合的類的代碼被修改了，不會對有關系的類造成波及與影響。這樣，這個類的復用性大大增強，提高了開發效率，降低了出錯的可能性。

?

哥最怕的是修改了某一個不起眼的類一點代碼，跟她發生關系的類太多。牽一發而動全身。會發生多米諾效應。咱可惹不起。誰知道，會出現什么后果！汗顏！

7.單一職責原則

每一個類應該專注于做一件事情。

偶的理解

這個講的就是商業領域里面的定位概念。想打官司，找律師；想看病，找醫生；想學習，找老師。

?

一個類一個具體作用，如微軟的VC?MFC里的CBrush、CPen、CFont等就是這個意思，想搞字體用CFont，想用畫筆用CPen，想用刷子，用CBrush。各司其責，一目了然。