設計模式

一、設計模式的分類：

設計模式可以分爲三大類：

1 創建型模式，一共有5種：工廠方法模式，抽象工廠模式，單例模式，建造者模式，原型模式。

2 結構型模式， 一共有7種：適配器模式，裝飾器模式，代理模式，外觀模式，橋接模式，組合模式，享元模式。

3 行爲型模式， 一共有11種：策略模式，模板方法模式，觀察者模式，迭代器模式，責任鏈模式，命令模式，備忘錄模式，狀態模式，訪問者模式，中介者模式，解釋器模式

序號	模式 & 描述	包括
1	創建型模式 這些設計模式提供了一種在創建對象的同時隱藏創建邏輯的方式，而不是使用新的運算符直接實例化對象。這使得程序在判斷針對某個給定實例需要創建哪些對象時更加靈活。避免用戶直接使用new運算符創建對象。	工廠模式（Factory Pattern） 抽象工廠模式（Abstract Factory Pattern） 單例模式（Singleton Pattern） 建造者模式（Builder Pattern） 原型模式（Prototype Pattern）
2	結構型模式 這些設計模式關注類和對象的組合。繼承的概念被用來組合接口和定義組合對象獲得新功能的方式。	適配器模式（Adapter Pattern） 橋接模式（Bridge Pattern） 過濾器模式（Filter、Criteria Pattern） 組合模式（Composite Pattern） 裝飾器模式（Decorator Pattern） 外觀模式（Facade Pattern） 享元模式（Flyweight Pattern） 代理模式（Proxy Pattern）
3	行爲型模式 這些設計模式特別關注對象之間的通信。	責任鏈模式（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）
4	J2EE 模式 這些設計模式特別關注表示層。這些模式是由 Sun Java Center 鑑定的。	MVC 模式（MVC Pattern） 業務代表模式（Business Delegate Pattern） 組合實體模式（Composite Entity Pattern） 數據訪問對象模式（Data Access Object Pattern） 前端控制器模式（Front Controller Pattern） 攔截過濾器模式（Intercepting Filter Pattern） 服務定位器模式（Service Locator Pattern） 傳輸對象模式（Transfer Object Pattern）

以上是23種設計模式，實際上，這23種設計模式都來自於 6大設計原則

二、6大設計原則

1，開閉原則

   定義：一個軟件的實體如類，模塊應該對拓展開放，對修改關閉

   該設計原則是6大設計原則的大哥大，我們所要設計的某個類的時候就應該想明白該類負責哪些職責，不應到了後期修改代碼，應當儘可能的去拓展代碼。換成安卓開發中，我們應當儘可能的使用接口和抽象類。

2，里氏替換原則

   定義：任何基類可以出現的地方，子類一定可以出現，即子類一定要可以替代父類

   對於該設計原則，簡單的說就是子類不可更改父類的功能和方法，如果更改，可能會導致不可預知的錯誤，給代碼帶來難以維護的後果。假設一組繼承關係中，父類需要修改，必須考慮到其所有的子類。

3，依賴倒置原則

   定義：高層模塊不應該依賴低層模塊，二者都應該依賴其抽象；抽象不應該依賴細節；細節應該依賴抽象

   依賴導致設計原則是開閉原則的基礎，簡單的說是面向接口編程，應對依賴於抽象，而不依賴於具體。在Java中，細節即實現類是多變的，抽象的東西相對於穩定的多，以抽象爲基礎搭建起來的架構比以細節搭建起來的架構穩定的多，該設計原則的核心是面向接口編程。

4，接口隔離原則

   定義：一個實現類不應該依賴於它不需要的接口；一個類對另一個類的依賴應該建立在最小的接口之上

   簡單的說就是使用多個隔離的接口比使用單獨一個接口要好，實質上是降低耦合的意思，一個類不應去實現他們不需要的方法，應當接口拆分開來使用

5，迪米特原則

   定於：一個對象應當對其他對象保持最少的瞭解

   這個很容易理解，設計功能模塊，應當相對獨立，儘量少的與其他對象產生耦合，如果不按這麼去做，可能會導致系統十分臃腫，維護一個功能模塊的方法導致另一個功能模塊也要跟着維護，增加工作量。

6，單一職責原則

   定於：不要存在多於一個導致類變更的原因

   通俗的去講，即一個類只負責一個功能，本質上講和迪米特法則有些相似，是爲了減少需求改變時產生的影響，如不遵守，會導致維護成本上升，代碼可讀性下降