關於解耦的研究(三)設計模式與解耦

前言

設計模式對於任何一個軟件開發人員來講，我想都不會陌生，這部經典鉅著在軟件開發人員心中的地位也是神聖般的存在。

雖然不少學校在大學階段、研究生階段便加入來此類課程的教學，但能掌握其精髓，融會貫通的人少之又少。

筆者身邊很多資深軟件開發人員都曾說，設計模式是須要多年開發經驗的積累的，只有當你編寫了不少程序在回過頭來讀這本書時，才能感覺到其中的精髓，理解其中的奧義！

本文要點

本文的目的不是講解設計模式，而是已解耦爲目的，吸收研究設計模式中關於解耦相關的經驗。文中不少內容也是筆者經過看書及他人文章總結的，感謝前人寶貴的經驗以及樂於奉獻的精神！
經過本篇文章，你將要了解到：

1.設計模式六大原則與解耦的關係
2.經常使用與解耦的設計模式之組合模式；
3.經常使用與解耦的設計模式之事件隊列；
4.經常使用與解耦的設計模式之服務定位器；

六大原則與解耦的關係

單一職責原則

單一職責原則很簡單，它就像內聚度中的功能內聚，其聚合度最高，固然耦合度也會最低

里氏替換原則

子類因爲繼承類父類的屬性和方法，天然與父類產生了必定程度的耦合，增長了耦合度，同時其餘模塊與子類的耦合也將轉移至父類，必定程度上能夠把耦合集中

依賴倒置原則

依賴抽象，依賴接口編程，和耦合的關係彷佛不大

接口隔離原則

類不該該依賴它不須要的接口，和耦合的關係彷佛也不大

迪米特法則

儘可能少暴露實現細節，其餘模塊對此模塊所需細節瞭解的越少，模塊間的耦合度越低

開閉原則

對擴展開放，對修改關閉。當耦合度很低的時候，發生變化，天然能夠極大減小修改

總結一下

1.遵照單一職責、迪米特法則能夠有效下降耦合。
2.適當運用里氏替換原則，控制父子類間的耦合，或把耦合集中給父類。
3.開閉原則將受益於耦合度的下降。
4.依賴倒置原則和接口隔離原則讓我很糾結，對耦合度影響彷佛不大，僅能一
定程度提高內聚度，更關乎與接口的設計。

接下來談下經常使用於解耦的設計模式：

組合模式

在oop的開發中，繼承是必不可少的，隨着功能模塊複雜度的提升，繼承的結構也會愈來愈龐大，愈來愈複雜，子類與父類耦合度極具增高，然而複雜的繼承體系中，每每存在着不少獨立，相互並不關聯的模塊，這樣的混合形成了不少沒必要要的耦合性，爲了解決此類問題，組合模式應運而生。

組合模式，主要是用來描述總體與部分之間關係。設計模式中的定義爲將對象組合成樹形結構以表示「部分-總體」的層次結構，使得用戶對單個對象和組合對象的使用具備一致性。

組合模式詳解https://www.runoob.com/design...

案例實戰：待補充

事件隊列模式

平常開發中，當某一個一塊狀態發生變化時，常常須要通知其餘模塊，一般的作法是在觸發模塊增長一個函數，將須要通知的模塊的邏輯寫入其中，已達到通知的效果。然而這樣就讓變化的觸發模塊和變化後要處理的模塊產生了耦合。當接受變化的處理模塊變更時，或者觸發模塊變更時，必須修改各模塊邏輯，違反了開閉原則。

創建一個事件隊列模塊來維護全部的事件，在模塊發生變化時，觸發模塊拋出對應事件給事件隊列，而變化接收者僅須要在事件隊列中註冊想要接收的事件，這就是事件隊列模式的簡單介紹。經過事件隊列模式變化的觸發者和變化的接收者就能夠徹底解除耦合，極大下降耦合度。

事件隊列模式詳解https://blog.csdn.net/u010223...

案例實戰：待補充

服務定位器模式

平常開發中很難避免不少全局的系統如音效播放，日誌系統、外部的sdk等，這些系統可能會滲入咱們開發的軟件中的各個角落，產生大量耦合，而服務定位器則就能夠有效下降這種狀況產生的耦合。

建立一個服務定位器模塊，用來提供一些全局必須的服務。全局的系統模塊由原來的單例調用或靜態直接調用，改成從服務定位器中獲取，服務定位器返回的能夠是接口或者基類、或者包含接口的空服務，這樣服務使用者和服務器提供者之間的耦合將有效下降。也能夠在服務定位器中方便的更換全局的服務提供者，帶來更大的擴展性。

服務定位器模式詳解https://www.runoob.com/design...

案例實戰：待補充

以上均爲本人拙見，以後也會不斷精進及深刻研究，本文將長期維護，不斷優化。。。

歡迎各位大佬提供寶貴建議，助力完善！

上一篇關於解耦的研究(二)之基礎解耦實踐下一篇 思考中