原文地址：http://www.work100.net/training/monolithic-architecture-design-patterns.html
更多教程：光束雲 - 免費課程
簡介
| 序號 | 文內章節 | 視頻 |
|---|---|---|
| 1 | 概述 | - |
| 2 | 設計原則 | - |
請參照如上章節導航進行閱讀
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)
這個原則是開閉原則的基礎，具體內容：針對接口編程，依賴於抽象而不依賴於具體。
要求客戶端依賴於抽象耦合：
- 模塊間的依賴通過抽象發生，實現類之間不發生直接的依賴關係，其依賴關係是通過接口或抽象類產生的。
- 接口或抽象類不依賴實現類
- 實現類依賴接口或抽象類
採用依賴倒置原則可以減少類間的耦合性，提高系統的穩定，降低並行開發引起的風險，提高代碼的可讀性和可維護性。
如果對課程內容感興趣，可以掃碼關注我們的
公衆號或QQ羣，及時關注我們的課程更新
