設計模式
1.Factory pattern（簡單工廠模式）
目的：定義一個用於創建對象的接口，此接口可以根據子類需要創建出不同的實例對象。
適用：適用於需要延遲創建對象的場景
優點：使產品的使用和產品的生產分開，客戶在使用不同的方法創建出的產品時沒有差異，所以在使用的代碼流程上無需修改
缺點：每個單獨的工廠模式只能生產同一類產品，存在分支判斷，由於要保存使用流程的一致，所以創建類時需要抽象出產品中一般的行爲
public class JavaProject {
public static void main(String[] args) {
Operation operation = OperationFactory.createOperation("+");
operation.mNumberA = 10;
operation.mNumberB = 20;
System.out.println("Result:" + operation.calcResult());
}
public static abstract class Operation{
int mNumberA;
int mNumberB;
public abstract int calcResult();
}
public static class OperationFactory{
public static Operation createOperation(String operation){
Operation oper = null;
if(operation.equals("+")){
oper = new OperationPlus();
}else if(operation.equals("-")){
oper = new OperationMinus();
}else if(operation.equals("*")){
oper = new OperationMul();
}else if(operation.equals("/")){
oper = new OperationDiv();
}else{
}
return oper;
}
}
public static class OperationPlus extends Operation{
@Override
public int calcResult() {
return (mNumberA + mNumberB);
}
}
public static class OperationMinus extends Operation{
@Override
public int calcResult() {
return (mNumberA - mNumberB);
}
}
public static class OperationMul extends Operation{
@Override
public int calcResult() {
return (mNumberA * mNumberB);
}
}
public static class OperationDiv extends Operation{
@Override
public int calcResult() {
if(mNumberB == 0){
return 0;
}
return (mNumberA / mNumberB);
}
}
} 2.Strategy pattern（策略模式）
目的：用於封裝經過抽象的算法，這些算法之間具有可替換性，使算法的使用獨立於客戶的使用
適用：客戶希望同時存在多種算法以便在不同的場景中使用
優點：使算法獨立於客戶的使用，使用者無需關心處理的細節，也無需增加額外判斷該使用哪種算法
缺點：要求不同的算法都處理同一件事情
3.Decorator pattern（裝飾模式）
目的：對已有對象動態的添加新的功能，保留對象的核心功能。就擴展性來說，裝飾着模式比生成一個子類要簡單
適用：當新增的功能只是某個類在特定情況下才會適用或者並非該類的主要功能時，爲了避免在該類中新增字段和方法導致類的複雜度上升
優點：把類的裝飾功能從類中搬移出去，保留類的核心功能，使原有的類得到了簡化
缺點：裝飾模式在某些場合下要求有一定的裝飾順序，理想的情況是各個裝飾功能彼此獨立
4.Proxy pattern（代理模式）
目的：爲其他對象提供一個代理以控制對這個對象的訪問
適用：
1）遠程代理，爲不同地址空間的訪問提供解決方案
2）虛擬代理：讓代理處理開銷很大的對象
3）安全代理：提供不同的訪問權限
4）智能指引：交給代理一些權限讓它在特定的時候完成一些事情。
5.Factory Method（工廠方法）
目的：Factory Method是簡單工廠的進一步抽象和推廣，只是將簡單工廠內部的必要的邏輯判斷移到客戶端來完成
適用：當項目中每個邏輯判斷所要完成的事情較多的時候可以採用此方法將不同的邏輯判斷轉化成不同的工廠類
優點：克服簡單工廠模式違背開放-封閉原則，又保持了將對象的創建過程封裝起來的目的
缺點：每增加一種不同的對象時需要新增一個工廠類
6.Prototype （原型模式）
目的：用原型實例來指定創建對象的種類，並通過拷貝來實現對象的創建
適用：當需要創建一批具有相同或大致相同屬性的對象（對象的屬性較多），一般用實現clone的接口來完成原型拷貝
優點：簡化創建對象時不斷初始化相同的內容的情況
缺點：要注意深層拷貝和淺層拷貝的問題
7.Template Method（模版方法）
目的：定義出一個算法的骨架，將一些變化的的步驟延遲到子類中去實現
適用：當固定不變的行爲與一些可變的行爲混在類中實現的時候，可將固定不變的部分抽離到父類中
優點：無需更改整個算法的結構就可以重定義某些算法的步驟
缺點：比較難以界定固定不變的行爲和固定的行爲，當固定的行爲發生變化時會增加了編程/維護的複雜度
8.Facade pattern（外觀模式）
目的：爲子系統提供一組一致的界面，此模式定義了一個高層接口，這個接口使得這個子系統更加容易使用。
適用：當一個子系統隨時間的推移越加複雜的時候可以考慮爲此複雜的字系統提供一個簡單的接口，以降低子系統與外界的耦合性
優點：模塊化設計，降低模組間耦合性，外界無需瞭解太多子系統的具體實現
9.Builder（建造者）
目的：將一個複雜對象的創建與他的表示分離。使相同的構建過程表示不同的類，其核心特徵是抽象出某個複雜對象的各個部分（或者步驟），以保證創建的完整性
適用：當創建複雜的對象時需要將算法獨立於該對象的組成部分以及他們的裝備方式
優點：使對象的創建與對象的使用隔離，降低耦合性，而且保證了創建對象的各個步驟的完整性
PS: 或許builder 模式與工廠模式有異曲同工之妙，但是builder 的核心在於將複雜對象的的各個部分（或者步驟），以保證創建的完整性，而builder的實現必須依靠抽象類或接口來完成。
10.Observe（觀察者）
目的：將一個系統分割成一系列相互協作的模組存在一個副作用，那就是需要維護相同模組之間的一致性。我們不希望爲了維護一致性而是各個模組之間緊密耦合，這樣會給維護、擴展和重用帶來麻煩。觀察者模式則是在定義出一個或者多個觀察者對象來監聽某個主題對象的狀態變化，當主題對象發生變化時所有登記過的觀察者就會收到消息通知相關的對象。
適用：當一個對象或者模組的狀態發生改變時如果需要通知其他對象，
優點：將兩個相關聯的對象之間的依賴關係抽象出來，在不改變對象實現的情況下實現相關模組間的同步，降低對象之間的耦合
11.Abstract Factory（抽象工廠）
目的：提供一個接口，此接口用來描述一個複雜子系統會用到的所有功能的抽象方法，方便在不同子系統之間切換來適應不同的環境需要
適用：通常用於一個較爲複雜的子系統，且此子系統的具體實現方式可能會改變，有時可以理解成對工廠方法的進一步抽象（將不同的工廠集中到一個類中，方便集體被替換）
優點：通過最小的改動來達到更換子系統的目的，使整個子系統的實例化過程與客戶端分離，客戶通過操縱抽象的工廠接口來選擇不同的子系統
PS：注意一次性聲明需要的子系統的類型，避免在每個具體的類中去修改
12.State （狀態模式）
目的：當控制一個對象狀態轉移的條件過於複雜的時候，可以將各個狀態的判斷邏輯轉移到不同的類或者方法中。
適用：如果軟件要實現的功能分成幾個特定的狀態（或者說一個對象的行爲取決於它的狀態），而每個狀態要負責的功能過於複雜的時候可以考慮將不同狀態下要完成的事情轉移到子類或者方法中。
優點：減少過多的判斷邏輯（分支語句）集中在一個方法（類）中，使代碼的可讀性增加，減少相互間的依賴關係
13.Adapter（適配器模式）
目的：將一類接口轉換成客戶希望另外一類接口，使得原本不兼容的接口可以一同工作
適用：通常用於項目後期對大型的接口維護，當兩個接口所完成的事情類似時可以通過適配器的方式將一個接口進行轉換以符合客戶希望的另一個接口
優點：無需更改現存的類即可實現複用，客戶只需調用統一的接口即可
缺點：容易被濫用，適配器模式屬於無奈之舉，有點像亡羊補牢，開發初期重構要比使用適配器模式要好。
PS: 適配器模式的概念也被擴大化，實際開發中不同環境下數據的表現形式不同，可以適配器負責處理不同數據表現形式之間的轉換
14.Memento（備忘錄模式）
目的：在不破壞封裝性的前提下，將對象的狀態在對象之外進行保存，以便將對象恢復到所保存的狀態
適用：功能比較複雜且需要記錄歷史屬性的對象
優點：不破壞對象的封裝性，將保存對象歷史屬性的功能放在對象之外，降低耦合性也便於統一的修改
缺點：過多的使用備忘錄會耗費較多的系統資源
15.Composite（組合模式）
目的：將對象組合成 部分-整體 的層次結構，使得用戶對單個對象或者組合對象的使用具有一致性
適用：需體現部分與整體的層次關係；希望用戶忽略組合對象與單個對象在使用上的不同
優點：用戶無需確認部分-整體之間的差別，使用上比較統一，可實現批量化處理
16.Iterator（迭代器）
目的：當需要順序的訪問某一聚合對象，又不希望暴露對象的內部
適用：當一個聚合對象需要被一種或多種方式遍歷時；多種遍歷方式
優點：迭代器的原理就是將對聚合對象的遍歷方式抽離出來，讓迭代器負責對局和對象的訪問，這樣既達到透明的訪問聚合對象內部，又不會暴露聚合對象。
PS:迭代器的使用已經相當普遍，有的語言（如Java）已經將這種模式做到了語法的內部（如foreach 用法）
17.Singleton（單例模式）
目的：保證一個類僅有一個實例，並提供一個訪問它的全局訪問點
適用：希望控制用戶何時\以何種方式訪問一個對象，並希望只存在一個實例的情況，一些工具類通常都是採用了靜態的單例模式
優點：採用私有構造方法，實現對象的受控訪問，且在只需實例化一個對象的場景，用戶在使用上比較方便
缺點：需要考慮多線程下創建對象的線程安全
18.Bridge（橋接模式）
目的：將系統的抽象部分與它的實現部分分離，使他們都可以獨立的變化
適用：實現系統可能有多角度分類，每一種分類都有可能變化，主要用於設計初期
優點：只使用繼承來實現系統會增加大量的類，且不能滿足開放-閉合原則，這個時候將這種多角度分類抽離出來讓他們獨立的變化，可以減少他們之間的耦合
19.Command（命令模式）
目的：將一個請求封裝爲一個對象，從而可以用不同的請求對客戶進行參數化；對請求排隊或者記錄請求日誌，以及支持可撤銷的操作
適用：當需要恢復/撤銷等操作時，一般是在項目開發過程中發現需求後重構出命令模式
優點：1）比較容易設計一個命令隊列；2）方便支持撤銷與重做；3）可以較容易的將請求記入日誌；4）加入新的命令不會影響其他的對象。實現了將發出請求與如何執行請求分離。
缺點：應避免爲代碼添加基於猜測的、實際不需要的功能
20.Chain of Responsibility（職責鏈模式）
目的：使多個對象都有機會處理請求，從而避免請求的發送者與請求的執行者之間的耦合關係。將這些能處理請求的對象練成一條鏈，並沿這條鏈傳遞請求，直到有一個對象處理它爲止
適用：職責鏈是對C語言中單項鍊表的一種擴展，當你需要靈活的增刪改查處理請求的結構時可考慮使用職責鏈模式
優點：請求的發送者和請求的接收者都沒有對方明確的信息，處在鏈中的對象也並不瞭解整個鏈的結構。結果是職責鏈可以簡化對象的相互連接，他們僅需要保存一個後繼者的引用
public class JavaProject {
public static void main(String[] args) {
KeyNode keyNodeA = new HotKeyA(0x10);
KeyNode keyNodeB = new HotKeyB(0x20);
KeyNode keyNodC = new HotKeyC(0x30);
keyNodeA.mNextNode = keyNodeB;
keyNodeB.mNextNode = keyNodC;
System.out.println("Process:" + keyNodeA.handKeyCode(0X20));
}
public static abstract class KeyNode{
public static int mNumberCnt = 0;
int mKeyCode;
int mNumber = mNumberCnt++;
KeyNode mNextNode = null;
public KeyNode(int keyCode){
mKeyCode = keyCode;
}
public abstract void operate();
public boolean handKeyCode(int KeyCode){
boolean handle = false;
System.out.println("node number " + mNumber);
if(KeyCode == mKeyCode){
System.out.println("handle key by " + getClass().getName());
handle = true;
}else if(mNextNode != null){
mNextNode.handKeyCode(KeyCode);
}
return handle;
}
}
public static class HotKeyA extends KeyNode{
public HotKeyA(int keyCode) {
super(keyCode);
}
@Override
public void operate() {
System.out.println("HotKeyA operate.");
}
}
public static class HotKeyB extends KeyNode{
public HotKeyB(int keyCode) {
super(keyCode);
}
@Override
public void operate() {
System.out.println("HotKeyB operate.");
}
}
public static class HotKeyC extends KeyNode{
public HotKeyC(int keyCode) {
super(keyCode);
}
@Override
public void operate() {
System.out.println("HotKeyC operate.");
}
}
}
21.Mediator（中介模式）
目的：用一箇中介對象來封裝一系列的對象交互，中介者使各個對象之間不必顯示地進行交互，從而使其鬆散耦合，而且可以獨立地改變它們之間的交互
適用：一般用於一組定義良好的對象但是進行復雜的方式進行通信的場合；以及想定製一個分佈在不同類中的行爲，而又不想生成太多的類
優點：Mediator 減少了各個對象之間的耦合，使各個對象和Mediator可以各自獨立的變化和複用，且將Mediator作爲一個獨立的概念並將其封裝在一個對象中，這樣關注的焦點就從關注對象本身的實現轉移到對象之間的關係，這就能從更宏觀的角度上去看待一個系統
缺點：Mediator 將各個對象之間的交互複雜性轉移到mediator的複雜性，使Mediator的複雜性增加，較難以維護
22.Flyweitht（享元模式）
目的：運用共享技術支持大量細粒度的對象
適用：需要生成大量細粒度對象來表示數據，而這些對象只有幾個屬性不同，就可以考慮使用享元模式。Java的String對象就是採用了享元模式。
優點：通過共享相同的數據大幅度的減少系統的開銷
缺點：享元模式內部需要維護已經共享數據的列表，增加了享元模式複雜度，使得程序的邏輯更加複雜化。
23.Interpreter（解釋器模式）
目的：給定一個語言，定義它文法的一種表示，並定義一個解釋器，這個解釋器使用該表示來解釋語言中的句子
適用：如果一個問題發生的頻率足夠高，那麼就值得將該問題的實例表述一個個簡單的語言中的列子。這樣可以構建一個解釋器，該解釋器通過解決這些句子來解決該問題。（機器語言向彙編語言的轉變就是個典型的解釋器模式）
優點：方便用戶解決問題，減少對問題的細節瞭解
缺點：解決問題的效率必定降低
24.Visitor（訪問者模式）
目的：表示一個作用於對象結構中各元素的操作。它使你在不改變元素類的前提下定義作用於這些元素的新操作（把處理數據從數據結構中分離出來）
適用：適用於數據結構相對穩定的系統
優點：訪問者模式將數據結構和操作數據結構之間的耦合解開，使操作的集合可以自由的演化。增加新的操作很容易，因爲增加新的操作相當於增加一個新的訪問者
缺點：如果被訪問的數據結構成員要發生變化會變得比較困難
