大部分時候寫的程式碼太亂了，找點邏輯看看。這個是從《人人都懂設計模式》裡摘錄的，加上我可能用到的理解。寫給自己參考的。花了3天讀了一下。

UML常見關係

泛化

一種實現形式，從基類到特定的子類。最為常用，空心箭頭，實線。

實現

實現的強弱關係和泛化一樣，不一樣的是父類為介面，使用的是虛線而不是實線。

組合

在visio裡較複合，其中被聚合的部分離開整體後無法單獨存在。因此關係之間更強。實心菱形，實線。電腦為呼叫者，元件為被呼叫者。

聚合

被聚合的類可以離開整體而單獨存在。公司為呼叫者，員工為被呼叫者。

關聯

一種呼叫關係，從呼叫者指向被呼叫者，呼叫者操作被呼叫者的類。為下圖上面。

依賴

一種呼叫關係，從呼叫者指向被呼叫者，呼叫者操作被呼叫者的方法。為下圖下面。

監聽模式

1. 建立被觀察者和觀察者

2. 將觀察者新增到被觀測者列表

3. 對被觀測者進行資料操作

4. 被觀察者通過觀察者的內部方法訪問，對其進行通知

5. 通知過程中，觀察者可能需要通過被觀察者的內部方法訪問，獲得資料資訊。

狀態模式

1.【使用者】建立上下文環境實現類

2. 【上下文環境實現類】新增狀態類到上下文環境類中的陣列

3. 【使用者】呼叫上下文環境類的行為

4. 【上下文環境實現類】根據當前的狀態呼叫對應狀態的行為

5. 【使用者】改變上下文環境類的屬性資訊

6. 【上下文環境實現類】根據改變的資訊遍歷狀態，獲取狀態的行為資訊

中介模式

1. 建立中介物件

2. 建立互動物件

3.互動物件中傳入中介物件方法，新增互動物件到中介物件

4. 使用者物件中傳入中介物件方法，獲取中介物件提供的服務，間接知道互動物件

【互動複雜度轉換為了中介的複雜度導致的中介複雜，多個使用者等問題】

裝飾模式

【元件1和元件2為出口，裝飾器為棧呼叫形式，每個裝飾器實現中存放了上一個裝飾器實現，最深的一層為元件】

1. 【使用者】建立元件1

2. 【使用者】建立裝飾器1，並將元件1傳入裝飾器1，得到裝飾器1

3. 【使用者】建立裝飾器2，並將裝飾器1傳入裝飾器2，得到裝飾器2

4. 【使用者】呼叫裝飾器的函式功能，【函式功能】呼叫自身的【新增行為】方法，對存放的上一層【函式功能】進行呼叫。

5. 【最後一層】【函式功能】為元件，呼叫元件的函式功能，最後呼叫棧向上走，到最後一程裝飾器的【函式功能】

6. 結束

單例模式

【使得使用者只能從該類中建立一個物件，繼續建立則返回第一個建立的物件例項】

【匿名物件好像預設就是單例的啊，建立的地址都一個】

1. 重寫__new__方法，當首次建立物件，則將例項儲存，後續建立則使用第一次的例項，儲存的位置為類的私有變數，__init__方法修改為首次建立，則進行初始化，否則不初始化。首次建立的flag存放在類的私有變數。

2. 自定義metaclass

3. 自定義裝飾器實現。

def decoder_x(cls, *args, **kwargs):
    instance = {}
    def wrap_x(*args, **kwargs):
        if cls not in instance:
            instance[cls] = cls(*args, **kwargs)
        return instance[cls]
    return wrap_x

克隆模式

克隆出一樣的，然後修改吧，deepcopy

職責模式

1. 建立請求者和責任者們

2. 為請求者和責任者建立上層責任者

3. 【使用者】傳送請求，責任者1處理請求，然後判斷是否呼叫上層責任者

4. 上層責任者依次處理請求。

代理模式

【這裡的客戶端指代使用者】

1. 【使用者】建立真實主題類

2. 【使用者】建立代理主題類，並將真實主題類傳入

3. 【使用者】對【代理主題類】傳送請求，代理主題類經過前處理，訪問真實主題類，後處理，完成請求過程。

外觀模式

【外觀模式為複雜的子系統提供了一層抽象，當子系統無法真實維護，但又可用，建立對外的統一介面，方便使用】

【客戶端和使用者含義相同】

1.【使用者】建立外觀類

2.【外觀類】掛載子系統類

3.【使用者】操作外觀類，【外觀類】訪問子系統，完成功能。

迭代模式

【迭代器模式，客戶端一般通過next方法獲取下一個元素等】

iter函式將可迭代資料型別轉換為迭代器型別，可使用next方法。

組合模式

1. 【使用者】建立一些組成部分

2. 【使用者】新增一些元件到各個組成部分

3. 【使用者】將子組成部分新增到組成部分

4. 【使用者】最大的組成部分執行操作，如顯示特徵，則逐個呼叫。

【組成部分的聚合關係，表示了組成部分會遍歷其元件】

構建模式

1. 【使用者】建立構建者

2. 【使用者】呼叫構建產品

3. 【構建者】建立並構建對應的產品

適配模式

1. 【客戶端】呼叫其他目標類的實現，正常

2. 【客戶端】間接呼叫被適配物件，則通過介面卡【直接】呼叫，介面卡通過對被適配物件的修正，完成訪問的方法。

【和什麼外觀模式，代理模式還有點像哈】

策略模式

1. 【使用者】建立上下文環境（它是需要策略的）

2. 【使用者】建立策略如策略1，並將其裝入上下文環境中

3. 【使用者】執行上下文操作介面，【上下文環境】呼叫對應的策略執行動作。

sorted重寫比較器就是這樣簡單的

工廠模式

我覺得工廠模式有點亂，可能是比較靈活的原因。其中UML繪製可能有點出入，但是大體思想是從工廠裡，建立並返回物件。

可能二級工廠就夠了，這個是三級的，不過用起來應該會很方便吧。

1. 【使用者】建立工廠，如工廠1

2. 【使用者】操作工廠，傳入引數，工廠根據引數對產品建立，返回產品。

3. 【使用者】操作產品的方法，完成任務。

命令模式

我這裡修改了客戶端到排程者、命令為實線箭頭。

【客戶端和使用者同義】

1. 【使用者】建立排程者

2. 【使用者】建立命令

3. 【使用者】將命令放入排程者中

4. 【排程者】根據命令，選擇執行命令，【命令】訪問【接收和執行】，執行直接內容。

備忘模式

1. 【使用者】建立發起人

2. 【使用者】對發起人寫入資料

3. 【使用者】呼叫發起人建立備忘錄

4. 【使用者】建立備忘錄管理器，將備忘錄插入管理器

5. 【使用者】從備忘錄管理器中獲取備忘錄，呼叫發起人，傳入備忘錄，從而恢復資料

享元模式

【客戶端理解為使用者，使用者在訪問工廠中的產品時，因資源限制，這些產品是公共享用的，且只生成一次（set判斷）】

1. 【使用者】建立輕量級工廠，傳入引數獲得指定輕量級

2. 【輕量級工廠】根據是否建立了對應的輕量級，來動態建立輕量級，並返回給使用者

3. 【使用者】操作輕量級，完成功能。

非共享輕量級可能和工廠模式或者構建模式像。

訪問模式

【客戶端是使用者】

1. 【使用者】建立資料結構管理器，建立資料節點

2. 【使用者】將資料節點插入資料結構管理器中

3. 【使用者】建立訪問者，將訪問者傳入資料結構管理器，執行動作。

4. 【資料結構管理器】執行客戶端行為，呼叫資料節點的訪問方法

5. 【資料節點】呼叫訪問者的訪問方法，完成訪問操作。

模板模式

我覺得就是抽象類和具體類的區別吧，一套公用的介面，然後大家都實現它。

橋接模式

說是和策略模式有點像，我想是這樣的：橋接模式是用於對程式碼重構的思考，如果程式層次性太深或拓展性不夠，是否可將下層的部分作為上層的一個元件形式，即聚合關係，橋接到上層。

【抽象類（形狀）實現類（顏色）橋接，從而使用者在建立形狀的時候，儘管有各種形狀和各種顏色，但是因為顏色成為一個形狀的元件，因此只需關注形狀類，而顏色類可以自由拓展】

解釋模式

【用於表示式的解析和執行上】

1. 【使用者】將資料傳入到抽象表示式中，根據表示式常用的思路，以棧的形式首先對錶達式解析，然後儲存到棧中。

2. 【抽象表示式】通過逐層呼叫，找到最內部的表示式，解析並將結果返回給上層表示式。

3. 以此類推，獲得最終結果。