如果說編碼是筋骨皮，那麼思想就是一口氣，就是內功。內功深厚決定你功力的大小。剛剛讀完了設計模式那本書。隨著項目業務的複雜，越發的感覺到設計模式的重要性。在此參考CSDN、伯樂在線和開源中國社區，優秀的博文，以此總結。開始新的起點。寫於2017/02/28
分析內容,屬於當第二次看設計模式的感悟,寫於2017/12/10 凌晨02:44
一、開閉原則
定義
一個軟件實體如類、模塊和函數應該對擴展開放，對修改關閉。
問題由來
在軟件的生命週期內，因為變化、升級和維護等原因需要對軟件原有代碼進行修改時，可能會給舊代碼中引入錯誤，也可能會使我們不得不對整個功能進行重構，並且需要原有代碼經過重新測試。
解決方案
當軟件需要變化時，儘量通過擴展軟件實體的行為來實現變化，而不是通過修改已有的代碼來實現變化。
表達
用抽象構建框架，用實現擴展細節因為抽象靈活性好，適應性廣，只要抽象的合理，可以基本保持軟件架構的穩定。而軟件中易變的細節，我們用從抽象派生的實現類來進行擴展，當軟件需要發生變化時，我們只需要根據需求重新派生一個實現類來擴展就可以了。當然前提是我們的抽象要合理，要對需求的變更有前瞻性和預見性才行。
分析
就是對擴展開放,對修改關閉, 裡式替換原則理論支持了這個一說法,及子類要能替換父類,這樣子類就可以在父類的基礎上,擴展
二、單一職責原則
定義
不要存在多於一個導致類變更的原因通俗的說，即一個類只負責一項職責。
問題由來
類T負責兩個不同的職責：職責P1，職責P2。當由於職責P1需求發生改變而需要修改類T時，有可能會導致原本運行正常的職責P2功能發生故障。
解決方案
遵循單一職責原則。分別建立兩個類T1、T2，使T1完成職責P1功能，T2完成職責P2功能。這樣，當修改類T1時，不會使職責P2發生故障風險；同理，當修改T2時，也不會使職責P1發生故障風險。
表達
不要讓責任擴散
分析
一個類,指責要單一,避免如果有多種職責,修改一個職責的時候,誤觸到其他職責的問題
三、里氏替換原則
定義
所有引用基類的地方必須能透明地使用其子類的對象。
問題由來
有一功能P由類A完成，現在要擴展P,其中P由類A的子類B完成，則子類在完成的同時，可能會導致原來功能故障
解決方案
當使用繼承時，遵循里氏替換原則。類B繼承類A時，除添加新的方法完成新增功能外，儘量不要重寫父類A的方法，也儘量不要重載父類A的方法。
表達
使用繼承的時候，不要隨便修改父類中已經實現的方法
分析
子類要能替換父類
四、依賴倒置原則
定義
高層模塊不應該依賴低層模塊，二者都應該依賴其抽象；抽象不應該依賴細節；細節應該依賴抽象。
問題由來
類A直接依賴類B，假如要將類A改為依賴類C，則必須通過修改類A的代碼來達成。這種場景下，類A一般是高層模塊，負責複雜的業務邏輯；類B和類C是低層模塊，負責基本的原子操作；假如修改類A，會給程序帶來不必要的風險。
解決方案
將類A修改為依賴接口I，類B和類C各自實現接口I，類A通過接口I間接與類B或者類C發生聯繫，則會大大降低修改類A的幾率。
表達
如果A依賴B，現在要改為依賴C，如果直接修改A有風險，可以讓A去依賴一個接口，BC都實現這個接口，也就是策略模式
分析
白話就是說,要根據接口或者抽象去設計,不要依賴於細節,eg.項目中要換數據庫,不用重新寫底層的數據庫代碼. 就是使用了hibernate一樣,替換方言就好了,因為hibernate是根據接口設計的,不同數據庫有不同的實現,可以直接使用. eg2: 我生病了要去買藥,如果A藥鋪,沒有我就用B藥鋪買. 因為他們都是藥鋪,都有一樣的功能,可以友好的替換
五、接口隔離原則
定義
客戶端不應該依賴它不需要的接口；一個類對另一個類的依賴應該建立在最小的接口上。
問題由來
類A通過接口I依賴類B，類C通過接口I依賴類D，如果接口I對於類A和類B來說不是最小接口，則**類B和類D必須去實現他們不需要的方法**。
解決方案
將臃腫的接口I拆分為獨立的幾個接口，類A和類C分別與他們需要的接口建立依賴關係。也就是採用接口隔離原則
表達
防止去實現不需要的接口方法，可以按接口拆分，避免臃腫。
分析
白話,接口要最小化,功能更細分. 目的是:不需要的功能,就不要去實現
比如有些接口可能裡面什麼方法都沒有，其存在的意義，就是為了其實現類擁有特殊的功能.所以我們也要怕我們的接口裡面沒有方法，就懷疑了它存在的價值
當實現RandomAccess的類比如ArrayList就具有隨機訪問的能力，而沒有實現該接口的，就只能去迭代訪問
六、迪米特法則
定義
一個對象應該對其他對象保持最少的瞭解。
問題由來
類與類之間的關係越密切，耦合度越大，當一個類發生改變時，對另一個類的影響也越大。
解決方案
儘量降低類與類之間的耦合。
表達
儘量降低類與類之間的耦合。
分析
降低類與類之間直接交互,能隱藏的屬性就可以隱藏. eg. 修電腦,去IT部門,之前一直找小張,現在小張走了,還需要重新認識小李. 迪米特法則,就是直接找IT主管,讓主管派人修. 主管就是接口，調用接口的方法，底層具體是小張還是小李，我們不用去管
這裡其實也強調了接口的重要性!
閱讀更多 東方既白 的文章
