深入理解面向对象设计的七大原则
一．面向對象設計的七大原則是什么？
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。各司其責，一目了然。
總結
以上是生活随笔為你收集整理的深入理解面向对象设计的七大原则的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 8.拉普拉斯变换
- 下一篇： BZOJ1895Pku3580 supe