一、GRASP模式(通用責任分配軟件模式)概述
1.1、理解責任
1）什么是責任
責任是類間的一種合約或義務,也可以理解成一個業務功能,包括行為、數據、對象的創建等
知道責任——表示知道什么
行為責任——表示做什么
責任＝知道責任＋行為責任
2）知道責任與行為責任
知道責任:
了解私有封裝數據
了解關聯的對象
了解能夠派生或計算的事物
行為責任:
如何完成對象初始化
如何執行一些控制行為
3）責任的理解
責任不是類的方法,類的方法用於【實現行為責任】。責任更可以理解成是系統應提供的一個業務功能
責任的分配可使用順序圖或協作圖來表達(之后會講到UML中的圖)
面向對象設計過程就是將責任分配給對象的過程
4）舉例說明
在一個銷售業務中,存在一個交費行為(業務功能),可將它識別為一個責任：
行為責任表示交費的行為,需要創建一的個付款記錄對象Payment。
知道責任必須知道付款記錄類Payment,知道如何記錄及計算Payment類中的數據。
二、GRASP模式的分類
作用/則重點:完成責任分配(以及分配責任的時候需要注意的點)
GRASP模式也是遵循基本的設計原則的(也就是說GRASP模式是在基本設計原則基礎之上建立的)。
2.1、Information Expert（信息專家）
誰能夠在某方面具有完整的信息，足以實現某個責任，就將責任分配給這個類，這個類即所謂的信息專家。
總結為"誰知道誰負責"
1.要知道的責成內容是什么
2.完成這個責任需要哪些信息
3.哪些對象擁有這些完成的信息
4.分配責任的同時不能違反基本的設計原則
例如:在購物車系統中，要讓每個商品（Item）在購物車（ShoppingCar）中只出現一次，如果放相同的商品到車上就只更新該商品的數量而不增加商品項。
2.2、Creator（創造者）
A是B的容器或者A和B是聚合關系
A有初始化B所需的信息
A需要記錄/使用B的實例
具有以上特性，可讓A具有創建/創造B類對象的責任
例如:我們使用過的工廠類ConnectionFactory/SessionFactory以及spring中的容器都是這個遵循這種責任配置模式下的產物。
2.3、Low Coupling（低耦合）
減少類間的耦合（關聯/依賴等等），使一個類的修改對其它類的影響范圍有所降低，從而系統變得更容易維護
使得系統變得更容易理解
總結為"不要和陌生人說話"
2.4、High Cohesion （高內聚）
提高類的通用性，並控制類的復雜程度，努力分解類使得類具有獨立的責任.
優點:
高內聚可表現關聯責任的一個抽象，易於實現類的重用
高內聚使維護工作變得簡單
高內聚使得系統模塊化工作，方便團隊工作
例如:
非常低的內聚：一個類單獨處理很多不同模塊的事務。比如它既處理對數據庫的存取，又處理用戶接口圖形處理。
比較低的內聚：一個類單獨處理一個模塊內的所有事務。
高內聚：類只處理與模塊相關的功能，一個類具有一個相對獨立的責任，且與其它類合作共同完成任務。
2.5、Controller （控制器）
能全面代表系統或子系統的類，比如系統事件的接收和處理通常由一個高級類來代替，稱為控制器類.
不要試圖只定義一個控制器類，那樣會違反高內聚的原則，一個子系統會有多個控制器類，分別處理不同的事情.
控制器不是用戶界面類，但通常與界面類關聯(MVC模式).
2.6、Polymorphism （多態）
在OOP看來，提供了靜態多態和動態多態，前者包括函數重載和模板兩種形式，都是在編譯期根據參數類型檢查來確定調用哪個函數或使用哪個具體參數類型；
后者運行時即時編譯根據內存和虛函數表查找確定調用哪個函數.
多態，尤其是動態多態性使得系統具有不變應萬變的特性.
2.7、Pure Fabrication （純虛構）
和多態性是同一概念，虛構頂層基類針對抽象編程。
純虛構就是要虛構一個基類，將對象盡量組織成繼承樹的形式，客戶端代碼只引用了基類的形式。
例如:
設計一個繪圖類，要求能在不同的系統如Linux以及Windows下繪畫，如何滿足？設計一個高層次的抽象類，用於分配這個職責。
2.8、Indirection （間接）
增加一個中介類，用於避免兩個類直接耦合。
在實體世界向關系世界的轉化中，對多對多的關系需要增加一個實體轉換為兩個一對多關系。
例如:
n n
Employee-----------Position
n 1 1 n
Employee-----------Assignment-------------Position
員工類 分配類 崗位類
(這是個中介類)
一個員工對於一個分配方式
一個分配方法對於一個崗位
分配類將員工類和崗位類間的多對多關系轉換為兩個1對多的關系
2.9、Protected Variations （受保護變化）
估計出需求中容易變化的點，為其設計穩定的接口，也就是開閉原則：對於修改是關閉的，對於擴展是開放的。
通過擴展已有部件，可以提供新的行為以滿足新需求，就使變化中的軟件系統具有一定的適應性和靈活性。
已有的軟件模塊，最重要的抽象層模塊不能再修改，就使變化中的軟件系統具有一定的穩定性和延續性。
這個原則說的是，在設計一個模塊的時候，應該可以使這個模塊可以在不被修改的前提下被擴張。換言之，應該可以在不必修改源代碼的情況下改變這個模塊的行為。
三、COF設計模式概述
作用/則重點:代碼的結構/完成的功能(以及這種結構的代碼能解決哪一類問題)
GOF模式是遵循着GRASP模式的(也就是說GOF是在GRASP模式基礎之上建立的)
GOF設計模式分為23種
GoF是指Erich Gamma、Richard Helm、Ralph Johnson、John Vlissides四個人，他們四個人被稱為Gang of Four，縮寫GoF。這四個人曾經合著過一本書
《Design Patterns: Elements of Reusable Object-Oriented Software》，也就是大名鼎鼎的《設計模式》一書。此書流傳很廣，已經是程序員界的聖經之一了。
這本書中介紹了23種設計模式，雖然設計模式其實不止這23種，但是由於這23種太常用了，所以我們一般說到設計模式，就是指GoF的23種設計模式。
四、GOF設計模式分類概述
創建型模式，共五種：工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式。
結構型模式，共七種：適配器模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。
行為型模式，共十一種：策略模式、模板方法模式、觀察者模式、迭代模式、責任鏈模式、命令模式、備忘錄模式、狀態模式、訪問者模式、中介者模式、解釋器模式。
4.1、創建型模式
4.1.1、工廠方法模式(Factory-Method)
1）普通工廠模式
2）多個工廠方法模式
3）靜態工廠方法模式
4.1.2、抽象工廠模式(Factory)
工廠方法模式有一個問題就是，類的創建依賴工廠類，也就是說，如果想要拓展程序，必須對工廠類進行修改，這違背了閉包原則.
4.1.3、單例模式(Singleton)
1）類中定義一個private static修飾的當前類的類型的變量
2）當前類的構造器用private修飾
3）提供一個public static修飾的方法,用來獲得當前類的單例對象.
4.1.4、建造者模式(Builder)
將一個復雜對象的構建與它的表示分離
4.1.5、原型模式(Prototype)
原型模式的主要思想是基於現有的對象克隆一個新的對象出來，一般是有對象的內部提供克隆的方法，通過該方法返回一個對象的副本
4.2、結構型模式
4.2.1、適配器模式(Adapter)
將一個類的接口轉換成客戶希望的另外一個接口,Adapter模式使得原本由於接口不兼容而不能一起工作的那些類可以一起工作。
4.2.2、裝飾器模式(Decorator)
動態地給一個對象添加一些額外的職責。就增加功能來說，Decorator模式相比生成子類更為靈活。
4.2.3、代理模式(Proxy)
spring AOP
4.2.4、外觀模式(Facade)
為系統中的一組接口提供一個一致的訪問方式
4.2.5、橋接模式（橋模式(Bridge)）
舉例:
汽車在路上行駛,即有小汽車又有公共汽車，它們都不但能在市區中的公路上行駛，也能在高速公路上行駛。對於交通工具（汽車）有不同的類型，然而它們
所行駛的環境（路）也在變化，在軟件系統中就要適應兩個方面的變化？怎樣實現才能應對這種變化呢？
4.2.6、組合模式（Composite）
將對象組合成樹形結構以表示"部分-整體"的層次結構
4.2.7、享元模式（共享模式(Flyweigth)）
String對象的運用
4.3、行為型模式
4.3.1、策略模式(Strategy)
定義一系列的算法,把它們一個個封裝起來,並且使它們可相互替換。本模式使得算法可獨立於使用它的客戶而變化。
4.3.2、模板方法模式
定義一個操作中的算法的骨架，而將一些步驟延遲到子類中。
4.3.3、觀察者模式(Observer)
被觀察的對象的狀態發生改變時,所有觀察它的對象都得到通知並被自動更新
4.3.4、迭代模式(Iterator)
List Iterator
4.3.5、責任鏈模式(Chain of Responsibility)
Filter Interceptor
4.3.6、命令模式(Commad)
將一個請求封裝為一個命令對象，從而使你可用不同的請求對客戶進行參數化；對請求排隊或記錄請求日志，以及支持可撤消的操作
4.3.7、備忘錄模式（紀念品模式(Memento)）
在不破壞封裝性的前提下，捕獲一個對象的內部狀態，並在該對象之外保存這個狀態。這樣以后就可將該對象恢復到原先保存的狀態。
4.3.8、狀態模式(State)
對象中的狀態改變,對象的操作也隨之改變
4.3.9、訪問者模式(Visitor)
它使你可以在不改變類的前提下執行作用於類中元素的新操作。
4.3.10、中介者模式(Mediator)
用一個中介對象來封裝一系列的對象交互。中介者使各對象不需要顯式地相互引用，從而使其耦合松散，而且可以獨立地改變它們之間的交互。
4.3.11、解釋器模式
接下來將慢慢的介紹這些設計模式了！
喜歡就點個“推薦”哦！