原文位址： http://www.work100.net/training/monolithic-architecture-design-patterns.html 更多教程： 光束雲 - 免費課程
簡介
請參照如上
章節導航
進行閱讀
1.概述
設計模式（Design pattern）代表了最佳的實踐，通常被有經驗的面向對象的軟體開發人員所采用。
設計模式是軟體開發人員在軟體開發過程中面臨的一般問題的解決方案。
這些解決方案是衆多軟體開發人員經過相當長的一段時間的試驗和錯誤總結出來的。
這些模式或者可以簡化代碼，或者可以使代碼邏輯看起來清晰，或者對功能擴充很友善。
設計模式按照使用場景可以分為三大類：
1.1.建立型模式（Creational Patterns）- 5個
這些設計模式提供了一種在建立對象的同時隐藏建立邏輯的方式，而不是使用 new 運算符直接執行個體化對象。
這使得程式在判斷針對某個給定執行個體需要建立哪些對象時更加靈活。
- 工廠模式（Factory Pattern）
- 抽象工廠模式（Abstract Factory Pattern）
- 單例模式（Singleton Pattern）
- 建造者模式（Builder Pattern）
- 原型模式（Prototype Pattern）
1.2.結構型模式（Structural Patterns）- 8個
這些設計模式關注類和對象的組合。繼承的概念被用來組合接口和定義組合對象獲得新功能的方式。
- 擴充卡模式（Adapter Pattern）
- 橋接模式（Bridge Pattern）
- 過濾器模式（Filter、Criteria Pattern）
- 組合模式（Composite Pattern）
- 裝飾器模式（Decorator Pattern）
- 外觀模式（Facade Pattern）
- 享元模式（Flyweight Pattern）
- 代理模式（Proxy Pattern）
1.3.行為型模式（Behavioral Patterns）- 12個
行為模式不僅表達了對象和類，還表達了他們之間的互動，涉及到了對象和算法的配置設定。
- 責任鍊模式（Chain of Responsibility Pattern）
- 指令模式（Command Pattern）
- 解釋器模式（Interpreter Pattern）
- 疊代器模式（Iterator Pattern）
- 中介者模式（Mediator Pattern）
- 備忘錄模式（Memento Pattern）
- 觀察者模式（Observer Pattern）
- 狀态模式（State Pattern）
- 空對象模式（Null Object Pattern）
- 政策模式（Strategy Pattern）
- 模闆模式（Template Pattern）
- 通路者模式（Visitor Pattern）
2.設計原則
為了便于記憶，我們可以使用一個口訣來記憶面向對象設計原則：開口合裡最單依
- 開：開閉原則
- 口：接口隔離原則
- 合：組合/聚合原則
- 裡：裡式替換原則
- 最：最少知識原則（迪米特法則）
- 單：單一職責原則
- 依：依賴倒置原則
2.1.開閉原則(Open-Closed Principle, OCP)
開閉原則的意思是：對擴充開放，對修改關閉。
在程式需要進行拓展的時候，不能去修改原有的代碼，實作一個熱插拔的效果。
簡言之，是為了使程式的擴充性好，易于維護和更新。
想要達到這樣的效果，我們需要使用接口和抽象類，這是面向對象設計（OOD）的基石，也是最重要的原則。
2.2.接口隔離原則(Interface Segregation Principle, ISP)
一個類對另外一個類的依賴是建立在最小的接口上。
使用多個專門的接口比使用單一的總接口要好。根據客戶需要的不同，而為不同的用戶端提供不同的服務是一種應當得到鼓勵的做法。
就像"看人下菜"一樣，要看客人是誰，再提供不同檔次的飯菜。
胖接口會導緻他們的客戶程式之間産生不正常的并且有害的耦合關系。
當一個客戶程式要求該胖接口進行一個改動時，會影響到所有其他的客戶程式。
是以客戶程式應該僅僅依賴他們實際需要調用的方法。
2.3.組合/聚合複用原則(Composite/Aggregate Reuse Principle，CARP)
在一個新的對象裡面使用一些已有的對象，使之成為新對象的一部分。
新的對象通過這些向對象的委派達到複用已有功能的目的。
這個設計原則有另一個簡短的表述：要盡量使用合成/聚合，盡量不要使用繼承。
2.4.裡氏代換原則(Liskov Substitution Principle，LSP)
由 Barbar Liskov (芭芭拉.裡氏) 提出，是繼承複用的基石。
所有引用基類的地方必須透明的使用其子類的對象。隻要父類能出現的地方子類也可以出現，而且替換為子類不會産生任何錯誤或異常，但是反過來就不行，有子類出現的地方，父類未必就能适應。
2.5.最少知識原則(Least Knowledge Principle，LKP)
一個對象應當對其他對象有盡可能少的了解。
沒有任何一個其他的
OO
設計原則象迪米特法則這樣有如此之多的表述方式,如下幾種：
- 隻與你直接的朋友們通信(Only talk to your immediate friends)
- 不要跟"陌生人"說話(Don't talk to strangers)
- 每一個軟體機關對其他的機關都隻有最少的知識,而且局限于那些本機關密切相關的軟體機關
就是說，如果兩個類不必彼此直接通信，那麼這兩個類就不應當發生直接的互相作用，如果其中的一個類需要調用另一個類的某一個方法的話，可以通過第三者轉發這個調用。
2.6.單一職責原則(Simple responsibility pinciple，SRP)
就一個類而言，應該僅有一個引起它變化的原因，如果你能想到多于一個的動機去改變一個類，那麼這個類就具有多于一個的職責。
應該把多于的指責分離出去，分别再建立一些類來完成每一個職責。
2.7.依賴倒置原則(Dependence Inversion Principle)
這個原則是開閉原則的基礎，具體内容：針對接口程式設計，依賴于抽象而不依賴于具體。
要求用戶端依賴于抽象耦合：
- 子產品間的依賴通過抽象發生，實作類之間不發生直接的依賴關系，其依賴關系是通過接口或抽象類産生的。
- 接口或抽象類不依賴實作類
- 實作類依賴接口或抽象類
采用依賴倒置原則可以減少類間的耦合性，提高系統的穩定，降低并行開發引起的風險，提高代碼的可讀性和可維護性。
3.源碼擷取
執行個體源碼已經托管到如下位址：
- https://github.com/work100-net/training-stage2/tree/master/design-patterns https://github.com/work100-net/training-stage2/tree/master/design-patterns
- https://gitee.com/work100-net/training-stage2/tree/master/design-patterns https://gitee.com/work100-net/training-stage2/tree/master/design-patterns
上一篇：
MVC架構下一篇：
工廠模式如果對課程内容感興趣，可以掃碼關注我們的或公衆号
，及時關注我們的課程更新QQ群
