多個演算法可實現類似功能，若將所有方法寫在一個sortUtils裡面會導致難以維護，程式碼複雜。所以策略模式考慮如何讓演算法和物件分開來，使得演算法可以獨立於使用它的客戶而變化。具體的方案是把一個類中經常改變或者將來可能改變的部分提取出來，作為一個介面，然後在類中包含這個物件的例項，這樣類的例項在執行時就可以隨意呼叫實現了這個介面的類的行為。

策略模式就是用來封裝演算法的，但在實踐中，我們發現可以用它來封裝幾乎任何型別的規則，只要在分析過程中聽到需要在不同時間應用不同的業務規則，就可以考慮使用策略模式處理這種變化的可能性。

優點

1、可以動態的改變物件的行為

缺點

1、客戶端必須知道所有的策略類，並自行決定使用哪一個策略類

2、策略模式將造成產生很多策略類

輸出：
策略A的具體演算法實現
策略B的具體演算法實現
策略C的具體演算法實現

工廠模式可以分為三類：

1）簡單工廠模式（Simple Factory）：不符合開放-封閉原則

2）工廠方法（Factory Method）：生產單一產品

3）抽象工廠模式（Abstract Factory）：生產一個產品體系

簡單工廠模式有一個具體的工廠類

工廠方法模式只有一個抽象產品類，而抽象工廠模式有多個。  

工廠方法模式的具體工廠類只能建立一個具體產品類的例項，而抽象工廠模式可以建立多個。

簡單工廠模式：一個上帝類，能夠生產A車，若有一種B車需要生產，則需要更改上帝類工廠程式碼

工廠方法模式：去掉了簡單工廠模式中工廠方法的靜態屬性，使得它可以被子類繼承。由於簡單工廠模式不僅對擴充套件開放了，也對修改開放了（每新增一個類，就得去生成例項的工廠方法中增加新的分支），違背了“開放-封閉原則”。工廠方法把簡單工廠的內部邏輯判斷轉移到了客戶端程式碼來進行。缺點：每加一個產品，需要額外加一個產品工廠的類，增加了額外的開銷。

工廠模式用於處理 如何獲取例項物件問題，建造者模式用於處理如何建造例項物件 問題。

工廠方法的實現並不能減少工作量，但是它能夠在必須處理新情況時，避免使已經很複雜的程式碼更加複雜

通常設計應該是從工廠方法開始，當設計者發現需要更大的靈活性時，設計便會向其他建立型模式演化。當設計者在設計標準之間進行權衡的時候，瞭解多個建立型模式可以給設計者更多的選擇餘地

動態給一個物件新增一些額外的職責，使用Decorator模式相比用生成子類方式達到功能的擴充顯得更為靈活。

設計初衷:通常可以使用繼承來實現功能的拓展,如果這些需要拓展的功能的種類很繁多,那麼勢必生成很多子類,增加系統的複雜性,同時,使用繼承實現功能拓展,我們必須可預見這些拓展功能,這些功能是編譯時就確定了,是靜態的。

裝飾者模式：

裝飾者模式必然有一個公共的介面或抽象類，用來作為物件的傳遞。你需要根據介面實現基本的被裝飾類（Person），以及裝飾類的公共介面（Decorator ），以後所有的裝飾類都是繼承自公共的裝飾類介面，內部實現。

輸出：
具體物件的操作
具體裝飾物件A的操作
B中的新增行為 具體裝飾物件B的操作
C沒有特殊行為 具體裝飾物件C的操作

裝飾者模式也可用於給一個方法新增開始時間，結束時間，或者新增事務，提交事務等  

核心要點：有一個抽象物件類或物件介面，而具體的物件和裝飾類都要繼承類或實現這個介面

裝飾程式碼二：

public class CodingTask implements Runnable {
  private final int employeeId;
  public CodingTask(int employeeId) {
    this.employeeId = employeeId;
  }
  @Override
  public void run() {
    System.out.println("Employee " + employeeId
        + " started writing code.");
    try {
      Thread.sleep(5000);
    } catch (InterruptedException e) {
      throw new RuntimeException(e);
    }
    System.out.println("Employee " + employeeId
        + " finished writing code.");
  }
}
public class TransactionalRunnable implements Runnable {
  private final Runnable innerRunnable;
  public TransactionalRunnable(Runnable innerRunnable) {
    this.innerRunnable = innerRunnable;
  }
  @Override
  public void run() {
    boolean shouldRollback = false;
    try {
      beginTransaction();
      innerRunnable.run();
    } catch (Exception e) {
      shouldRollback = true;
      throw e;
    } finally {
      if (shouldRollback) {
        rollback();
      } else {
        commit();
      }
    }
  }
  private void commit() {
    System.out.println("commit");
  }
  private void rollback() {
    System.out.println("rollback");
  }
  private void beginTransaction() {
    System.out.println("beginTransaction");
  }
}
public class LoggingRunnable implements Runnable {
  private final Runnable innerRunnable;
  public LoggingRunnable(Runnable innerRunnable) {
    this.innerRunnable = innerRunnable;
  }
  @Override
  public void run() {
    long startTime = System.currentTimeMillis();
    System.out.println("Task started at "
        + startTime);
    innerRunnable.run();
    System.out.println("Task finished. Elapsed time: "
        + (System.currentTimeMillis() - startTime));
  }
}
public class Client {
  public static void main(String[] args) {
    new LoggingRunnable(
        new TransactionalRunnable(
            new CodingTask(0))).run();
  }
}
輸出
Task started at 1522227362358
beginTransaction
Employee 0 started writing code. 
Employee 0 finished writing code. 
commit
Task finished. Elapsed time: 5012

代理模式：為其他物件提供一種代理以控制對這個物件的訪問，使得其他物件無法直接接觸目標物件

輸出：真實物件的請求

原型模式：用原型例項指定建立物件的種類，並且通過拷貝這些原型建立新的物件。

涉及了淺拷貝與深拷貝

參考學習網址：https://www.cnblogs.com/Qian123/p/5710533.html#_label3

原型模式其實就是從一個物件再建立另外一個可定製的物件，而且不需要知道任何建立的細節

優點：建立相應數目的原型並克隆它們通常比每次用合適的狀態手工例項化該類更方便一些

輸出：
>>>>>>淺度拷貝:
大鳥  男  25
工作經歷： 1999-2002,  ZZ公司
大鳥  男  25
工作經歷： 1999-2002,  ZZ公司
大鳥  男  25
工作經歷： 1999-2002,  ZZ公司
==================================
>>>>>>深度拷貝:
大鳥  男  25
工作經歷： 1999-2002,  XX公司
大鳥  男  25
工作經歷： 1999-2002,  YY公司
大鳥  男  25
工作經歷： 1999-2002,  ZZ公司

模板方法模式：定義一個操作中的演算法的骨架，而將一些步驟延遲到子類中。模板方法使得子類可以不改變一個演算法的結構即可重定義該演算法的某些特定步驟

輸出：
具體類A的方法1實現
具體類A的方法2實現
模板方法結束
 

具體類B的方法1實現
具體類B的方法2實現
模板方法結束
 

比如 AsyncTask 裡面的四個方法 onPreExecute 、 doInBackground 、 onProgressUpdate 、 onPostExecute

還有 Android裡面的Activity 也應用了模板方法模式

onCreate 、 onStart 、 onResume 、 onPause 、 onStop 、 onDestroy 、 onRestart

為子系統中的一組介面提供一個一致的頁面，此模式定義了一個高層介面，這個介面使得這一子系統更加容易使用（完美體現了依賴倒轉原則和迪米特法則）

案例解釋：一個人買很多股票，由於股票眾多難以管理容易造成虧損，可以選擇購買基金，由基金來管理這些股票（基金擅長管理股票）

輸出：
方法組A:
子系統方法一
子系統方法二
子系統方法四
方法組B:
子系統方法三
子系統方法四

將一個複雜的物件的構建與它的表示分離，使得同樣的構建過程可以建立不同的表示。

案例解釋：麥當勞的漢堡包永遠不會少加鹽，擺攤的每次炒的東西味道可能有變化

使用建造者模式，使用者只需指定需要建造的型別就可以得到它們，而具體建造的過程和細節就不需知道了。

什麼時候使用建造者模式：需要建立一些複雜的物件，這些物件內部構建間的建造順序通常是穩定的，但物件內部的構建通常面臨著複雜的變化。

建造者模式如何實現高內聚鬆耦合的？將一個複雜物件的建立與它的表示分離，這就可以很容易地改變一個產品的內部表示，並且使得構造程式碼和表示程式碼分開。這樣對於客戶來說，它無需關心產品的建立過程，而只要告訴建造者需要什麼，就能用同樣的構建過程建立不同的產品給客戶

與抽象工廠的區別：在建造者模式裡，有個指導者，由指導者來管理建造者，使用者是與指導者聯絡的，指導者聯絡建造者最後得到產品。即建造模式可以強制實行一種分步驟進行的建造過程。

觀察者模式（釋出-訂閱模式）：定義了一種一對多的依賴關係，讓多個觀察者物件同時監聽某一個主題物件。這個主題物件在狀態傳送變化時，會通知所有觀察者物件，讓它們能夠自動更新自己

一個被觀察者管理所有相依於它的觀察者物件，並且在本身的狀態改變時主動發出通知。這通常通過呼叫各觀察者所提供的方法來實現。此種模式通常被用來實現事件處理系統。

案例解釋：前臺小姐concreteSubject、裡面的工作的人concreteObserver、老闆來了前臺小姐通知裡面工作的人馬上開始工作

輸出：
觀察者X的新狀態是ABC
觀察者Y的新狀態是ABC

觀察者Z的新狀態是ABC

應用：珠寶商運送一批鑽石，有黃金強盜準備搶劫，珠寶商僱傭了私人保鏢，警察局也派人護送，於是當運輸車上路的時候，強盜保鏢警察都要觀察運輸車一舉一動

程式：

1.     抽象的被觀察者watched介面，有addWatcher,deleteWatch,notifyWatch方法

2.     抽象的觀察者watcher介面，update方法

3.     具體的被觀察者Transporter實現watched介面

4.     三個具體的觀察者實現watcher，有具體的update方法

5.     測試類

觀察者模式在關於目標角色、觀察者角色通訊的具體實現中，有兩個版本。

一種情況便是目標角色在發生變化後，僅僅告訴觀察者角色“我變化了”，觀察者角色如果想要知道具體的變化細節，則就要自己從目標角色的介面中得到。這種模式被很形象的稱為：拉模式——就是說變化的資訊是觀察者角色主動從目標角色中“拉”出來的。

還有一種方法，那就是我目標角色“服務一條龍”，通知你發生變化的同時，通過一個引數將變化的細節傳遞到觀察者角色中去。這就是“推模式”——管你要不要，先給你啦。

提供一個建立一系列相關或相互依賴物件的介面，而無需指定它們具體的類

好處：

1.     易於交換產品系列，例如Ifactory factory = new AccessFactory()在一個應用中只需要在初始化的時候出現一次，這就使得改變一個應用的具體工廠變得非常容易，它只需要改變具體工廠即可使用不同的產品配置。

2.     它讓具體的建立例項過程與客戶端分離，客戶端是通過它們的抽象介面操縱例項，產品的具體類名也被具體工廠的實現分離，不會出現在客戶程式碼中。

所有在用簡單工廠的地方，都可以考慮用反射技術來去除switch或if，解除分支判斷帶來的耦合

缺點：如果要新增一個產品類，就得增加很多程式碼

用反射+抽象工廠的資料訪問程式

public class OperationFactory {
    private static Map<String, Class<?>> allOperationMaps = new HashMap<String, Class<?>>();
    public static void fillMap() {
      allOperationMaps.put("+", OperationAdd.class);
      allOperationMaps.put("-", OperationSub.class);
      allOperationMaps.put("*", OperationMul.class);
      allOperationMaps.put("/", OperationDiv.class);
    }
    public static Operation createOperation(String operator)
       throws InstantiationException, IllegalAccessException {
   Operation operation;
   fillMap();
   Class<?> operationClass = allOperationMaps.get(operator);
   if (operationClass == null) {
       throw new RuntimeException("unsupported operation");
   }
      operation = (Operation) operationClass.newInstance();
      return operation;
    }
}

public class Client {
    public static void main(String[] args) throws InstantiationException,
       IllegalAccessException {
      Operation operation = OperationFactory.createOperation("/");
      operation.numberA = 7;
      operation.numberB = 8;
      System.out.println(operation.result());
    }
}
  輸出：0.875

當一個物件的內在狀態改變時允許改變其行為，這個物件看起來像是改變了其類

狀態模式主要解決的是當控制一個物件狀態轉換的條件表示式過於複雜時的情況。把狀態的判斷邏輯轉移到表示不同狀態的一系列類當中，可以把複雜的判斷邏輯簡化。

好處：將與特定狀態相關的行為區域性化，並且將不同狀態的行為分割開來。

也就是將特定的狀態相關的行為都放入一個物件中，由於所有與狀態相關的程式碼都存在於某個ConcreteState中，所以通過定義性的子類可以很容易地增加新的狀態和轉換。

目的：消除龐大的條件分支語句；狀態模式通過把各種狀態轉移邏輯分佈到State的子類之間，來減少相互間的依賴。

什麼時候用：

當一個物件的行為取決於它的狀態，並且它必須在執行時刻根據狀態改變它的行為時，就可以考慮使用狀態模式。

//Context類，維護一個ConcreteState子類的例項，這個例項定義當前的狀態

public class Context {
    private State state;
    public Context(State state) {
       this.state = state;
    }
    public State getState() {
       return state;
    }
    public void setState(State state) {
       this.state = state;
    }
    public void request() {
       this.state.handle(this);
    }
}

//抽象狀態類
public abstract class State {
    public abstract void handle(Context context);
}

//具體狀態類A
class ConcreteStateA extends State {
    public void handle(Context context) {
       System.out.println("現在是在狀態A");
       context.setState(new ConcreteStateB());
    }
}//具體狀態類B
class ConcreteStateB extends State {
    public void handle(Context context) {
       System.out.println("現在是在狀態B");
       context.setState(new ConcreteStateC());
    }
}//具體狀態類C
class ConcreteStateC extends State {
    public void handle(Context context) {
       System.out.println("現在是在狀態C");
       context.setState(new ConcreteStateA());
    }
}

//客戶端：不斷請求，不斷更改狀態
public class StateClient {
    public static void main(String[] args) {
      Context context = new Context(new ConcreteStateA());
      context.request();
      context.request();
      context.request();
      context.request();
      context.request();
    }
}
輸出：
現在是在狀態A
現在是在狀態B
現在是在狀態C
現在是在狀態A
現在是在狀態B
 

將一個類的介面轉換成客戶希望的另外一個介面。Adapter模式使得原本由於介面不相容而不能一起工作的那些類可以在一起工作。

優點

　　通過介面卡，客戶端可以呼叫同一介面，因而對客戶端來說是透明的。這樣做更簡單、更直接、更緊湊。

　　複用了現存的類，解決了現存類和複用環境要求不一致的問題。

　  將目標類和適配者類解耦，通過引入一個介面卡類重用現有的適配者類，而無需修改原有程式碼。

　　一個物件介面卡可以把多個不同的適配者類適配到同一個目標，也就是說，同一個介面卡可以把適配者類和它的子類都適配到目標介面。

缺點

　  對於物件介面卡來說，更換介面卡的實現過程比較複雜。

適用場景

　　系統需要使用現有的類，而這些類的介面不符合系統的介面。

　　想要建立一個可以重用的類，用於與一些彼此之間沒有太大關聯的一些類，包括一些可能在將來引進的類一起工作。

　　兩個類所做的事情相同或相似，但是具有不同介面的時候。

　　舊的系統開發的類已經實現了一些功能，但是客戶端卻只能以另外介面的形式訪問，但我們不希望手動更改原有類的時候。

使用第三方元件，元件介面定義和自己定義的不同，不希望修改自己的介面，但是要使用第三方元件介面的功能。

實現：

public abstract class Target {
    public void request() {
   System.out.println("普通請求！");
    }
}

//需要適配的類
public class Adaptee {
    public void specificRequest() {
   System.out.println("特殊的請求！");
    }
}

//介面卡類，通過在內部包裝一個Adaptee物件，把原介面轉換成目標介面
public class Adapter extends Target {
    private Adaptee adaptee = new Adaptee();
    @Override
    public void request() {
   adaptee.specificRequest();
    }
}

//介面卡客戶端
public class AdapterClient {
   public static void main(String[] args) {
      Target target;
      target = new Adapter();
      target.request();
   }
}
輸出：
特殊的請求！
 

Android 裡的  ListView 和  RecyclerView 的 setAdapter() 方法就是使用了介面卡模式。

在不破壞封裝性的前提下，捕獲一個物件的內部狀態，並在該物件之外儲存這個狀態，這樣以後就可將該物件回覆到原先儲存的狀態

Memento比較適合用於功能複雜的，但需要維護或記錄屬性歷史的類，或者需要儲存的屬性只是眾多屬性中的一小部分時，Originator可以根據儲存的Memento資訊還原到前一狀態。

如果在某個系統中使用命令模式時，需要實現命令的撤銷功能，那麼命令模式可以使用備忘錄模式來儲存可撤銷操作的狀態。

使用備忘錄可以把複雜的物件內部資訊對其他的物件遮蔽起來，從而可以恰當地保持封裝的邊界

//備忘錄（Memento）類
  public class Memento {
    private String state;
    public Memento(String state) {this.state = state;}
    public String getState() {return state;}
    public void setState(String state) {this.state = state;}
}

//管理者（CareTaker）類：管理備忘錄
  public class CareTaker {
    private Memento memento;
    public Memento getMemento() { return memento; }
    public void setMemento(Memento memento) { this.memento = memento; }
}

//發起人（Originator） 類
  public class Originator {
    private String state;
    public Memento createMemento() { return new Memento(this.state);}
    public void recoverMemento(Memento memento) { this.setState(memento.getState()); }
    public void show() {System.out.println("state = " + this.state); }
    public String getState() { return state; }
    public void setState(String state) { this.state = state; }
}

//客戶端
  public class MementoClient {
    public static void main(String[] args) {
   // 設定初始狀態
   Originator originator = new Originator();
   originator.setState("On");
   originator.show();
   // 管理者通過備忘錄儲存狀態，由於有了很好地封裝，可以隱藏Originator的實現細節
   CareTaker careTaker = new CareTaker();
   careTaker.setMemento(originator.createMemento());
   // 改變狀態
   originator.setState("Off");
   originator.show();
   // 通過管理者從備忘錄中恢復狀態
   originator.recoverMemento(careTaker.getMemento());
   originator.show();
    }
}
  輸出：
state = On
state = Off
state = On

將物件組合成樹形結構以表示“部分-整體”的層次結構。組合模式使得用於對單個物件和組合物件的使用具有一致性

何時使用？

答：需求中是體現部分與整體層次的結構時，以及希望使用者可以忽略組合物件與單個物件的不同，統一地使用組合結構中的所有物件時，就應該考慮用組合模式

//Component為組合中的物件宣告介面，在適當情況下，實現所有類共有介面的預設行為。
public abstract class Component {
    protected String name;
    public Component(String name) { this.name = name; }
    public abstract void add(Component component);
    public abstract void remove(Component component);
    public abstract void display(int depth);
}

//Leaf在組合中表示葉節點物件，葉節點沒有子節點，實際上它的add、remove方法都是多餘的，實際上我覺得這裡有點違反了介面隔離原則：每個介面中不存在子類用不到卻必須實現的方法，也就是Component介面存在子類Leaf用不上卻必須實現的方法
public class Leaf extends Component {
    public Leaf(String name) {
        super(name);
    }
    public void add(Component component) {
        System.out.println("cannot add to a leaf");
    }
    public void remove(Component component) {
        System.out.println("cannot remove from a leaf");
    }
    public void display(int depth) {
        // 通過“-”的數目顯示級別
        System.out.println(StringUtil.repeatableString("-", depth) + this.name);
    }
}

//定義有枝節點行為，用來儲存子部件
public class Composite extends Component {
    private List<Component> children = new ArrayList<Component>();
    public Composite(String name) { super(name); }
    public void add(Component component) { children.add(component); }
    public void remove(Component component) { children.remove(component); }
    public void display(int depth) {
       // 顯示其枝節點名稱，並對其下級進行遍歷
       System.out.println(StringUtil.repeatableString("-", depth) + this.name);
        for (Component component : children) {
            component.display(depth + 2);
        }
    }
}

//客戶端。通過Component介面操作組合部件的物件
public class CompositeClient {
    public static void main(String[] args) {
      // 生成樹根，根上長出兩葉Leaf A和Leaf B
      Composite root = new Composite("root");
      root.add(new Leaf("Leaf A"));
      root.add(new Leaf("Leaf B"));
      // 根上長出分支Composite X，分支上也有兩葉Leaf X-A和Leaf X-B
      Composite compositeX = new Composite("Composite X");
      compositeX.add(new Leaf("Leaf X-A"));
      compositeX.add(new Leaf("Leaf X-B"));
      root.add(compositeX);
      // 在Composite X上再長出分支Composite X-Y，分支上也有兩葉Leaf X-Y-A和Leaf X-Y-B
      Composite compositeXY = new Composite("Composite X-Y");
      compositeXY.add(new Leaf("Leaf X-Y-A"));
      compositeXY.add(new Leaf("Leaf X-Y-B"));
      compositeX.add(compositeXY);
      // 顯示大樹的樣子
      root.display(1);
    }
}

打印出：
-root
---Leaf A
---Leaf B
---Composite X
-----Leaf X-A
-----Leaf X-B
-----Composite X-Y
-------Leaf X-Y-A
-------Leaf X-Y-B
 

程式中提到Leaf實現類實現了add與remove方法，而這兩個方法對其本身並沒有用處，這種方式叫透明方式，也就是說在Component中宣告所有用來管理子物件的方法，其中包括add、remove等，這樣實現Component介面的所有子類都具備了Add和remove，這樣做的好處就是葉節點和枝節點對於外界沒有區別，它們具備完全一致的行為介面。但問題也很明顯，因為Leaf類本身不具備Add、remove方法的功能，所以實現它是沒有意義的。

提供一種方法順序訪問一個聚合物件中各個元素，而又不暴露該物件的內部表示。

Java等語言都已經對其進行了封裝

程式介紹：用一個Aggregate裡面儲存一個list，帶有控制list的方法，而Iterator裡面包裝這個Aggregate，將對Iterator的各個介面方法的操作重寫為對Aggregate的操作。Aggregate裡面有一個可以建立其對應的Iterator的方法

//聚集介面，可以理解為Iterable
public interface Aggregate<T> {
    public Iterator<T> createIterator();
}

//具體聚集類
public class ConcreteAggregate<T> implements Aggregate<T> {
    private List<T> items = new ArrayList<T>();
    @Override
    public Iterator<T> createIterator() {
       return new ConcreteIterator<T>(this);
    }
    public int count() { return items.size(); }
    public T getItems(int index) { return items.get(index); }
    public void setItems(T item) { items.add(item); }
}

//迭代器介面
public interface Iterator<T> {
    public T first();
    public T next();
    public boolean isDone();
    public T currentItem();
}

//具體迭代器類，給出一種具體迭代的實現方式。思考：迭代器表示的是一種迭代的行為，而聚集則是真正要被迭代的資料集合。之所以要將迭代器和聚集分開，就是為了將行為與資料分開。 可類比Java中Iterator與Iterable的關係進行理解
public class ConcreteIterator<T> implements Iterator<T> {
    private ConcreteAggregate<T> concreteAggregate;
    private int current = 0;
    public ConcreteIterator(ConcreteAggregate<T> concreteAggregate) {

this.setConcreteAggregate(concreteAggregate);

}
    @Override
    public T first() { return concreteAggregate.getItems(0); }
    @Override
    public T next() {
        current++;
        if (current < concreteAggregate.count()) {
            return concreteAggregate.getItems(current);
        }
        return null;
    }
    @Override
    public boolean isDone() {

return current >= concreteAggregate.count() ? true : false;

}
    @Override
    public T currentItem() { return concreteAggregate.getItems(current); }
    public ConcreteAggregate<T> getConcreteAggregate() { return concreteAggregate; }
    public void setConcreteAggregate(ConcreteAggregate<T> concreteAggregate) {

this.concreteAggregate = concreteAggregate;

}
    public int getCurrent() { return current; }
    public void setCurrent(int current) { this.current = current; }
}

//迭代器客戶端
public class IteratorClient {
    public static void main(String[] args) {
      ConcreteAggregate<String> bus = new ConcreteAggregate<String>();
      bus.setItems("大鳥");
      bus.setItems("小菜");
      bus.setItems("行李");
      bus.setItems("老外");
      bus.setItems("公交內部員工");
      bus.setItems("小偷");
      Iterator<String> iterator = new ConcreteIterator<String>(bus);
      while (!iterator.isDone()) {
         System.out.println(iterator.currentItem() + "請買票！");
         iterator.next();
      }
    }
}
輸出：
大鳥請買票！
小菜請買票！
行李請買票！
老外請買票！
公交內部員工請買票！
小偷請買票！
 

保證一個類僅有一個例項，並提供一個訪問它的全域性訪問點。

優點：讓類自身負責儲存它的唯一例項。這個類可以保證沒有其他例項可以被建立，並且還提供了一個訪問該例項的方法，這樣就使得對唯一的例項可以嚴格地控制客戶怎樣以及何時訪問它。

懶漢式、餓漢式、synchronized懶或餓漢式、雙檢鎖DCL、volatile方式（工作記憶體優化方式）、靜態內部類方式、列舉類方式

如果單例模式不是用列舉類建立的，那麼其無法防止其序列化過程破壞單例特性，因為在序列化過程會利用反射呼叫單例的私有構造方法生成新的物件，如果要避免這種破壞，就要在單例類裡面新增方法readResolve()，

具體參考：http://mp.weixin.qq.com/s/iXC47w4tMfpZzTNxS_JQOw

1.     有一個雙重檢驗鎖的單例模式（即版本五或版本六）

2.     序列化測試程式碼如下

將抽象部分與它的實現部分分離，使它們都可以獨立地變化。

這裡並不是說讓抽象類與其派生類分離，因為這沒有任何意義，實現指的是抽象類和它的派生類用來實現自己的物件

由於實現的方式有多種，橋接模式的核心意圖就是把這些實現獨立出來，讓它們各自地變化，就使得每種實現的變化不會影響其他實現，從而達到應對變化的目的

注意：橋接模式與設計模式在程式碼上的實現時及其類似甚至相同的，不同點在於介面卡模式的介面卡類與被介面卡類是已經存在的，需要開發一個介面使得他們實現這個介面一起工作，而橋接模式是先定下介面策略，再讓不同的類去實現它。

public abstract class Abstraction {
    //橋接模式的關鍵，使得Abstraction聚合Implementor
    protected Implementor implementor;//聚合關係
    private String name;
    public Abstraction(String name) {
       this.setName(name);
    }
    public void setImplementor(Implementor implementor) {
       this.implementor = implementor;
    }
    public void operation() {
       System.out.print("Abstraction-" + this.getName() + ": ");
       implementor.operation();
    }
    public String getName() {
       return name;
    }
    public void setName(String name) {
       this.name = name;
    }
}

class AbstractionA extends Abstraction {
    public AbstractionA(String name) {
       super(name);
    }
    @Override
    public void operation() {
       super.operation();
    }
}
class AbstractionB extends Abstraction {
    public AbstractionB(String name) {
       super(name);
    }
    @Override
    public void operation() {
       super.operation();
    }
}

public abstract class Implementor {
    public abstract void operation();
}

class ConcreteImplemtorA extends Implementor {
    @Override
    public void operation() {
       System.out.println("ConcreteImplemtorA的方法執行");
    }
}

class ConcreteImplemtorB extends Implementor {
    @Override
    public void operation() {
       System.out.println("ConcreteImplemtorB的方法執行");
    }
}

public class BridgeClient {
    public static void main(String[] args) {
      Abstraction a = new AbstractionA("A");
      a.setImplementor(new ConcreteImplemtorA());
      a.operation();
      a.setImplementor(new ConcreteImplemtorB());
      a.operation();
      Abstraction b = new AbstractionB("B");
      b.setImplementor(new ConcreteImplemtorA());
      b.operation();
      b.setImplementor(new ConcreteImplemtorB());
      b.operation();
      // 這樣通過使用“組合/聚合複用原則”
      // 如果繼續有AbstractionC ... 或者ConcreteImplemtorC ...
      // 只需要擴充套件類即可，不需要修改現有類，符合“開放-封閉”原則
    }
}
輸出：
Abstraction-A: ConcreteImplemtorA的方法執行
Abstraction-A: ConcreteImplemtorB的方法執行
Abstraction-B: ConcreteImplemtorA的方法執行
Abstraction-B: ConcreteImplemtorB的方法執行
 

將以上程式碼更加具體化到現實情況的程式碼如下：

將一個請求封裝為一個物件，從而使你可以用不同的請求對客戶進行引數化；對請求排隊或記錄請求日誌，以及支援可撤銷的操作

優點

1.降低物件之間的耦合度。

2.新的命令可以很容易地加入到系統中。

3.可以比較容易地設計一個組合命令。

4.呼叫同一方法實現不同的功能

缺點

使用命令模式可能會導致某些系統有過多的具體命令類。因為針對每一個命令都需要設計一個具體命令類，因此某些系統可能需要大量具體命令類，這將影響命令模式的使用。

//知道如何實施與執行一個與請求相關的操作，任何類都可能作為一個接收者。真正執行請求的地方！
interface Reciever {   //比喻為廚師
    public void action();
}
class RecieverA implements Reciever { //烤肉的廚師
    @Override
    public void action() {
   System.out.println("RecieverA執行請求！");
    }
}
class RecieverB implements Reciever { //炒菜的廚師
    @Override
    public void action() {
   System.out.println("RecieverB執行請求！");
    }
}
class RecieverC implements Reciever {  //烤魚的廚師
    @Override
    public void action() {
   System.out.println("RecieverC執行請求！");
    }
}

//用來宣告執行操作的介面
public abstract class Command {
    //命令類，服務員手裡的訂單，訂單裡面包含了客戶想要什麼廚師做的菜
    protected Reciever reciever;
    public Command(Reciever reciever) {
       this.reciever = reciever;
    }
    public abstract void execute();
}
// 將一個接收者物件綁定於一個動作，呼叫接收者相應的操作，以實現execute
class ConcreteCommand extends Command {
    public ConcreteCommand(Reciever reciever) {
       super(reciever);
    }
    @Override
    public void execute() {
        reciever.action();
    }
}

//要求該命令執行這個請求
public class Invoker {//服務員，擁有很多訂單
    private List<Command> list = new ArrayList();
    public void addCommand(Command command) {
        list.add(command);
    }
    public void executeCommand() {
        for (Command command:list) {
            command.execute();
        }
    }
}

//建立一個具體命令物件並設定它的接收者
public class CommandClient {
    public static void main(String[] args) {
      Reciever recieverA = new RecieverA();
      Reciever recieverB = new RecieverB();
      Reciever recieverC = new RecieverC();
      Command commandA = new ConcreteCommand(recieverA);
      Command commandB = new ConcreteCommand(recieverB);
      Command commandC = new ConcreteCommand(recieverC);
      Invoker invoker = new Invoker();
      invoker.addCommand(commandA);
      invoker.addCommand(commandB);
      invoker.addCommand(commandC);
      invoker.executeCommand();
    }
}
輸出：
RecieverA執行請求！
RecieverB執行   
 
  
 

            
  
           

              
              
            
            
相關推薦
			   
            
            
            
 

    

    
    
大話設計模式、UML、設計模式Java版完全總結
     
 
                

此篇部落格為閱讀大話設計模式後的筆記記錄，注意是筆記形式，優先適合於對設計模式有一定了解的讀者，希望短時間快速溫習的讀者，同時也對所有設計模式添加了完整程式碼詮釋與註釋，方便初學者的理解，另外，文章末尾有對所有設計模式的總結，讀者若對部分設計模式容易混淆，可以到文章末尾進 

  
 

    

    
    
【Robert C. Martin部落格中文版】面向物件設計、模式、UML、敏捷方法學和極限程式設計領域。Robert C. Martin是Object Mentor公司總裁，面向物件設計、模式、UML、敏捷方法學和極限程式設計領域內的資深顧問。他不僅是Jolt獲獎
     
 
			
			面向物件設計、模式、UML、敏捷方法學和極限程式設計領域。Robert C. Martin是Object Mentor公司總裁，面向物件設計、模式、UML、敏捷方法學和極限程式設計領域內的資深顧問。他不僅是J...
		
		
        




(adsbygoogle = windo 

  
 

    

    
    
【設計模式】第一篇：概述、耦合、UML、七大原則，詳細分析總結（基於Java）
     
 ![](//p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/879cf035c7c044469f3589610c4ba7f8~tplv-k3u1fbpfcp-zoom-1.image)

迷茫了一週，一段時間重複的 CRUD ，著實讓我有點煩悶，最近打算將這些技術棧系列的文 

  
 

    

    
    
powerdesign、navacat、ER圖、uml、類圖、時序圖
     
 dea   timezone   初始化   num   idt   找到   源地址   more   選擇   關於建表和生成實體以及ER圖的簡便方法
a：用navacat客戶端生成簡單的ER圖，並生成建表sql,執行生成表。
b：用powerdesign連接數據庫，反向生成帶有註釋的ER圖。
c：用id 

  
 

    

    
    
資料結構和演算法精講版（陣列、棧、佇列、連結串列、遞迴、排序、二叉樹、紅黑樹、堆、雜湊表）Java版
     
 查詢和排序是最基礎也是最重要的兩類演算法，熟練地掌握這兩類演算法，並能對這些演算法的效能進行分析很重要，這兩類演算法中主要包括二分查詢、快速排序、歸併排序等等。我們先來了解查詢演算法! 順序查詢: 順序查詢又稱線性查詢。它的過程為：從查詢表的最後一個元素開始逐個與給定關鍵字比較，若某個記錄的關鍵字和給定值比較 

  
 

    

    
    
二叉樹、樹和森林（java版）
     
 
							
							
							什麼是樹

樹是n個結點的有限集合（n>=0）； 
樹只有一個根節點（root）； 
n>1時除了root外每個集合都是子樹；



術語

結點：包括一個數據和指向若干結點的分支。 
結點的度：結點擁有子樹的個數（為0則是葉子結點）。 
樹的度：樹 

  
 

    

    
    
設計模式之UML（一）類圖以及類間關係（泛化 、實現、依賴、關聯、聚合、組合）
     
 
							
							
							類圖用於描述系統中所包含的類以及它們之間的相互關係，幫助人們簡化對系統的理解，它是系統分析和設計階段的重要產物，也是系統編碼和測試的重要模型依據。接下來我們就來談談類圖的組成，在下一篇中我們將討論一下類圖之間的關係。

一、類圖的組成

1. 普通類



上圖 

  
 

    

    
    
【劉偉技術部落格】專注軟體架構、設計模式、重構、UML和OOAD！
     
 
    個人簡介
    
        劉偉(Sunny)，中南大學計算機應用技術博士，國家認證系統分析師（2005年），國家認證系統架構設計師（2009年，全國第四名），高階程式設計師，資料庫系統工程師，MCSE，MCDBA，CASI專業顧問與企業內訓講師。具有十多年軟體開發、專案管理及教育培訓經驗， 

  
 

    

    
    
【設計模式】四、UML建模：建立型模式，結構型模式
     
 
                1 單例模式

懶漢，餓漢



	懶漢+執行緒安全+內部類
	


2工廠模式

抽象工廠+工廠方法


UML類圖引用：



3建造者模式



備註：MilkTea即充當了產品物件，也充當了建造者本身（違反了單一責任原則），建造方法addItem()；MilkTeaB 

  
 

    

    
    
JavaScript設計模式：一、面向對象編程
     
 this   依賴   人在   turn   obj   log   javascrip   體會   創建   JavaScript面向對象編程
  眾所周知，JS作為一門腳本語言，由於其設計者在設計JS的時候，也僅僅用了很少的時間就完成了JS這門語言的創建，JS雖然擁有著腳本語言的優勢，但是JS也存在著 

  
 

    

    
    
JavaScript設計模式：一、面向對象編程（第二節）
     
 得到   調用   帶來   方式   get   特權   style   方法封裝   面向對象   一、封裝
  面向對象編程思想其中的一個特點就是封裝，通俗的講法就是把需要的功能方向在一個對象裏。遺憾的是，對於JS這種解釋性的弱類型語言沒有經典強類型語言中那樣通過class等關鍵字實現類的封裝方法，j 

  
 

    

    
    
JavaScript設計模式：一、面向對象編程（第三節）
     
 設置   style   擁有   ray   進行   如果   eat   gree   而在   一、繼承
  js並沒有繼承這一個現有的機制，所以我們所說的繼承是通過JS本身的機制去實現的。
1、類式繼承
 

 1 // 類式繼承
 2 
 3 // 父類
 4 function SuperClas 

  
 

    

    
    
Java設計模式補充：回調模式、事件監聽器模式、觀察者模式（轉）
     
 應該   hand   關閉   lan   china   關註   update   使用   event   一、回調函數
為什麽首先會講回調函數呢？因為這個是理解監聽器、觀察者模式的關鍵。
什麽是回調函數
所謂的回調，用於回調的函數。 回調函數只是一個功能片段，由用戶按照回調函數調用約定來實現的 

  
 

    

    
    
架構、框架和設計模式
     
 們的   設計模式的   發現   使用   特定   位置   業務邏輯層   工具   如果   軟件架構是系統的一個草圖，闡述了各個組件之間的通信，層次劃分，一旦系統開始詳細設計，架構藍圖就很難甚至無法改變。
例如：三層架構：一種設計軟件架構的思想。
通常意義上的三層架構就是將整個業務應用劃分為表示層（ 

  
 

    

    
    
【JS設計模式】溫習簡單工廠模式、工廠方法模式、抽象工廠模式概念
     
 his   mac   script   開頭   str   new   每一個   簡單工廠   pattern   
註：空心箭頭表示的是種繼承關系，工廠類和產品類之間是一種依賴關系。是用箭頭加虛線表示的，以下的模型圖是用的實線是不正確（時間不夠用，在這裏我偷懶了。這個習慣不好，呵呵）簡單工廠模式（S 

  
 

    

    
    
五、單例設計模式
     
 println   pre   log   內存   urn   args   懶漢   logs   pan    

/*
設計模式：解決某一類問題最有效的方式

單例設計模式：解決的是一個類在內存中只有一個對象的問題
1:構造方法私有化
2:構造方法私有化之後，一個對象都不能創建了，所以只能在類中創建對 

  
 

    

    
    
架構、框架、設計模式之間的關系簡述
     
 數據庫軟件   ron   相互   服務   語言   體系結構   表現   arch   良性   http://developer.51cto.com/art/200906/130816.htm
一、軟件體系結構和框架的定義
軟件體系結構的英文單詞是“architecture”. Architectu 

  
 

    

    
    
設計模式：對象生成（單例、工廠、抽象工廠）
     
 添加   對象實例   log   return   ray   靜態   學習   線程   tco   對象的創建有時會成為面向對象設計的一個薄弱環節。我們可以使用多種面向對象設計方案來增加對象的創建的靈活性。

單例模式：生成一個且只生成一個對象實例的特殊類
工廠方法模式：構建創建者類的繼承層級
 

  
 

    

    
    
Java設計模式學習記錄-簡單工廠模式、工廠方法模式
     
 static ip   ofa   關心   有一個   就是   con   14.   對比   div   前言
之前介紹了設計模式的原則和分類等概述。今天開啟設計模式的學習，首先要介紹的就是工廠模式，在介紹工廠模式前會先介紹一下簡單工廠模式，這樣由淺入深來介紹。
簡單工廠模式
 做法：創建一個工 

  
 

    

    
    
多線程的設計模式：Future、Master-Worker
     
 future模式   多線程   try   繼續   分享   接收   imp   線程結構   優化   一 簡介
並行設計模式屬於設計優化的一部分，它是對一些常用的多線程結構的總結和抽象。與串行程序相比，並行程序的結構通常更為復雜，因此合理的使用並行模式在多線程開發中更具有意義，在這裏主要介紹==Fu