【Java】設計模式

TypantK發表於2019-02-18
Java設計模式

原帖地址：https://www.cnblogs.com/wmbg/p/6943878.html

 

常見設計模式分類

建立型模式

工廠模式

抽象工廠模式

單例模式

建造者模式

結構型模式

介面卡模式

裝飾器模式

橋接模式

代理模式

行為型模式

命令模式

迭代器模式

策略模式

觀察者模式

 

 

六大原則

  • 開閉原則

　　對擴充套件開放，對修改關閉。

  • 里氏代換原則

　　任何基類可以出現的地方，子類一定可以出現。

  • 依賴倒轉原則

　　依賴於抽象而不依賴於具體。

  • 介面隔離原則

　　使用多個隔離的介面，比使用單個介面要好。

  • 迪米特法則，又稱最少知道原則

　　一個實體應當儘量少地與其他實體之間發生相互作用，使得系統功能模組相對獨立。

  • 合成複用原則

　　儘量使用合成/聚合的方式，而不是使用繼承。

 

 

建立型模式

工廠模式

作用

一個抽象的介面，多個抽象介面的實現類，一個工廠，用來例項化抽象的介面。

優點

一個呼叫者想建立一個物件，直接向工廠請求即可，不需要知道具體實現，以提高系統的可維護性、可擴充套件性。

缺點

產品修改時，工廠也要進行修改。

程式碼

這裡有錯誤，如果是抽象類應該是extends，並且方法如果沒有實現應該宣告是抽象的；介面採用implements

 

抽象工廠模式

作用

抽象工廠模式（Abstract Factory Pattern）是圍繞一個超級工廠建立其他工廠。

優點

當一個產品型別（每一類中有多個產品）被設計成一起工作時，有良好的維護性。

缺點

產品類擴充套件困難。

例

 

 

單例模式

作用

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

特點

1、單例類只能有一個例項。

2、單例類必須自己建立自己的唯一例項。

3、單例類必須給所有其他物件提供這一例項。

懶漢式

執行緒不安全

public class Singleton {  

    private static Singleton instance;  

    private Singleton (){}   

    public static Singleton getInstance() {  

     if (instance == null) {  

         instance = new Singleton();  

    }  

    return instance;  

    }  

}  

執行緒安全

public class Singleton {  

    private static Singleton instance;  

    private Singleton (){}  

    public static synchronized Singleton getInstance() {  

    if (instance == null) {  

         instance = new Singleton();  

     }  

     return instance;  

    }  

}

雙檢鎖

public class Singleton {  

    private static Singleton singleton;  

    private Singleton (){}  

    public static Singleton getSingleton() {  

     if (singleton == null) {  

         synchronized (Singleton.class) {  

         if (singleton == null) {  

             singleton = new Singleton();

         }  

          }  

   }  

     return singleton;  

    }  

}  

靜態內部類

public class Singleton {  

    private static class SingletonHolder {  

     private static final Singleton INSTANCE = new Singleton();  

    }  

    private Singleton (){}  

    public static final Singleton getInstance() {  

     return SingletonHolder.INSTANCE;  

    }  

}   

餓漢式

public class Singleton {  

    private static final Singleton instance = new Singleton();  

    private Singleton (){}  

    public static Singleton getInstance() {  

     return instance;  

    }  

}

 

建造者模式

作用

建造者模式（Builder Pattern）使用多個簡單的物件一步一步構建成一個複雜的物件。

應用例項

肯德基裡，漢堡、可樂、薯條、炸雞翅等是不變的，而其組合是經常變化的，生成出所謂的"套餐"。

角色

　　抽象建造者角色：一個抽象介面，以規範產品物件的各個組成成分的建造。

　　具體建造者角色：實現抽象建造者Builder所宣告的介面，給出一步一步地完成建立產品例項的操作。

　　導演者角色：擔任這個角色的類呼叫具體建造者角色以建立產品物件。應當指出的是，導演者角色並沒有產品類的具體知識，真正擁有產品類的具體知識的是具體建造者角色。

　　產品角色：產品便是建造中的複雜物件。一般來說，一個系統中會有多於一個的產品類，而且這些產品類並不一定有共同的介面，而完全可以是不相關聯的。

例子

 

結構型模式

介面卡模式

作用

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

模式中的角色

1．目標介面（Target）：客戶所期待的介面。目標可以是具體的或抽象的類，也可以是介面。

2．需要適配的類（Adaptee）：需要適配的類或適配者類。

3．介面卡（Adapter）：實現了目標介面，通過包裝一個需要適配的物件，把原介面轉換成目標介面。　

通過介面卡把需要適配的類轉成目標類

優點

  1. 介面可以轉成自己希望的另一個介面
  2. 提高了類的複用。

缺點

過多地使用介面卡，會讓系統非常零亂，不易整體進行把握。

例子

 

 

裝飾器模式

作用

對已有的業務邏輯進一步的封裝，使其增加額外的功能。即向一個現有的物件新增新的功能，同時又不改變其結構。

優點

可以提供比繼承更多的靈活性。

缺點

多層裝飾比較複雜。

例子

實物基類

雞肉

鴨肉

裝飾者基類

蒸-裝飾者

烤-裝飾者

 

橋接模式

作用

將抽象部分與實現部分分離，使它們都可以獨立的變化。把兩個角色之間的繼承關係改為了耦合的關係。 

例子

 

代理模式

作用

一個類代理另一個類的功能。

模式中的角色

  1. 抽象角色：宣告真實物件和代理物件的共同介面。 
    2. 代理角色：代理物件角色內部含有對真實物件的引用，繼承了抽象物件。 
    3. 真實角色：代理角色所代表的真實物件，是我們最終要引用的物件。

缺點

由於在客戶端和真實主題之間增加了代理物件，因此有些型別的代理模式可能會造成請求的處理速度變慢。

例子

 

行為型模式

命令模式

作用

將一個命令封裝成一個物件，可以對命令接受者進行不同的命令處理。

組成

命令接受者：執行命令的物件。

命令：操作命令接受者執行命令。

命令物件入口：要求命令物件執行請求，通常會持有命令物件，可以持有很多的命令物件。

例子

 

迭代器模式

作用

這種模式用於順序訪問集合物件的元素，不需要知道集合物件的底層表示。

通過容器獲取迭代器，通過迭代器遍歷元素。

角色

1．迭代器介面

2．迭代器具體實現

3．抽象容器

4．具體容器

例子

迭代器介面

public interface Iterator {

    public Object first();

    public Object previous();

    public Object next();

    public boolean hasNext();

}

具體迭代器

public class MyIterator implements Iterator{

    private List<Object> list;

    private int index = 0;

    public MyIterator(List<Object> list) {

        this.list = list;

    }

    @Override

    public Object previous() {

        if((this.index - 1) < 0){

            return null;

        }else{

            return this.list.get(--index);

        }

    }

    @Override

    public Object next() {

        if((this.index + 1) >= this.list.size()){

            return null;

        }else{

            return this.list.get(++index);

        }

    }

    @Override

    public boolean hasNext() {

        if(this.index < (this.list.size() - 1)){

            return true;

        }

        return false;

    }

    @Override

    public Object first() {

        if(this.list.size() <= 0){

            return null;

        }else{

            return this.list.get(0);

        }

    }

}

容器介面

package com.pichen.dp.behavioralpattern.iterator;

public abstract class Container {

    public abstract Iterator iterator();

    public abstract void put(Object obj);

}

具體容器  

public class MyContainer extends Container{

    private List<Object> list;

    public MyContainer() {

        this.list = new ArrayList<Object>();

    }

    @Override

    public void put(Object obj){

        this.list.add(obj);

    }

    @Override

    public Iterator iterator() {

        return new MyIterator(list);

    }

}

 

策略模式

作用

　　將多個演算法封裝到具有共同介面的獨立的類中，從而使得它們可以相互替換。

組成

　　1．抽象策略角色：通常由一個介面或者抽象類實現。

　　2．具體策略角色: 包裝了相關的演算法和行為。

　　3．環境角色: 持有一個策略類的引用，最終給客戶端呼叫。

實際舉例

　　旅行的出遊方式，選擇騎自行車、坐汽車，每一種旅行方式都是一個策略。

例子

 

觀察者模式

作用

它定義了一種一對多的依賴關係，讓多個觀察者物件同時監聽某一個主題物件。這個主題物件在狀態變化時，會通知所有的觀察者物件，使他們能夠自動更新自己。

優點

1．觀察者模式在被觀察者和觀察者之間建立一個抽象的耦合。

2．觀察者模式支援廣播通訊。被觀察者會向所有的登記過的觀察者發出通知。

缺點

1．如果一個被觀察者物件有很多的直接和間接的觀察者的話，將所有的觀察者都通知到會花費很多時間。

2．如果在觀察者和觀察目標之間有迴圈依賴的話，觀察目標會觸發它們之間進行迴圈呼叫，可能導致系統崩潰。

3．觀察者模式沒有相應的機制讓觀察者知道所觀察的目標物件是怎麼發生變化的，而僅僅只是知道觀察目標發生了變化。

結構圖

  1. Subject：抽象主題（抽象被觀察者），每個主題都可以有任意數量的觀察者，抽象主題提供一個介面，可以增加和刪除觀察者物件。
  2. ConcreteSubject：具體主題（具體被觀察者），把所有觀察者物件儲存在一個集合裡，在具體主題的內部狀態發生改變時，給所有註冊過的觀察者傳送通知。
  3. Observer：抽象觀察者，是觀察者者的抽象類，它定義了一個更新介面，使得在得到主題更改通知時更新自己。
  4. ConcrereObserver：具體觀察者，是實現抽象觀察者定義的更新介面，以便在得到主題更改通知時更新自身的狀態。

例子

 

Easier way to understand.

原帖地址：http://blog.sina.com.cn/s/blog_657572dc0100sh41.html

建立型模式
　　1、FACTORY—追MM少不了請吃飯了，麥當勞的雞翅和肯德基的雞翅都是MM愛吃的東西，雖然口味有所不同，但不管你帶MM去麥當勞或肯德基，只管向服務員說“來四個雞翅”就行了。麥當勞和肯德基就是生產雞翅的Factory
　　工廠模式：客戶類和工廠類分開。消費者任何時候需要某種產品，只需向工廠請求即可。消費者無須修改就可以接納新產品。缺點是當產品修改時，工廠類也要做相應的修改。如：如何建立及如何向客戶端提供。

　 　2、BUILDER—MM最愛聽的就是“我愛你”這句話了，見到不同地方的MM,要能夠用她們的方言跟她說這句話哦，我有一個多種語言翻譯機，上面每種 語言都有一個按鍵，見到MM我只要按對應的鍵，它就能夠用相應的語言說出“我愛你”這句話了，國外的MM也可以輕鬆搞掂，這就是我的“我愛你” builder。（這一定比美軍在伊拉克用的翻譯機好賣）
　　建造模式：將產品的內部表象和產品的生成過程分割開來，從而使一個建造過程生成具有不同的內部表象的產品物件。建造模式使得產品內部表象可以獨立的變化，客戶不必知道產品內部組成的細節。建造模式可以強制實行一種分步驟進行的建造過程。

　　3、FACTORY METHOD—請MM去麥當勞吃漢堡，不同的MM有不同的口味，要每個都記住是一件煩人的事情，我一般採用Factory Method模式，帶著MM到服務員那兒，說“要一個漢堡”，具體要什麼樣的漢堡呢，讓MM直接跟服務員說就行了。
　　工廠方法模式：核心工廠類不再負責所有產品的建立，而是將具體建立的工作交給子類去做，成為一個抽象工廠角色，僅負責給出具體工廠類必須實現的介面，而不接觸哪一個產品類應當被例項化這種細節。
　　4、PROTOTYPE—跟MM用QQ聊天，一定要說些深情的話語了，我搜集了好多肉麻的情話，需要時只要copy出來放到QQ裡面就行了，這就是我的情話prototype了。（100塊錢一份，你要不要）
　 　原始模型模式：通過給出一個原型物件來指明所要建立的物件的型別，然後用複製這個原型物件的方法建立出更多同型別的物件。原始模型模式允許動態的增加或 減少產品類，產品類不需要非得有任何事先確定的等級結構，原始模型模式適用於任何的等級結構。缺點是每一個類都必須配備一個克隆方法。

　　5、SINGLETON—俺有6個漂亮的老婆，她們的老公都是我，我就是我們家裡的老公Sigleton，她們只要說道“老公”，都是指的同一個人，那就是我(剛才做了個夢啦，哪有這麼好的事)
　　單例模式：單例模式確保某一個類只有一個例項，而且自行例項化並向整個系統提供這個例項單例模式。單例模式只應在有真正的“單一例項”的需求時才可使用。

 結構型模式
　　6、ADAPTER—在朋友聚會上碰到了一個美女Sarah，從香港來的，可我不會說粵語，她不會說普通話，只好求助於我的朋友kent了，他作為我和Sarah之間的Adapter，讓我和Sarah可以相互交談了(也不知道他會不會耍我)
　　介面卡（變壓器）模式：把一個類的介面變換成客戶端所期待的另一種介面，從而使原本因介面原因不匹配而無法一起工作的兩個類能夠一起工作。適配類可以根據引數返還一個合適的例項給客戶端。

　　7、BRIDGE—早上碰到MM，要說早上好，晚上碰到MM，要說晚上好；碰到MM穿了件新衣服，要說你的衣服好漂亮哦，碰到MM新做的髮型，要說你的頭髮好漂亮哦。不要問我“早上碰到MM新做了個髮型怎麼說”這種問題，自己用BRIDGE組合一下不就行了
　　橋樑模式：將抽象化與實現化脫耦，使得二者可以獨立的變化，也就是說將他們之間的強關聯變成弱關聯，也就是指在一個軟體系統的抽象化和實現化之間使用組合/聚合關係而不是繼承關係，從而使兩者可以獨立的變化。

　 　8、COMPOSITE—Mary今天過生日。“我過生日，你要送我一件禮物。”“嗯，好吧，去商店，你自己挑。”“這件T恤挺漂亮，買，這條裙子好 看，買，這個包也不錯，買。”“喂，買了三件了呀，我只答應送一件禮物的哦。”“什麼呀，T恤加裙子加包包，正好配成一套呀，小姐，麻煩你包起來。” “……”，MM都會用Composite模式了，你會了沒有？
    合成模式：合成模式將物件組織到樹結構中，可以用來描述整體與部分的關係。合成模式就是一個處理物件的樹結構的模式。合成模式把部分與整體的關係用樹結構表示出來。合成模式使得客戶端把一個個單獨的成分物件和由他們複合而成的合成物件同等看待。

　 　9、DECORATOR—Mary過完輪到Sarly過生日，還是不要叫她自己挑了，不然這個月伙食費肯定玩完，拿出我去年在華山頂上照的照片，在背面 寫上“最好的的禮物，就是愛你的Fita”，再到街上禮品店買了個像框（賣禮品的MM也很漂亮哦），再找隔壁搞美術設計的Mike設計了一個漂亮的盒子裝 起來……，我們都是Decorator，最終都在修飾我這個人呀，怎麼樣，看懂了嗎？
　　裝飾模式：裝飾模式以對客戶端透明的方式擴充套件物件的功能，是繼承關係的一個替代方案，提供比繼承更多的靈活性。動態給一個物件增加功能，這些功能可以再動態的撤消。增加由一些基本功能的排列組合而產生的非常大量的功能。

　 　10、FACADE—我有一個專業的Nikon相機，我就喜歡自己手動調光圈、快門，這樣照出來的照片才專業，但MM可不懂這些，教了半天也不會。幸好 相機有Facade設計模式，把相機調整到自動擔灰宰寄勘臧純烀啪託辛耍磺杏上嗷遠髡庋鵐M也可以用這個相機給我拍張照片了。
　　門面模式：外部與一個子系統的通訊必須通過一個統一的門面物件進行。門面模式提供一個高層次的介面，使得子系統更易於使用。每一個子系統只有一個門面類，而且此門面類只有一個例項，也就是說它是一個單例模式。但整個系統可以有多個門面類。

　 　11、FLYWEIGHT—每天跟MM發簡訊，手指都累死了，最近買了個新手機，可以把一些常用的句子存在手機裡，要用的時候，直接拿出來，在前面加上 MM的名字就可以傳送了，再不用一個字一個字敲了。共享的句子就是Flyweight，MM的名字就是提取出來的外部特徵，根據上下文情況使用。
　 　享元模式：FLYWEIGHT在拳擊比賽中指最輕量級。享元模式以共享的方式高效的支援大量的細粒度物件。享元模式能做到共享的關鍵是區分內蘊狀態和外 蘊狀態。內蘊狀態儲存在享元內部，不會隨環境的改變而有所不同。外蘊狀態是隨環境的改變而改變的。外蘊狀態不能影響內蘊狀態，它們是相互獨立的。將可以共 享的狀態和不可以共享的狀態從常規類中區分開來，將不可以共享的狀態從類裡剔除出去。客戶端不可以直接建立被共享的物件，而應當使用一個工廠物件負責建立 被共享的物件。享元模式大幅度的降低記憶體中物件的數量。

　　12、PROXY—跟MM在網上聊天，一開頭總是“hi,你好”,“你從哪兒來呀？”“你多大了？”“身高多少呀？”這些話，真煩人，寫個程式做為我的Proxy吧，凡是接收到這些話都設定好了自動的回答，接收到其他的話時再通知我回答，怎麼樣，酷吧。
　 　代理模式：代理模式給某一個物件提供一個代理物件，並由代理物件控制對源物件的引用。代理就是一個人或一個機構代表另一個人或者一個機構採取行動。某些 情況下，客戶不想或者不能夠直接引用一個物件，代理物件可以在客戶和目標物件直接起到中介的作用。客戶端分辨不出代理主題物件與真實主題物件。代理模式可 以並不知道真正的被代理物件，而僅僅持有一個被代理物件的介面，這時候代理物件不能夠建立被代理物件，被代理物件必須有系統的其他角色代為建立並傳入。

行為模式
　　13、CHAIN OF RESPONSIBLEITY—晚上去上英語課，為了好開溜坐到了最後一排，哇，前面坐了好幾個漂亮的MM哎，找張紙條，寫上“Hi,可以做我的女朋友 嗎？如果不願意請向前傳”，紙條就一個接一個的傳上去了，糟糕，傳到第一排的MM把紙條傳給老師了，聽說是個老處女呀，快跑!
　　責任鏈模式：在責任鏈模式中，很多物件由每一個物件對其下家的引用而接起來形成一條鏈。請求在這個鏈上傳遞，直到鏈上的某一個物件決定處理此請求。客戶並不知道鏈上的哪一個物件最終處理這個請求，系統可以在不影響客戶端的 情況下動態的重新組織鏈和分配責任。處理者有兩個選擇：承擔責任或者把責任推給下家。一個請求可以最終不被任何接收端物件所接受。

　 　14、COMMAND—俺有一個MM家裡管得特別嚴，沒法見面，只好藉助於她弟弟在我們倆之間傳送資訊，她對我有什麼指示，就寫一張紙條讓她弟弟帶給 我。這不，她弟弟又傳送過來一個COMMAND，為了感謝他，我請他吃了碗雜醬麵，哪知道他說：“我同時給我姐姐三個男朋友送COMMAND，就數你最小 氣，才請我吃麵。”，
　　命令模式：命令模式把一個請求或者操作封裝到一個物件中。命令模式把發出命令的責任和執行命令的責任分割 開，委派給不同的物件。命令模式允許請求的一方和傳送的一方獨立開來，使得請求的一方不必知道接收請求的一方的介面，更不必知道請求是怎麼被接收，以及操 作是否執行，何時被執行以及是怎麼被執行的。系統支援命令的撤消。

　　15、INTERPRETER—俺有一個《泡MM真經》，上面有各種泡MM的攻略，比如說去吃西餐的步驟、去看電影的方法等等，跟MM約會時，只要做一個Interpreter，照著上面的指令碼執行就可以了。
　 　直譯器模式：給定一個語言後，直譯器模式可以定義出其文法的一種表示，並同時提供一個直譯器。客戶端可以使用這個直譯器來解釋這個語言中的句子。直譯器 模式將描述怎樣在有了一個簡單的文法後，使用模式設計解釋這些語句。在直譯器模式裡面提到的語言是指任何直譯器物件能夠解釋的任何組合。在直譯器模式中需 要定義一個代表文法的命令類的等級結構，也就是一系列的組合規則。每一個命令物件都有一個解釋方法，代表對命令物件的解釋。命令物件的等級結構中的物件的 任何排列組合都是一個語言。

　　16、ITERATOR—我愛上了Mary，不顧一切的向她求婚。
　　Mary：“想要我跟你結婚，得答應我的條件”
　　我：“什麼條件我都答應，你說吧”
　　Mary：“我看上了那個一克拉的鑽石”
　　我：“我買，我買，還有嗎？”
　　Mary：“我看上了湖邊的那棟別墅”
　　我：“我買，我買，還有嗎？”
　　Mary：“我看上那輛法拉利跑車”
　　我腦袋嗡的一聲，坐在椅子上，一咬牙：“我買，我買，還有嗎？”
　　……
　 　迭代子模式：迭代子模式可以順序訪問一個聚集中的元素而不必暴露聚集的內部表象。多個物件聚在一起形成的總體稱之為聚集，聚集物件是能夠包容一組物件的 容器物件。迭代子模式將迭代邏輯封裝到一個獨立的子物件中，從而與聚集本身隔開。迭代子模式簡化了聚集的介面。每一個聚集物件都可以有一個或一個以上的迭 代子物件，每一個迭代子的迭代狀態可以是彼此獨立的。迭代演算法可以獨立於聚集角色變化。

　　17、MEDIATOR—四個MM打麻將，相互之間誰應該給誰多少錢算不清楚了，幸虧當時我在旁邊，按照各自的籌碼數算錢，賺了錢的從我這裡拿，賠了錢的也付給我，一切就OK啦，俺得到了四個MM的電話。
　 　調停者模式：調停者模式包裝了一系列物件相互作用的方式，使得這些物件不必相互明顯作用。從而使他們可以鬆散偶合。當某些物件之間的作用發生改變時，不 會立即影響其他的一些物件之間的作用。保證這些作用可以彼此獨立的變化。調停者模式將多對多的相互作用轉化為一對多的相互作用。調停者模式將物件的行為和 協作抽象化，把物件在小尺度的行為上與其他物件的相互作用分開處理。

　　18、MEMENTO—同時跟幾個MM聊天時，一定要記清楚剛才跟MM說了些什麼話，不然MM發現了會不高興的哦，幸虧我有個備忘錄，剛才與哪個MM說了什麼話我都拷貝一份放到備忘錄裡面儲存，這樣可以隨時察看以前的記錄啦。
　　備忘錄模式：備忘錄物件是一個用來儲存另外一個物件內部狀態的快照的物件。備忘錄模式的用意是在不破壞封裝的條件下，將一個物件的狀態捉住，並外部化，儲存起來，從而可以在將來合適的時候把這個物件還原到儲存起來的狀態。

　　19、OBSERVER—想知道我們們公司最新MM情報嗎？加入公司的MM情報郵件組就行了，tom負責蒐集情報，他發現的新情報不用一個一個通知我們，直接釋出給郵件組，我們作為訂閱者（觀察者）就可以及時收到情報啦
　　觀察者模式：觀察者模式定義了一種一隊多的依賴關係，讓多個觀察者物件同時監聽某一個主題物件。這個主題物件在狀態上發生變化時，會通知所有觀察者物件，使他們能夠自動更新自己。

    20、 STATE—跟MM交往時，一定要注意她的狀態哦，在不同的狀態時她的行為會有不同，比如你約她今天晚上去看電影，對你沒興趣的MM就會說“有事情啦”， 對你不討厭但還沒喜歡上的MM就會說“好啊，不過可以帶上我同事麼？”，已經喜歡上你的MM就會說“幾點鐘？看完電影再去泡吧怎麼樣？”，當然你看電影過 程中表現良好的話，也可以把MM的狀態從不討厭不喜歡變成喜歡哦。
　　狀態模式：狀態模式允許一個物件在其內部狀態改變的時候改變行 為。這個物件看上去象是改變了它的類一樣。狀態模式把所研究的物件的行為包裝在不同的狀態物件裡，每一個狀態物件都屬於一個抽象狀態類的一個子類。狀態模 式的意圖是讓一個物件在其內部狀態改變的時候，其行為也隨之改變。狀態模式需要對每一個系統可能取得的狀態創立一個狀態類的子類。當系統的狀態變化時，系 統便改變所選的子類。

　　21、STRATEGY—跟不同型別的MM約會，要用不同的策略，有的請電影比較好，有的則去吃小吃效果不錯，有的去海邊浪漫最合適，單目的都是為了得到MM的芳心，我的追MM錦囊中有好多Strategy哦。
　 　策略模式：策略模式針對一組演算法，將每一個演算法封裝到具有共同介面的獨立的類中，從而使得它們可以相互替換。策略模式使得演算法可以在不影響到客戶端的情 況下發生變化。策略模式把行為和環境分開。環境類負責維持和查詢行為類，各種演算法在具體的策略類中提供。由於演算法和環境獨立開來，演算法的增減，修改都不會 影響到環境和客戶端。

　　22、TEMPLATE METHOD——看過《如何說服女生上床》這部經典文章嗎？女生從認識到上床的不變的步驟分為巧遇、打破僵局、展開追求、接吻、前戲、動手、愛撫、進去八 大步驟(Template method)，但每個步驟針對不同的情況，都有不一樣的做法，這就要看你隨機應變啦(具體實現)；
　　 模板方法模式：模板方法模式準備一個抽象類，將部分邏輯以具體方法以及具體構造子的形式實現，然後宣告一些抽象方法來迫使子類實現剩餘的邏輯。不同的子類 可以以不同的方式實現這些抽象方法，從而對剩餘的邏輯有不同的實現。先制定一個頂級邏輯框架，而將邏輯的細節留給具體的子類去實現。

　 　23、VISITOR—情人節到了，要給每個MM送一束鮮花和一張卡片，可是每個MM送的花都要針對她個人的特點，每張卡片也要根據個人的特點來挑，我 一個人哪搞得清楚，還是找花店老闆和禮品店老闆做一下Visitor，讓花店老闆根據MM的特點選一束花，讓禮品店老闆也根據每個人特點選一張卡，這樣就 輕鬆多了；
　　訪問者模式：訪問者模式的目的是封裝一些施加於某種資料結構元素之上的操作。一旦這些操作需要修改的話，接受這個操作 的資料結構可以保持不變。訪問者模式適用於資料結構相對未定的系統，它把資料結構和作用於結構上的操作之間的耦合解脫開，使得操作集合可以相對自由的演 化。訪問者模式使得增加新的操作變的很容易，就是增加一個新的訪問者類。訪問者模式將有關的行為集中到一個訪問者物件中，而不是分散到一個個的節點類中。
    當使用訪問者模式時，要將盡可能多的物件瀏覽邏輯放在訪問者類中，而不是放到它的子類中。訪問者模式可以跨過幾個類的等級結構訪問屬於不同的等級結構的成 員類。
 

相關文章