【部落格大賽】23種設計模式娓娓道來，助你優雅的編寫出漂亮代碼！

大家好，我是小羽。

我們平時使用的每一個技術棧的原理或者源碼都或多或少與設計模式的理念有關聯，也可以這麼說，隻有更好的掌握了設計模式，我們的代碼編寫才能更規範、簡潔，效率更高。

其次，設計模式大多都是經過我們的前輩的經驗反複總結而成，站在巨人的肩膀上，吸收他們的經驗教訓，我們的編碼之路才會走的更長久。

同時，在我們的面試過程中也是加分的選項，你如果将設計模式能跟面試官娓娓道來，面試官肯定會對你刮目相看的。工作中，擁有良好的設計模式思想，對于項目的開發也會有很大的幫助。

接下來，跟着小羽一起來看看我們需要了解的設計模式都有哪些呢～

前言

總體來說設計模式分為三大類：

建立型模式：工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式。

結構型模式：擴充卡模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。

行為型模式：政策模式、模闆方法模式、觀察者模式、疊代子模式、責任鍊模式、指令模式、備忘錄模式、狀态模式、通路者模式、中介者模式、解釋器模式。

單例模式

概念

確定某一個類隻有一個執行個體，而且自行執行個體化并向整個系統提供這個執行個體。

使用場景

要求生成唯一序列号的環境；
在整個項目中需要一個共享通路點或共享資料，例如一個Web頁面上的計數器，可以不用把每次重新整理都記錄到資料庫中，使用單例模式保持計數器的值，并確定是線程安全的；
建立一個對象需要消耗的資源過多，如要通路IO和資料庫等資源；
需要定義大量的靜态常量和靜态方法（如工具類）的環境，可以采用單例模式（當然，也可以直接聲明為static的方式）。

代碼示例

線程安全：

public class Singleton {
    private static final Singleton singleton = new Singleton();
    //限制産生多個對象
    private Singleton(){
    }
    //通過該方法獲得執行個體對象
    public static Singleton getSingleton(){
        return singleton;
    }
    //類中其他方法，盡量是 static
    public static void doSomething(){
    }
}

線程不安全：

public class Singleton {
    private static Singleton singleton = null;
    //限制産生多個對象
    private Singleton(){
    }
    //通過該方法獲得執行個體對象
    public static Singleton getSingleton(){
        if(singleton == null){
            singleton = new Singleton();
        }
        return singleton;
    }
}

針對線程不安全：

在 getSingleton 方法前加 synchronized 關鍵字，也可以在 getSingleton 方法内增加synchronized 來實作。

工廠模式

定義一個用于建立對象的接口，讓子類決定執行個體化哪一個類。工廠方法使一個類的執行個體化延遲到其子類。

jdbc 連接配接資料庫，硬體通路，降低對象的産生和銷毀

結構

簡單工廠模式：一個子產品僅需要一個工廠類，沒有必要把它産生出來，使用靜态的方法

多個工廠類：每個人種（具體的産品類）都對應了一個建立者，每個建立者獨立負責建立對應的産品對象，非常符合單一職責原則

代替單例模式：單例模式的核心要求就是在記憶體中隻有一個對象，通過工廠方法模式也可以隻在記憶體中生産一個對象

延遲初始化： ProductFactory 負責産品類對象的建立工作，并且通過 prMap 變量産生一個緩存，對需要再次被重用的對象保留

Product 為抽象産品類負責定義産品的共性，實作對事物最抽象的定義；

Creator 為抽象建立類，也就是抽象工廠，具體如何建立産品類是由具體的實作工廠 ConcreteCreator 完成的。

public class ConcreteCreator extends Creator {
    public <T extends Product> T createProduct(Class<T> c){
        Product product=null;
        try {
            product =
                    (Product)Class.forName(c.getName()).newInstance();
        } catch (Exception e) {
        //異常處理
        }
        return (T)product;
    }
}

抽象工廠模式

為建立一組相關或互相依賴的對象提供一個接口，而且無須指定它們的具體類。

一個對象族（或是一組沒有任何關系的對象）都有相同的限制。

涉及不同作業系統的時候，都可以考慮使用抽象工廠模式。

public abstract class AbstractCreator {
    //建立 A 産品家族
    public abstract AbstractProductA createProductA();
    //建立 B 産品家族
    public abstract AbstractProductB createProductB();
}

模闆方法模式

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

多個子類有公有的方法，并且邏輯基本相同時。
重要、複雜的算法，可以把核心算法設計為模闆方法，周邊的相關細節功能則由各個子類實作。
重構時，模闆方法模式是一個經常使用的模式，把相同的代碼抽取到父類中，然後通過鈎子函數（見“模闆方法模式的擴充”）限制其行為。

抽象模闆：

AbstractClass

為抽象模闆，它的方法分為兩類：

1、基本方法：也叫做基本操作，是由子類實作的方法，并且在模闆方法被調用。

2、模闆方法：可以有一個或幾個，一般是一個具體方法，也就是一個架構，實作對基本方法的排程，完成固定的邏輯。

注意：為了防止惡意的操作，一般模闆方法都加上

final

關鍵字，不允許被覆寫。

具體模闆：實作父類所定義的一個或多個抽象方法，也就是父類定義的基本方法在子類中得以實作。

package templateMethod;
public class TemplateMethodPattern
{
    public static void main(String[] args)
    {
        AbstractClass tm=new ConcreteClass();
        tm.TemplateMethod();
    }
}

//抽象類
abstract class AbstractClass
{
    public void TemplateMethod() //模闆方法
    {
        SpecificMethod();
        abstractMethod1();
        abstractMethod2();
    }
    public void SpecificMethod() //具體方法
    {
        System.out.println("抽象類中的具體方法被調用...");
    }
    public abstract void abstractMethod1(); //抽象方法1
    public abstract void abstractMethod2(); //抽象方法2
}

//具體子類
class ConcreteClass extends AbstractClass
{
    public void abstractMethod1()
    {
        System.out.println("抽象方法1的實作被調用...");
    }
    public void abstractMethod2()
    {
        System.out.println("抽象方法2的實作被調用...");
    }
}

建造者模式

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

相同的方法，不同的執行順序，産生不同的事件結果時，可以采用建造者模式。
多個部件或零件，都可以裝配到一個對象中，但是産生的運作結果又不相同時，則可以使用該模式。
産品類非常複雜，或者産品類中的調用順序不同産生了不同的效能，這個時候使用建造者模式非常合适。

Product 産品類：通常是實作了模闆方法模式，也就是有模闆方法和基本方法。

Builder 抽象建造者：規範産品的組建，一般是由子類實作。

ConcreteBuilder 具體建造者：實作抽象類定義的所有方法，并且傳回一個組建好的對象。

Director 導演類：負責安排已有子產品的順序，然後告訴 Builder 開始建造

public class ConcreteProduct extends Builder {
     private Product product = new Product();
     //設定産品零件
     public void setPart(){
             /*
              * 産品類内的邏輯處理
              */
     }  
     //組建一個産品
     public Product buildProduct() {
             return product;
     }
}

代理模式

為其他對象提供一種代理以控制對這個對象的通路。

Subject 抽象主題角色：抽象主題類可以是抽象類也可以是接口，是一個最普通的業務類型定義，無特殊要求。

RealSubject 具體主題角色：也叫做被委托角色、被代理角色。它才是冤大頭，是業務邏輯的具體執行者。

Proxy 代理主題角色：也叫做委托類、代理類。它負責對真實角色的應用，把所有抽象主題類定義的方法、限制委托給真實主題角色實作，并且在真實主題角色處理完畢前後做預處理和善後處理工作。

分類

普通代理：在該模式下，調用者隻知代理而不用知道真實的角色是誰，屏蔽了真實角色的變更對高層子產品的影響，真實的主題角色想怎麼修改就怎麼修改，對高層次的子產品沒有任何的影響，隻要你實作了接口所對應的方法，該模式非常适合對擴充性要求較高的場合。

強制代理：強制代理的概念就是要從真實角色查找到代理角色，不允許直接通路真實角色。高層子產品隻要調用 getProxy 就可以通路真實角色的所有方法，它根本就不需要産生一個代理出來，代理的管理已經由真實角色自己完成。

差別：普通代理就是我們要知道代理的存在，也就是類似的 GamePlayerProxy 這個類的存在，然後才能通路；強制代理則是調用者直接調用真實角色，而不用關心代理是否存在，其代理的産生是由真實角色決定的。

動态代理：根據被代理的接口生成所有的方法，也就是說給定一個接口，動态代理會宣稱“我

已經實作該接口下的所有方法了”。兩條獨立發展的線路。動态代理實作代理的職責，業務邏輯 Subject 實作相關的邏輯功能，兩者之間沒有必然的互相耦合的關系。通知 Advice 從另一個切面切入，最終在高層子產品也就是 Client 進行耦合，完成邏輯的封裝任務。

意圖：橫切面程式設計，在不改變我們已有代碼結構的情況下增強或控制對象的行為。
首要條件：被代理的類必須要實作一個接口。

public Object getProxy(@Nullable ClassLoader classLoader) {
    if (logger.isTraceEnabled()) {
        logger.trace("Creating JDK dynamic proxy: " + this.advised.getTargetSource());
    }
    Class<?>[] proxiedInterfaces = AopProxyUtils.completeProxiedInterfaces(this.advised, true);
    findDefinedEqualsAndHashCodeMethods(proxiedInterfaces);
    return Proxy.newProxyInstance(classLoader, proxiedInterfaces, this);
}

原型模式

用原型執行個體指定建立對象的種類，并且通過拷貝這些原型建立新的對象。

資源優化場景：類初始化需要消化非常多的資源，這個資源包括資料、硬體資源等。

性能和安全要求的場景：通過 new 産生一個對象需要非常繁瑣的資料準備或通路權限，則可以使用原型模式。

一個對象多個修改者的場景：一個對象需要提供給其他對象通路，而且各個調用者可能都需要修改其值時，可以、考慮使用原型模式拷貝多個對象供調用者使用。

優點

原型模式實際上就是實作 Cloneable 接口，重寫 clone（）方法。

性能優良：原型模式是在記憶體二進制流的拷貝，要比直接 new 一個對象性能好很多，特别是要在一個循環體内産生大量的對象時，原型模式可以更好地展現其優點。

逃避構造函數的限制：這既是它的優點也是缺點，直接在記憶體中拷貝，構造函數是不會執行的。

public class PrototypeClass implements Cloneable{
    //覆寫父類 Object 方法
    @Override
    public PrototypeClass clone(){
        PrototypeClass prototypeClass = null;
        try {
            prototypeClass = (PrototypeClass)super.clone();
        } catch (CloneNotSupportedException e) {
        //異常處理
        }
        return prototypeClass;
    }
}

中介者模式

用一個中介對象封裝一系列的對象互動，中介者使各對象不需要顯示地互相作用，進而使其耦合松散，而且可以獨立地改變它們之間的互動。

中介者模式适用于多個對象之間緊密耦合的情況，緊密耦合的标準是：在類圖中出現了蜘蛛網狀結構，即每個類都與其他的類有直接的聯系。

Mediator 抽象中介者角色：抽象中介者角色定義統一的接口，用于各同僚角色之間的通信。

Concrete Mediator 具體中介者角色：具體中介者角色通過協調各同僚角色實作協作行為，是以它必須依賴于各個同僚角色。

Colleague 同僚角色：每一個同僚角色都知道中介者角色，而且與其他的同僚角色通信的時候，一定要通過中介者角色協作。每個同僚類的行為分為兩種：一種是同僚本身的行為，比如改變對象本身的狀态，處理自己的行為等，這種行為叫做自發行為（SelfMethod），與其他的同僚類或中介者沒有任何的依賴；第二種是必須依賴中介者才能完成的行為，叫做依賴方法（Dep-Method）。

示例代碼

public abstract class Mediator {
    //定義同僚類
    protected ConcreteColleague1 c1;
    protected ConcreteColleague2 c2;
    //通過 getter/setter 方法把同僚類注入進來
    public ConcreteColleague1 getC1() {
        return c1;
    }
    public void setC1(ConcreteColleague1 c1) {
        this.c1 = c1;
    }
    public ConcreteColleague2 getC2() {
        return c2;
    }
    public void setC2(ConcreteColleague2 c2) {
        this.c2 = c2;
    }
    //中介者模式的業務邏輯
    public abstract void doSomething1();
    public abstract void doSomething2();
}

指令模式

将一個請求封裝成一個對象，進而讓你使用不同的請求把用戶端參數化，對請求排隊或者記錄請求日志，可以提供指令的撤銷和恢複功能。

認為是指令的地方就可以采用指令模式，例如，在 GUI 開發中，一個按鈕的點選是一個指令，可以采用指令模式；模拟 DOS 指令的時候，當然也要采用指令模式；觸發－回報機制的處理等。

Receive 接收者角色：該角色就是幹活的角色，指令傳遞到這裡是應該被執行的，具體到我們上面的例子中就是 Group 的三個實作類（需求組，美工組，代碼組）。

Command 指令角色：需要執行的所有指令都在這裡聲明。

Invoker 調用者角色：接收到指令，并執行指令。在例子中，我（項目經理）就是這個角色。

public class Invoker {
    private Command command;

    // 設值注入
    public void setCommand(Command command) {
        this.command = command;
    }

    // 執行指令
    public void action() {
        this.command.execute();
    }
}

責任鍊模式

使多個對象都有機會處理請求，進而避免了請求的發送者和接受者之間的耦合關系。将這些對象連成一條鍊，并沿着這條鍊傳遞該請求，直到有對象處理它為止。

職責

抽象的處理者實作三個職責：

1、定義一個請求的處理方法 handleMessage，唯一對外開放的方法；

2、定義一個鍊的編排方法 setNext，設定下一個處理者；

3、定義了具體的請求者必須實作的兩個方法：定義自己能夠處理的級别getHandlerLevel 和具體的處理任務 echo。

public abstract class Handler {
    private Handler nextHandler;
    //每個處理者都必須對請求做出處理
    public final Response handleMessage(Request request){
        Response response = null;
        //判斷是否是自己的處理級别
        if(this.getHandlerLevel().equals(request.getRequestLevel())){
            response = this.echo(request);
        }else{ //不屬于自己的處理級别
            //判斷是否有下一個處理者
            if(this.nextHandler != null){
                response =
                        this.nextHandler.handleMessage(request);
            }else{
            //沒有适當的處理者，業務自行處理
            } }
        return response;
    }
    //設定下一個處理者是誰
    public void setNext(Handler _handler){
        this.nextHandler = _handler;
    }
    //每個處理者都有一個處理級别
    protected abstract Level getHandlerLevel();
    //每個處理者都必須實作處理任務
    protected abstract Response echo(Request request);
}

注意事項

鍊中節點數量需要控制，避免出現超長鍊的情況，一般的做法是在 Handler 中設定一個最大節點數量，在 setNext 方法中判斷是否已經是超過其門檻值，超過則不允許該鍊建立，避免無意識地破壞系統性能。

裝飾模式

動态地給一個對象添加一些額外的職責。就增加功能來說，裝飾模式相比生成子類更為靈活。

需要擴充一個類的功能，或給一個類增加附加功能。
需要動态地給一個對象增加功能，這些功能可以再動态地撤銷。
需要為一批的兄弟類進行改裝或加裝功能，當然是首選裝飾模式。

Component 抽象構件： Component 是一個接口或者是抽象類，就是定義我們最核心的對象，也就是最原始的對象。在裝飾模式中，必然有一個最基本、最核心、最原始的接口或抽象類充當Component 抽象構件。

ConcreteComponent 具體構件： ConcreteComponent 是最核心、最原始、最基本的接口或抽象類的實作，你要裝飾的就是它。

Decorator 裝飾角色：一般是一個抽象類，做什麼用呢？實作接口或者抽象方法，它裡面可不一定有抽象的方法呀，在它的屬性裡必然有一個 private 變量指向 Component 抽象構件。

具體裝飾角色： ConcreteDecoratorA 和 ConcreteDecoratorB 是兩個具體的裝飾類，你要把你最核心的、最原始的、最基本的東西裝飾成其他東西，上面的例子就是把一個比較平庸的成績單裝飾成家長認可的成績單。

/**
 * 裝飾角色
 */
@Data
@AllArgsConstructor
@NoArgsConstructor
@Log
class BufferedReader implements Reader{

    private  Reader reader;
    @Override
    public void read() {
        reader.read();
    }

    public void readLine(){
        read();
        log.info("并且僅僅讀取一行");
    }
}

政策模式

定義一組算法，将每個算法都封裝起來，并且使它們之間可以互換。

多個類隻有在算法或行為上稍有不同的場景。
算法需要自由切換的場景。
需要屏蔽算法規則的場景。
具體政策數量超過 4 個，則需要考慮使用混合模式

Context 封裝角色：它也叫做上下文角色，起承上啟下封裝作用，屏蔽高層子產品對政策、算法的直接通路，封裝可能存在的變化。

Strategy 抽象政策角色：政策、算法家族的抽象，通常為接口，定義每個政策或算法必須具有的方法和屬性。

ConcreteStrategy 具體政策角色：實作抽象政策中的操作，該類含有具體的算法。

public enum Calculator {
    //加法運算
    ADD("+"){
        public int exec(int a,int b){
            return a+b;
        }
    },
    //減法運算
    SUB("-"){
        public int exec(int a,int b){
            return a - b;
        }
    };
    String value = "";
    //定義成員值類型
    private Calculator(String _value){
        this.value = _value;
    }
    //獲得枚舉成員的值
    public String getValue(){
        return this.value;
    }
    //聲明一個抽象函數
    public abstract int exec(int a,int b);
}

擴充卡模式

将一個類的接口變換成用戶端所期待的另一種接口，進而使原本因接口不比對而無法在一起工作的兩個類能夠在一起工作。

你有動機修改一個已經投産中的接口時，擴充卡模式可能是最适合你的模式。比如系統擴充了，需要使用一個已有或建立立的類，但這個類又不符合系統的接口，怎麼辦？詳細設計階段不要考慮使用擴充卡模式，使用主要場景為擴充應用中。

類擴充卡

Target 目标角色：該角色定義把其他類轉換為何種接口，也就是我們的期望接口。

Adaptee 源角色：你想把誰轉換成目标角色，這個“誰”就是源角色，它是已經存在的、運作良好的類或對象，經過擴充卡角色的包裝，它會成為一個嶄新、靓麗的角色。

Adapter 擴充卡角色：擴充卡模式的核心角色，其他兩個角色都是已經存在的角色，而擴充卡角色是需要建立立的，它的職責非常簡單：把源角色轉換為目标角色，怎麼轉換？通過繼承或是類關聯的方式。

對象擴充卡

不使用多繼承或繼承的方式，而是使用直接關聯，或者稱為委托的方式。

對象擴充卡和類擴充卡的差別：

類擴充卡是類間繼承，對象擴充卡是對象的合成關系，也可以說是類的關聯關系，這是兩者的根本差別。實際項目中對象擴充卡使用到的場景相對比較多。

public class Adapter extends Target
{
    private Adaptee adaptee;

    public Adapter(Adaptee adaptee)
    {
        this.adaptee=adaptee;
    }

    public void request()
    {
        adaptee.specificRequest();
    }
}

疊代器模式

它提供一種方法通路一個容器對象中各個元素，而又不需暴露該對象的内部細節。

Iterator 抽象疊代器：抽象疊代器負責定義通路和周遊元素的接口，而且基本上是有固定的 3 個方法：first()獲得第一個元素，next()通路下一個元素，isDone()是否已經通路到底部（Java 叫做 hasNext()方法）。

ConcreteIterator 具體疊代器：具體疊代器角色要實作疊代器接口，完成容器元素的周遊。

Aggregate 抽象容器：容器角色負責提供建立具體疊代器角色的接口，必然提供一個類似createIterator()這樣的方法，在 Java 中一般是 iterator()方法。

Concrete Aggregate 具體容器：具體容器實作容器接口定義的方法，建立出容納疊代器的對象。

/**
 * 具體疊代器
 */
public class ConcreteIterator<T> implements Iterator<T> {

    private List<T> list = new ArrayList<>();

    private int cursor = 0;

    public boolean hasNext() {
        return cursor != list.size();
    }

    public T next() {
        T obj = null;
        if (this.hasNext()) {
            obj = this.list.get(cursor++);
        }
        return obj;
    }

}

組合模式

将對象組合成樹形結構以表示 “部分-整體” 的層次結構，使得使用者對單個對象群組合對象的使用具有一緻性。

維護和展示部分-整體關系的場景，如樹形菜單、檔案和檔案夾管理。
從一個整體中能夠獨立出部分子產品或功能的場景。
隻要是樹形結構，就考慮使用組合模式。

Component 抽象構件角色：定義參加組合對象的共有方法和屬性，可以定義一些預設的行為或屬性。

Leaf 葉子構件：葉子對象，其下再也沒有其他的分支，也就是周遊的最小機關。

Composite 樹枝構件：樹枝對象，它的作用是組合樹枝節點和葉子節點形成一個樹形結構。

public class Composite extends Component {
    //構件容器
    private ArrayList<Component> componentArrayList = new
            ArrayList<Component>();
    //增加一個葉子構件或樹枝構件
    public void add(Component component){
        this.componentArrayList.add(component);
    }
    //删除一個葉子構件或樹枝構件
    public void remove(Component component){
        this.componentArrayList.remove(component);
    }
    //獲得分支下的所有葉子構件和樹枝構件
    public ArrayList<Component> getChildren(){
        return this.componentArrayList;
    } 
}

觀察者模式

定義對象間一種一對多的依賴關系，使得每當一個對象改變狀态，則所有依賴于它的對象都會得到通知并被自動更新。

關聯行為場景。需要注意的是，關聯行為是可拆分的，而不是“組合”關系。
事件多級觸發場景。
跨系統的消息交換場景，如消息隊列的處理機制。

Subject 被觀察者：定義被觀察者必須實作的職責，它必須能夠動态地增加、取消觀察者。它一般是抽象類或者是實作類，僅僅完成作為被觀察者必須實作的職責：管理觀察者并通知觀察者。

Observer 觀察者：觀察者接收到消息後，即進行 update（更新方法）操作，對接收到的資訊進行處理。

ConcreteSubject 具體的被觀察者：定義被觀察者自己的業務邏輯，同時定義對哪些事件進行通知。

ConcreteObserver 具體的觀察者：每個觀察在接收到消息後的處理反應是不同，各個觀察者有自己的處理邏輯。

public abstract class Subject {
    //定義一個觀察者數組
    private Vector<Observer> obsVector = new Vector<Observer>();
    //增加一個觀察者
    public void addObserver(Observer o){
        this.obsVector.add(o);
    }
    //删除一個觀察者
    public void delObserver(Observer o){
        this.obsVector.remove(o);
    }
    //通知所有觀察者
    public void notifyObservers(){
        for(Observer o:this.obsVector){
            o.update();
        }
    } 
}

門面模式

要求一個子系統的外部與其内部的通信必須通過一個統一的對象進行。門面模式提供一個高層次的接口，使得子系統更易于使用。

為一個複雜的子產品或子系統提供一個供外界通路的接口
子系統相對獨立——外界對子系統的通路隻要黑箱操作即可
預防低水準人員帶來的風險擴散

Facade 門面角色：用戶端可以調用這個角色的方法。此角色知曉子系統的所有功能和責任。一般情況下，本角色會将所有從用戶端發來的請求委派到相應的子系統去，也就說該角色沒有實際的業務邏輯，隻是一個委托類。

subsystem 子系統角色：可以同時有一個或者多個子系統。每一個子系統都不是一個單獨的類，而是一個類的集合。子系統并不知道門面的存在。對于子系統而言，門面僅僅是另外一個用戶端而已。

代碼模式

public class Client {
    //委托的子系統對象
    private A a= new A();
    private B b= new B();
    private C c= new C();
    //提供外部通路的方法
    public void methodA(){
        this.a.doSomething();
    }
    public void methodB(){
        this.b.doSomething();
    }
    public void methodC(){
        this.c.doSomething();
    }
}

備忘錄模式

在不破壞封裝性的前提下，捕獲一個對象的内部狀态，并在該對象之外儲存這個狀态。這樣以後就可将該對象恢複到原先儲存的狀态。

需要儲存和恢複資料的相關狀态場景。
提供一個可復原（rollback）的操作。
需要監控的副本場景中。
資料庫連接配接的事務管理就是用的備忘錄模式。

Originator 發起人角色：記錄目前時刻的内部狀态，負責定義哪些屬于備份範圍的狀态，負責建立和恢複備忘錄資料。

Memento 備忘錄角色：負責存儲 Originator 發起人對象的内部狀态，在需要的時候提供發起人需要的内部狀态。

Caretaker 備忘錄管理者角色：對備忘錄進行管理、儲存和提供備忘錄。

public class BeanUtils {
    //把 bean 的所有屬性及數值放入到 Hashmap 中
    public static HashMap<String,Object> backupProp(Object bean){
        HashMap<String,Object> result = new
                HashMap<String,Object>();
        try {
            //獲得 Bean 描述
            BeanInfo
                    beanInfo=Introspector.getBeanInfo(bean.getClass());
            //獲得屬性描述
            PropertyDescriptor[]
                    descriptors=beanInfo.getPropertyDescriptors();
            //周遊所有屬性
            for(PropertyDescriptor des:descriptors){
                //屬性名稱
                String fieldName = des.getName();
                //讀取屬性的方法
                Method getter = des.getReadMethod();
                //讀取屬性值
                Object fieldValue=getter.invoke(bean,new
                        Object[]{});
                if(!fieldName.equalsIgnoreCase("class")){
                    result.put(fieldName, fieldValue);
                } } } catch (Exception e) {
                //異常處理
        }
        return result;
    }
    //把 HashMap 的值傳回到 bean 中
    public static void restoreProp(Object bean,HashMap<String,Object>
            propMap){
        try {
            //獲得 Bean 描述
            BeanInfo beanInfo =
                    Introspector.getBeanInfo(bean.getClass());
            //獲得屬性描述
            PropertyDescriptor[] descriptors =
                    beanInfo.getPropertyDescriptors();
            //周遊所有屬性
            for(PropertyDescriptor des:descriptors){
                //屬性名稱
                String fieldName = des.getName();
                //如果有這個屬性
                if(propMap.containsKey(fieldName)){
                    //寫屬性的方法
                    Method setter = des.getWriteMethod();
                    setter.invoke(bean, new
                            Object[]{propMap.get(fieldName)});
                } } } catch (Exception e) {
            //異常處理
            System.out.println("shit");
            e.printStackTrace();
        }
    }
}

通路者模式

封裝一些作用于某種資料結構中的各元素的操作，它可以在不改變資料結構的前提下定義作用于這些元素的新的操作。

一個對象結構包含很多類對象，它們有不同的接口，而你想對這些對象實施一些依賴于其具體類的操作，也就說是用疊代器模式已經不能勝任的情景。
需要對一個對象結構中的對象進行很多不同并且不相關的操作，而你想避免讓這些操作“污染”這些對象的類。

Visitor——抽象通路者：抽象類或者接口，聲明通路者可以通路哪些元素，具體到程式中就是 visit 方法的參數定義哪些對象是可以被通路的。

ConcreteVisitor——具體通路者：它影響通路者通路到一個類後該怎麼幹，要做什麼事情。

Element——抽象元素：接口或者抽象類，聲明接受哪一類通路者通路，程式上是通過 accept 方法中的參數來定義的。

ConcreteElement——具體元素：實作 accept 方法，通常是 visitor.visit(this)，基本上都形成了一種模式了。

ObjectStruture——結構對象：元素産生者，一般容納在多個不同類、不同接口的容器，如 List、Set、Map 等，在項目中，一般很少抽象出這個角色。

public class CompensationVisitor implements Visitor {

    @Override
    public void Visit(Element element) {
        // TODO Auto-generated method stub
        Employee employee = ((Employee) element);

        System.out.println(
                employee.getName() + "'s Compensation is " + (employee.getDegree() * employee.getVacationDays() * 10));
    }

}

狀态模式

當一個對象内在狀态改變時允許其改變行為，這個對象看起來像改變了其類。

行為随狀态改變而改變的場景，這也是狀态模式的根本出發點，例如權限設計，人員的狀态不同即使執行相同的行為結果也會不同，在這種情況下需要考慮使用狀态模式。
條件、分支判斷語句的替代者

State——抽象狀态角色：接口或抽象類，負責對象狀态定義，并且封裝環境角色以實作狀态切換。

ConcreteState——具體狀态角色：每一個具體狀态必須完成兩個職責：本狀态的行為管理以及趨向狀态處理，通俗地說，就是本狀态下要做的事情，以及本狀态如何過渡到其他狀态。

Context——環境角色：定義用戶端需要的接口，并且負責具體狀态的切換。

//抽象狀态角色
public abstract class State {
     //定義一個環境角色，提供子類通路
     protected Context context;
     //設定環境角色
     public void setContext(Context _context){
             this.context = _context;
     }
     //行為1
     public abstract void handle1();
     //行為2
     public abstract void handle2();
}

解釋器模式

給定一門語言，定義它的文法的一種表示，并定義一個解釋器，該解釋器使用該表示來解釋語言中的句子。

重複發生的問題可以使用解釋器模式
一個簡單文法需要解釋的場景

AbstractExpression——抽象解釋器：具體的解釋任務由各個實作類完成，具體的解釋器分别由TerminalExpression 和 Non-terminalExpression 完成。

TerminalExpression——終結符表達式：實作與文法中的元素相關聯的解釋操作，通常一個解釋器模式中隻有一個終結符表達式，但有多個執行個體，對應不同的終結符。具體到我們例子就是 VarExpression類，表達式中的每個終結符都在棧中産生了一個 VarExpression 對象。

NonterminalExpression——非終結符表達式：文法中的每條規則對應于一個非終結表達式，具體到我們的例子就是加減法規則分别對應到 AddExpression 和 SubExpression 兩個類。非終結符表達式根據邏輯的複雜程度而增加，原則上每個文法規則都對應一個非終結符表達式。

Context——環境角色：具體到我們的例子中是采用 HashMap 代替。

/**
 * 終結符表達式
 */
public class TerminalExpression extends AbstractExpression {

    @Override
    public void interpret(Context ctx) {
        // 實作與文法規則中的終結符相關聯的解釋操作

    }

}

/**
 * 非終結符表達式
 */
public class NonterminalExpression extends AbstractExpression {

    @Override
    public void interpret(Context ctx) {
        // 實作與文法規則中的非終結符相關聯的解釋操作

    }

}

享元模式

使用共享對象可有效地支援大量的細粒度的對象。

對象的資訊分為兩個部分：内部狀态（intrinsic）與外部狀态（extrinsic）。

内部狀态：内部狀态是對象可共享出來的資訊，存儲在享元對象内部并且不會随環境改變而改變。

外部狀态：外部狀态是對象得以依賴的一個标記，是随環境改變而改變的、不可以共享的狀态。

系統中存在大量的相似對象。
細粒度的對象都具備較接近的外部狀态，而且内部狀态與環境無關，也就是說對象沒有特定身份。
需要緩沖池的場景。

Flyweight——抽象享元角色：它簡單地說就是一個産品的抽象類，同時定義出對象的外部狀态和内部狀态的接口或實作。

ConcreteFlyweight——具體享元角色：具體的一個産品類，實作抽象角色定義的業務。該角色中需要注意的是内部狀态處理應該與環境無關，不應該出現一個操作改變了内部狀态，同時修改了外部狀态，這是絕對不允許的。

unsharedConcreteFlyweight——不可共享的享元角色：不存在外部狀态或者安全要求（如線程安全）不能夠使用共享技術的對象，該對象一般不會出現在享元工廠中。

FlyweightFactory——享元工廠：職責非常簡單，就是構造一個池容器，同時提供從池中獲得對象的方法。

public class FlyweightFactory {
    //定義一個池容器
    private static HashMap<String,Flyweight> pool= new
            HashMap<String,Flyweight>();
    //享元工廠
    public static Flyweight getFlyweight(String Extrinsic){
        //需要傳回的對象
        Flyweight flyweight = null;
        //在池中沒有該對象
        if(pool.containsKey(Extrinsic)){
            flyweight = pool.get(Extrinsic);
        }else{
            //根據外部狀态建立享元對象
            flyweight = new ConcreteFlyweight1(Extrinsic);
            //放置到池中
            pool.put(Extrinsic, flyweight);
        }
        return flyweight;
    }
}

橋梁模式

将抽象和實作解耦，使得兩者可以獨立地變化。

不希望或不适用使用繼承的場景
接口或抽象類不穩定的場景
重用性要求較高的場景

Abstraction——抽象化角色：它的主要職責是定義出該角色的行為，同時儲存一個對實作化角色的引用，該角色一般是抽象類。

Implementor——實作化角色：它是接口或者抽象類，定義角色必需的行為和屬性。

RefinedAbstraction——修正抽象化角色：它引用實作化角色對抽象化角色進行修正。

ConcreteImplementor——具體實作化角色：它實作接口或抽象類定義的方法和屬性。

public abstract class Abstraction {
    //定義對實作化角色的引用
    private Implementor imp;
    //限制子類必須實作該構造函數
    public Abstraction(Implementor _imp){
        this.imp = _imp;
    }
    //自身的行為和屬性
    public void request(){
        this.imp.doSomething();
    }
    //獲得實作化角色
    public Implementor getImp(){
        return imp;
    }
}