設計模式
零、設計原則
0.1 單一職責
0.2 接口隔離
0.3 開閉原則
0.4 依賴倒置
0.5 迪米特法則，最小知道原則
用戶關機
只和朋友通信
朋友條件：
1）當前對象本身（this）
2）以參量形式傳入到當前對象方法中的對象
3）當前對象的實例變量直接引用的對象
4）當前對象的實例變量如果是一個聚集，那么聚集中的元素也都是朋友
5）當前對象所創建的對象
0.6 里氏替換原則
代碼符合里氏替換原則
長方形繼承正方形，就是反例
根據歷史替換原則，正方形不是長方形
0.7 組合由于繼承
一丶單例模式
類加載創建對象，是餓漢式，調用方法創建對象是懶漢式
二丶簡單工廠模式（靜態工廠模式）
2.1 UML類圖
2.2 說明
封裝實例化代碼的行為
2.2 三種工廠方法區別
產品的種類很多，可以用抽象工廠模式，如果就那幾個產品可以用簡單工廠
工廠模式意義：將實例化對象的代碼提取出來，放到一個類中，統一管理和維護，達到這主項目的一來關系解耦，從而提供項目的擴展和維護性。
三丶工廠方法模式
3.1 UML類圖
3.2 說明
- 工廠方法模式：定義了一個創建對象的抽象方法，由子類決定要實例化的類。工廠方法模式將對象的實例化推遲到子類。
四丶抽象工廠模式
4.1 UML類圖
4.2 說明
- 將工廠抽象成兩層，AbsFactory(抽象工廠) 和 具體實現的工廠子類。程序員可以根據創建對象類型使用對應的工廠子類。這樣將單個的簡單工廠類變成了工廠簇，更利于代碼的維護和擴展。
五丶原型模式（克隆羊）
5.1 UML類圖
5.2 說明
- 創建新的對象比較復雜時，可以利用原型模式簡化對象的創建過程，同時也能夠提高效率
- 不用重新初始化對象，而是動態地獲得對象運行時的狀態
- 如果原始對象發生變化(增加或者減少屬性)，其它克隆對象的也會發生相應的變化，無需修改代碼
- 在實現深克隆的時候可能需要比較復雜的代碼
- 缺點：需要為每一個類配備一個克隆方法，這對全新的類來說不是很難，但對已有的類進行改造時，需要修改其源代碼，違背了ocp原則，這點請同學們注意.
比如Spring bean的的類型為prototype時會用到
深拷貝： 實現clone方法
實現序列化接口 輸出對象，再讀取對象
淺拷貝： 簡單實現
六丶建造者模式
6.1 UML類圖（傳統）
6.2 說明
建造者模式的注意事項和細節
- 客戶端(使用程序)不必知道產品內部組成的細節，將產品本身與產品的創建過程解耦，使得相同的創建過程可以創建不同的產品對象
- 每一個具體建造者都相對獨立，而與其他的具體建造者無關，因此可以很方便地替換具體建造者或增加新的具體建造者， 用戶使用不同的具體建造者即可得到不同的產品對象
- 可以更加精細地控制產品的創建過程。將復雜產品的創建步驟分解在不同的方法中，使得創建過程更加清晰，也更方便使用程序來控制創建過程
- 增加新的具體建造者無須修改原有類庫的代碼，指揮者類針對抽象建造者類編程，系統擴展方便，符合 “開閉原則”
6.3 UML類圖（改進版）
七丶適配器（手機充電）
將一個類的接口轉換成另一種接口，讓原本不兼容的類可以兼容。
7.1 UML類圖（類適配器）
7.2 說明
類適配器有繼承關系，不建議使用
根據合成復用原則，在系統中盡量使用關聯關系代替繼承關系。
7.3 UML類圖（對象適配器）
7.4 說明
對象適配器模式介紹
- 基本思路和類的適配器模式相同，只是將Adapter類作修改，不是繼承src類，而是持有src類的實例，以解決兼容性的問題。即：持有src類，實現dst類接口，完成src->dst的適配
- 根據“合成復用原則”，在系統中盡量使用關聯關系來替代繼承關系。
- 對象適配器模式是適配器模式常用的一種
7.5 UML類圖 （接口適配器）
public class Client {public static void main(String[] args) {AbsAdapter absAdapter = new AbsAdapter() {@Overridepublic void operation1() {System.out.println("調用operation1方法");}};absAdapter.operation1();}
}7.6 說明
接口適配器模式介紹
- 一些書籍稱為：適配器模式(Default Adapter Pattern)或缺省適配器模式。
- 當不需要全部實現接口提供的方法時，可先設計一個抽象類實現接口，并為該接口中每個方法提供一個默認實現（空方法），那么該抽象類的子類可有選擇地覆蓋父類的某些方法來實現需求
- 適用于一個接口不想使用其所有的方法的情況。
7.6 源碼應用
說明：
? Spring定義了一個適配接口，使得每一種Controller有一種對應的適配器實現類
? 適配器代替controller執行相應的方法
? 擴展Controller 時，只需要增加一個適配器類就完成了SpringMVC的擴展了,
? 這就是設計模式的力量
7.6 手動實現Springmvc
7.6.1 類圖
](https://i-blog.csdnimg.cn/direct/1bb21fd22eb1410aaf5c62b7c37d566d.png)
7.6.2 適配器模式的注意事項和細節
- 三種命名方式，是根據 src是以怎樣的形式給到Adapter（在Adapter里的形式）來
命名的。 - 類適配器：以類給到，在Adapter里，就是將src當做類，繼承
對象適配器：以對象給到，在Adapter里，將src作為一個對象，持有
接口適配器：以接口給到，在Adapter里，將src作為一個接口，實現 - Adapter模式最大的作用還是將原本不兼容的接口融合在一起工作。
- 實際開發中，實現起來不拘泥于我們講解的三種經典形式
八、橋接模式（手機分類）
8.1 UML類圖
解決類爆炸
8.2 說明
橋接模式(Bridge)-基本介紹
基本介紹
- 橋接模式(Bridge模式)是指：將實現與抽象放在兩個不同的類層次中，使兩個層
次可以獨立改變。 - 是一種結構型設計模式
- Bridge模式基于類的最小設計原則，通過使用封裝、聚合及繼承等行為讓不同
的類承擔不同的職責。它的主要特點是把抽象(Abstraction)與行為實現
(Implementation)分離開來，從而可以保持各部分的獨立性以及應對他們的功能
擴展
8.3 橋接模式在JDBC的源碼剖析
- Jdbc的Driver接口，如果從橋接模式來看，Driver就是一個接口，下面可以有MySQL的Driver，Oracle的Driver，這些就可以當做實現接口類
8.4 橋接模式的注意事項和細節
- 實現了抽象和實現部分的分離，從而極大的提供了系統的靈活性，讓抽象部分和實現部分獨立開來，這有助于系統進行分層設計，從而產生更好的結構化系統。
- 對于系統的高層部分，只需要知道抽象部分和實現部分的接口就可以了，其它的部分由具體業務來完成。
- 橋接模式替代多層繼承方案，可以減少子類的個數，降低系統的管理和維護成本。
- 橋接模式的引入增加了系統的理解和設計難度，由于聚合關聯關系建立在抽象層，要求開發者針對抽象進行設計和編程
- 橋接模式要求正確識別出系統中兩個獨立變化的維度，因此其使用范圍有一定的局限性，即需要有這樣的應用場景。
8.5 橋接模式其它應用場景
- 對于那些不希望使用繼承或因為多層次繼承導致系統類的個數急劇增加的系統，橋接模式尤為適用.
- 常見的應用場景:
-JDBC驅動程序
-銀行轉賬系統
轉賬分類:網上轉賬,柜臺轉賬,AMT轉賬
轉賬用戶類型:普通用戶,銀卡用戶,金卡用戶…
-消息管理
消息類型:即時消息,延時消息
消息分類:手機短信,郵件消息,QQ消息…
九、裝飾者模式（購買咖啡）
9.1 UML類圖
9.1.1 最差方案
9.1.2 第二種解決方案
9.1.3 裝飾者方案
9.1.2 說明
裝飾者模式定義
- 裝飾者模式:動態的將新功能附加到對象上。在對象功能擴展方面，它比繼承更有彈性，裝飾者模式也體現了開閉原則(ocp)
- 這里提到的動態的將新功能附加到對象和ocp原則，在后面的應用實例上會以代碼的形式體現，請同學們注意體會。
9.2 源碼
public abstract class InputStream implements Closeable{} //是一個抽象類，即Component
public class FilterInputStream extends InputStream { //是一個裝飾者類Decorator
protected volatile InputStream in //被裝飾的對象 }
class DataInputStream extends FilterInputStream implements DataInput { //FilterInputStream 子類
十、組合模式（輸出院系信息）
10.1 UML類圖
10.2 說明
- 組合模式的注意事項和細節
組合模式的注意事項和細節
- 簡化客戶端操作。客戶端只需要面對一致的對象而不用考慮整體部分或者節點葉子的問題。
- 具有較強的擴展性。當我們要更改組合對象時，我們只需要調整內部的層次關系，客戶端不用做出任何改動.
- 方便創建出復雜的層次結構。客戶端不用理會組合里面的組成細節，容易添加節點或者葉子從而創建出復雜的樹形結構
- 需要遍歷組織機構，或者處理的對象具有樹形結構時,非常適合使用組合模式.
- 要求較高的抽象性，如果節點和葉子有很多差異性的話，比如很多方法和屬性都不一樣，不適合使用組合模式
10.3 源碼應用
十一、外觀模式（家庭影院）
11.1 UML類圖（傳統方式）
11.2 傳統方式問題分析
11.3 UML類圖（外觀模式）
11.4 說明
11.5 源碼
11.6 外觀模式的注意事項和細節
- 外觀模式對外屏蔽了子系統的細節，因此外觀模式降低了客戶端對子系統使用的復
雜性 - 外觀模式對客戶端與子系統的耦合關系，讓子系統內部的模塊更易維護和擴展
- 通過合理的使用外觀模式，可以幫我們更好的劃分訪問的層次
- 當系統需要進行分層設計時，可以考慮使用Facade模式
- 在維護一個遺留的大型系統時，可能這個系統已經變得非常難以維護和擴展，此時
可以考慮為新系統開發一個Facade類，來提供遺留系統的比較清晰簡單的接口，
讓新系統與Facade類交互，提高復用性 - 不能過多的或者不合理的使用外觀模式，使用外觀模式好，還是直接調用模塊好。
要以讓系統有層次，利于維護為目的。
十二、享元模式（同一網站多種形式發布）
12.1 UML類圖（傳統）
12.2 問題分析
12.3 UML類圖（享元模式）
12.4 說明
12.5 源碼應用
public class FlyweightInInteger {public static void main(String[] args) {Integer x = Integer.valueOf(127);Integer y = new Integer(127);Integer z = Integer.valueOf(127);Integer w = new Integer(127);System.out.println(x.equals(y)); // trueSystem.out.println(x == y); // falseSystem.out.println(x == z); // trueSystem.out.println(w == x); // falseSystem.out.println(w == y); // false}
}十三、代理模式（代理老師授課）
13.1 UML類圖
13.2 說明 （靜態代理）
靜態代理在使用時,需要定義接口或者父類,被代理對象(即目標對象)與代理對象一起實現相同的接口或者是繼承相同父類
13.3 UML類圖
13.4 說明（動態代理）
13.4 Cglib代理
代理不能是final
13.5 UML類圖(Cglib)
13.6 兩者區別
jdk代理
Proxy.newProxyInstance獲取代理對象，重寫invoke方法
Cclib代理
實現MethodInterceptor接口，重寫Interceptor方法。用Enhancer獲取代理對象，在內存中生成子對象。
// 1、創建工具類Enhancer enhancer = new Enhancer();// 2、設置父類enhancer.setSuperclass(target.getClass());// 3、設置回調函數enhancer.setCallback(this);// 4、創建子類對象，即代理對象return enhancer.create();
十四、模板方法模式（制作豆漿）
制作豆漿
14.1 UML類圖
14.2 說明
14.3 UML類圖
14.4 鉤子方法
14.5 源碼分析
14.6 源碼類圖
14.7 注意事項和細節
十五、命令模式（稍微難）（遙控器控制開燈關燈）
15.1 UML類圖
15.2 說明
15.3 源碼使用
15.4 說明
十六、訪問者模式（有點難）（訪問動物園，需要買票）
16.1 UML類圖
16.2 說明
16.3 注意事項和細節
十七、迭代器模式（遍歷學校院系結構）ArrayList遍歷，沒仔細看
17.1 UML類圖
17.2 說明
17.3 源碼分析
17.3 注意事項和細節
十八、觀察者模式（天氣預報和氣象站）
18.1 UML類圖(傳統)
18.2 說明（傳統）
18.3 UML類圖（觀察者）
18.4 說明
18.5 源碼應用
十九、中介者模式（家庭影院各個設備協調工作）
19.1 UML類圖
19.2 說明
中介者模式（Mediator Pattern），用一個中介對象來封裝一系列的對象交互。
- 中介者使各個對象不需要顯式地相互引用，從而使其耦合松散，而且可以獨立
地改變它們之間的交互 - 中介者模式屬于行為型模式，使代碼易于維護
- 比如MVC模式，C（Controller控制器）是M（Model模型）和V（View視圖）的中
介者，在前后端交互時起到了中間人的作用
19.3 UML類圖
19.4 注意事項
二十、備忘錄模式（游戲角色死后恢復）
20.1 UML類圖
20.2 說明
1）備忘錄模式（Memento Pattern）在不破壞封裝性的前提下，捕獲一個對象的內
部狀態，并在該對象之外保存這個狀態。這樣以后就可將該對象恢復到原先保
存的狀態
2) 可以這里理解備忘錄模式：現實生活中的備忘錄是用來記錄某些要去做的事情，
或者是記錄已經達成的共同意見的事情，以防忘記了。而在軟件層面，備忘錄
模式有著相同的含義，備忘錄對象主要用來記錄一個對象的某種狀態，或者某
些數據，當要做回退時，可以從備忘錄對象里獲取原來的數據進行恢復操作
3) 備忘錄模式屬于行為型模式
20.3 UML類圖（游戲角色）
20.4 注意事項
二十一、解釋器模式（計算器求值）
21.1 UML類圖
21.2 說明
21.3 源碼應用
21.4 說明
解釋器模式的注意事項和細節
- 當有一個語言需要解釋執行，可將該語言中的句子表示為一個抽象語法樹，就可以
考慮使用解釋器模式，讓程序具有良好的擴展性 - 應用場景：編譯器、運算表達式計算、正則表達式、機器人等
- 使用解釋器可能帶來的問題：解釋器模式會引起類膨脹、解釋器模式采用遞歸調用
方法，將會導致調試非常復雜、效率可能降低.
二十二、狀態模式（用戶抽獎）
22.1 UML類圖
22.2 說明
- 狀態模式（State Pattern）：它主要用來解決對象在多種狀態轉換時，需要對外
輸出不同的行為的問題。狀態和行為是一一對應的，狀態之間可以相互轉換 - 當一個對象的內在狀態改變時，允許改變其行為，這個對象看起來像是改變了
其類
22.3 訂單模式
22.4 注意事項和細節
- 代碼有很強的可讀性。狀態模式將每個狀態的行為封裝到對應的一個類中
- 方便維護。將容易產生問題的if-else語句刪除了，如果把每個狀態的行為都放到一
個類中，每次調用方法時都要判斷當前是什么狀態，不但會產出很多if-else語句，
而且容易出錯 - 符合“開閉原則”。容易增刪狀態
- 會產生很多類。每個狀態都要一個對應的類，當狀態過多時會產生很多類，加大維
護難度 - 應用場景：當一個事件或者對象有很多種狀態，狀態之間會相互轉換，對不同的狀
態要求有不同的行為的時候，可以考慮使用狀態模式
二十三、策略模式（鴨子問題）
23.1 UML類圖
23.2 說明
傳統的方式實現的問題分析和解決方案
- 其它鴨子，都繼承了Duck類，所以fly讓所有子類都會飛了，這是不正確的
- 上面說的1 的問題，其實是繼承帶來的問題：對類的局部改動，尤其超類的局部改
動，會影響其他部分。會有溢出效應 - 為了改進1問題，我們可以通過覆蓋fly 方法來解決 => 覆蓋解決
- 問題又來了，如果我們有一個玩具鴨子ToyDuck, 這樣就需要ToyDuck去覆蓋Duck
的所有實現的方法 => 解決思路 策略模式 (strategy pattern)
23.3 UML類圖（策略模式）
23.4 源碼應用
23.5 注意事項
- 策略模式的關鍵是：分析項目中變化部分與不變部分
- 策略模式的核心思想是：多用組合/聚合 少用繼承；用行為類組合，而不是行為的
繼承。更有彈性 - 體現了“對修改關閉，對擴展開放”原則，客戶端增加行為不用修改原有代碼，只
要添加一種策略（或者行為）即可，避免了使用多重轉移語句（if…else if…else） - 提供了可以替換繼承關系的辦法： 策略模式將算法封裝在獨立的Strategy類中使得
你可以獨立于其Context改變它，使它易于切換、易于理解、易于擴展 - 需要注意的是：每添加一個策略就要增加一個類，當策略過多是會導致類數目龐大
二十四、責任鏈模式（OA系統審批）
24.1 UML類圖
24.2 說明
- 職責鏈模式（Chain of Responsibility Pattern）,
又叫 責任鏈模式，為請求創建了一個接收者
對象的鏈(簡單示意圖)。這種模式對請求的
發送者和接收者進行解耦。 - 職責鏈模式通常每個接收者都包含對另一個接
收者的引用。如果一個對象不能處理該請求，
那么它會把相同的請求傳給下一個接收者，依
此類推。 - 這種類型的設計模式屬于行為型模式
24.3 源碼應用
![[已解決]當啟動 Spring Boot 應用時出現 Using generated security password xxx提示](http://pic.xiahunao.cn/[已解決]當啟動 Spring Boot 應用時出現 Using generated security password xxx提示)
)
