EasyJavaDesignPatterns
定義了演算法家族，個別封裝起來，讓它們之間可以互相替換，此模式讓演算法的變動，不會影響到使用演算法的程式。
合成比較好，有一個的概念會比是一個的概念來得通用，一個要吸引獵物的獵人會”有"武器攻擊獵物，而不是本身超強攻擊獵物，武器的靈活性就高多啦。
出版者 ＋ 訂閱者 ＝ 觀察者模式
觀察者模式定義物件之間一對多的關係。
訂閱者和出版者之間是可鬆綁的，出版者只需知道誰訂閱了相關消息，再透過傳送消息的介面告訴訂閱者，不需要知道訂閱者收到消息要衝三小。
實踐此模式可以藉由 介面把資料推出去或者，通知對方來啦資料，理論上推出去的安全性高點，如果還沒拉到就變更資料的話，會掉資料。
此模式在Android 被大量使用，像是Listener 啊 Broadcast Receiver 的註冊都是 觀察者模式的應用。
動態地將責任加諸於物件上，若要擴充功能，裝飾者提供了比繼承更有彈型的選擇。
裝飾者和被裝飾者有相同的超型態。
裝飾者可以在所委派被裝飾者的行為之前或之後加上自己的行為。
範例了一個武器( 被裝飾者) 附魔(裝飾者)的概念簡單的Code。
定義了一個建立物件的介面，但由次類別決定要實體化的類別為何者。工廠方法讓類別把實體化的動作，交由次類別進行。
(盡量)
- 變數不可以持有具象類別的參考。
- 不要讓類別繼承自具象類別
- 不要讓次類別中的方法推翻超類別的方法
##抽象工廠模式
定義了一個介面，建立相關或相依物件之家族，而不需要明確指定具象類別。
對於單一個物件創造使用的是工廠模式，對於一堆物件組合成的物件，可用抽象工廠去創造一堆物件的介面，然後由工廠決定實作的具象類別。
##獨體模式
獨體模式：確保一個類別只有一個實體，並給他一個存取的全域點。
如果不希望這個物件被重複創造，使用獨體模式會是好的選則。
把建構式設定private 使外不能直接創建物件，給予全域靜態的method 去創建自己的實體>。
##命令模式
命令模式：將請求封裝成物件，以便使用不同的請求，佇列，或者日誌，參數化其他物件。命令模式也支援可恢復的作業。
可以把一堆要做的事包裝成command物件，放到陣列中一個一個做，把要做的是包裝同一種執行方法，像是go , do , run ,excute讓接受這些command的控制器可以簡單地去告訴該做事的人做事，就像是員工聽到”上班"就會去做他們份內的事，你可以在對的時間叫他們上班也可以一個一個叫(command Q)，而不用知道上班實際內容為何。
##轉接器模式
轉接器模式：將一個類別的介面轉乘另一個介面以供其他類別或者客戶所使用。 轉接器讓原本不相容的介面可以合作。
譬如原本只有武器可以攻擊對手，我也想用道具去攻擊對手，我就製作一個ItemToWeapon的adapter，把道具丟進這個Adapter讓他像武器一樣用。
一些常見的還有像把Map 轉成Json Object也很合適去製作一個Adapter。
##表象模式
表象模式：提供了一個統一的介面，用來存取次系統中的一群介面，表象定義了一個較高層次的介面，讓次系統更容易使用。
譬如說，一個連續技，包含了三百招六十四掌二十句垃圾話，把招式，掌，垃圾話等等包進Combo表象物件中，把連續技的尻法寫在其中，外面只要對這個表象物件下達使用連續技指令而不用實際一招一招接，相對省事，就算要改掉其中內容，改表象物件即可，使用者不須知道內容改了啥可繼續使用連續技。
##樣板方法模式
樣板方法模式：將一個演算法的骨架定義在一個方法中，而演算法本身會用的一些方法，則是定義在次類別中。樣板方法讓次類別可以在不改變演算法架構的情況下，重新定義演算法中的某個步驟。
跟工廠模式相當類似，一個是把類別實作的取得交給次類別去決定，一個是演算法包在父類別，而讓子類別可以決定方法的實作，有兩種方式，一種是使用抽象方法，另一種是先把一個方法放在父類別而做預設的事，子類別可以決定要不要複寫方法(掛鉤)。
##反覆器模式
反覆器模式：讓我們能夠取得一個聚集內每一個元素，而不需要此聚集將其實踐方法曝露出來。
把重複訪問的演算法用反覆器包裝起來，使得要重複訪問這些物件的人，只要知道其反覆器就好，不用知道實際訪問的演算法。____ ##合成模式
合成模式：允許你將物件合成樹狀結構，呈現[部分/整體]的階層關係。合成能讓客戶程式碼以一致的方式處理個別物件，以及合成物件。
把英雄分成隊伍，可以直接對英雄隊伍點名，他會列出所有隊伍裡的英雄，以及裡面子隊伍的英雄。
##狀態模式
狀態模式：允許物件隨著內在的狀態改變而改變行為，好像物件的類別改變了一樣。類別圖看起來跟策略完全一模一樣，但用意不同ㄡ
用來做一些常態狀態不同去實作不一樣的行為，有點類似策略模式，但策略模式的變更實作主要是由外部去定義，狀態模式的變更實作主要用自身去定義，譬如我沒有工作的狀態無法工作，一旦我被雇用了自動將狀態改為有工作，實作就會改成有辦法工作如此。
##代理人模式
代理人模式：讓某個物件具有一個替身，藉以控制外界對此物件的接觸。
基本上類別圖應該跟裝飾者大同小異，不過目的不同，代理人模式的目的是幫忙物件處理相關判斷及拋出例外之類的事項，是保護存取的動作，譬如說存密碼帳號一定要大於四個字或三個字，判斷其大於四個或三個字的判斷可以由代理人物件去做篩選。
裝飾者偏向於動態的幫物件增加要做的事，或者改變其參數的附加物，比較不屬於保護存取的動作判斷。
動態代理人：在執行期決定要使用哪種代理人，譬如非自己的帳戶只能使get的方法而不能使用其他方法這樣，可以在拿到其User資料決定要使用哪種代理人，自己或者非自己的的代理人。
##MVC模式
複合模式：結合兩個或以上的模式，組成一個新的解決方案，可以解決一再發生的一般性問題。
MVC是一種複合模式，結合了觀察者，策略模式等等。 Controller 是View 的決策。
MVC模式，簡單的說就是把資料的實際操作包裝到Model中，把控制Model的方法用Controller包裝起來，然後使用View去觸發Model的操作，使之Model跟View有抽換的空間，基礎就是策略模式啦， 整個流程大致是這樣： 1.使用者從View互動。 2.根據View的互動，對應到相對的Controller的Interface 3.controller根據互動決定要改變哪個view或者告知Model做事。 4.model或者view做完事之後再透過Controller決定要不要執行下個動作，像是告知view，Model的變更。 5.View向Model詢問，然後呈現變更後結果的View。 大致是這樣(隨著情況可以方便變更)
##反模式
告訴你如何採用一個不好的解決方案解決一個問題。 就像是我之前寫的東西又爛擴充性又差，後來我改過自新了，我把之前的爛code寫成文件，說明這邊為什麼不好，為什麼有問題，來告知自己以及其他人不要犯同樣的錯誤這樣。
##心得
模式不一定要用，但要懂得概念，在適合的情境下去使用，有時硬是去使用模式，只會徒增複雜度， 一開始設計時不用刻意去想說要用什麼模式，而是一邊寫一邊發現適合可以用哪種模式時再加入模式。 兩種情況適合模式的存在，一個是問題需要解決，一個是確信未來的需求改變需要用此模式。