設計模式，及在Java中的應用

設計模式- http://blog.csdn.net/SEU_Calvin/article/category/6226468

【設計模式&重構&UML建模】- http://blog.csdn.net/a910626/article/category/6153362

java設計模式- http://blog.csdn.net/DLUTBruceZhang/article/category/1506009

設計模式- http://blog.csdn.net/Innost/article/list/3

關於23種設計模式的有趣見解- http://blog.csdn.net/it_man/article/details/1362621

設計模式- http://blog.csdn.net/x359981514/article/category/1278882
Design Pattern - http://blog.csdn.net/u012515223/article/category/2281679

設計模式- http://blog.csdn.net/bboyfeiyu/article/category/1119220

設計模式- http://blog.csdn.net/itachi85/article/category/6062957

---------------------------------------------------------------------------------

> 設計模式都解決了什麼問題？如工廠模式
介面與實現分開，解耦;類的依賴與類的解耦；發現變化並且封裝變化，針對介面程式設計而不是實現程式設計。

> 工廠模式解決了什麼問題？設計模式解決了什麼問題？

設計模式（Design Patterns）——可複用物件導向軟體的基礎
設計模式（Design pattern）是一套被反覆使用、多數人知曉的、經過分類編目的、程式碼設計經驗的總結。使用設計模式是為了可重用程式碼、讓程式碼更容易被他人理解、保證代碼可靠性。毫無疑問，設計模式於己於他人於系統都是多贏的，設計模式使程式碼編制真正工程化，設計模式是軟體工程的基石，如同大廈的一塊塊磚石一樣。專案中合理的運用設計模式可以完美的解決很多問題，每種模式在現在中都有相應的原理來與之對應，每一個模式描述了一個在我們周圍不斷重複發生的問題，以及該問題的核心解決方案，這也是它能被廣泛應用的原因。本章系Java之美[從菜鳥到高手演變]系列之設計模式，我們會以理論與實踐相結合的方式來進行本章的學習，希望廣大程式愛好者，學好設計模式，做一個優秀的軟體工程師！

> 設計模式的應用：《Android原始碼設計模式解析與實戰》讀書筆記--http://blog.csdn.net/column/details/mode.html?&page=2

Java設計模式（十三）別人再問你設計模式，叫他看這篇文章: http://www.jasongj.com/design_pattern/summary/

企業級專案實戰(帶原始碼)地址：http://zz563143188.iteye.com/blog/1825168

23種模式java實現原始碼收集五年的開發資料下載地址： http://pan.baidu.com/share/link?shareid=3739316113&uk=4076915866#dir/path=%2Fstudy

在著名的《設計模式》一書中，其實在反覆強調一點:發現變化並且封裝變化，針對介面程式設計而不是實現程式設計。很多人看書是隻關注具體的模式，而忽略了模式的本質目的。

-- 23種設計模式- http://my.oschina.net/tiancai/blog/224624?fromerr=ja7O9mld

Java之美[從菜鳥到高手演變]之設計模式(zz)- https://www.cnblogs.com/soul-stone/p/6791316.html

一、設計模式的分類

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

1·建立型別：建立型別的模式都是用於建立類的例項。但是和通過new來建立例項不同，這些模式提供了更加靈活的方式，是程式能夠根據特定的情況建立特定的類。
2·結構型別：結構型別的模式幫助開發人員將簡單物件組合在一起以後的更加複雜的結構。
3·行為型別：行為型別的模式幫助開發人員控制類之間的通訊。

-建立型模式，共五種：工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式。

-結構型模式，共七種：介面卡模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。

-行為型模式，共十一種：策略模式、模板方法模式、觀察者模式、迭代子模式、責任鏈模式、命令模式、備忘錄模式、狀態模式、訪問者模式、中介者模式、直譯器模式。

其實還有兩類：併發型模式和執行緒池模式。用一個圖片來整體描述一下：

二、設計模式的六大原則

1、開閉原則（Open Close Principle）

開閉原則就是說對擴充套件開放，對修改關閉。在程式需要進行擴充的時候，不能去修改原有的程式碼，實現一個熱插拔的效果。所以一句話概括就是：為了使程式的擴充套件性好，易於維護和升級。想要達到這樣的效果，我們需要使用介面和抽象類，後面的具體設計中我們會提到這點。

2、里氏代換原則（Liskov Substitution Principle）

裡氏代換原則(Liskov Substitution Principle LSP)物件導向設計的基本原則之一。里氏代換原則中說，任何基類可以出現的地方，子類一定可以出現。 LSP是繼承複用的基石，只有當衍生類可以替換掉基類，軟體單位的功能不受到影響時，基類才能真正被複用，而衍生類也能夠在基類的基礎上增加新的行為。裡氏代換原則是對“開-閉”原則的補充。實現“開-閉”原則的關鍵步驟就是抽象化。而基類與子類的繼承關係就是抽象化的具體實現，所以里氏代換原則是對實現抽象化的具體步驟的規範。—— From Baidu 百科

3、依賴倒轉原則（Dependence Inversion Principle）

這個是開閉原則的基礎，具體內容：針對介面程式設計，依賴於抽象而不依賴於具體。

4、介面隔離原則（Interface Segregation Principle）

這個原則的意思是：使用多個隔離的介面，比使用單個介面要好。還是一個降低類之間的耦合度的意思，從這兒我們看出，其實設計模式就是一個軟體的設計思想，從大型軟體架構出發，為了升級和維護方便。所以上文中多次出現：降低依賴，降低耦合。

5、迪米特法則（最少知道原則）（Demeter Principle）

為什麼叫最少知道原則，就是說：一個實體應當儘量少的與其他實體之間發生相互作用，使得系統功能模組相對獨立。

6、合成複用原則（Composite Reuse Principle）

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

三、Java的23中設計模式

從這一塊開始，我們詳細介紹Java中23種設計模式的概念，應用場景等情況，並結合他們的特點及設計模式的原則進行分析。

1、工廠方法模式（Factory Method）

> 工廠模式：客戶類和工廠類分開。消費者任何時候需要某種產品，只需向工廠請求即可。消費者無須修改就可以接納新產品。缺點是當產品修改時，工廠類也要做相應的修改。如：如何建立及如何向客戶端提供。

工廠方法模式分為三種：

11、普通工廠模式，就是建立一個工廠類，對實現了同一介面的一些類進行例項的建立。首先看下關係圖：

舉例如下：（我們舉一個傳送郵件和簡訊的例子）

首先，建立二者的共同介面：

[java] view plain copy

public interface Sender {
public void Send();
}

其次，建立實現類：

[java] view plain copy

public class MailSender implements Sender {
@Override
public void Send() {
System.out.println("this is mailsender!");
}
}

[java] view plain copy

public class SmsSender implements Sender {
@Override
public void Send() {
System.out.println("this is sms sender!");
}
}

最後，建工廠類：

[java] view plain copy

public class SendFactory {
public Sender produce(String type) {
if ("mail".equals(type)) {
return new MailSender();
} else if ("sms".equals(type)) {
return new SmsSender();
} else {
System.out.println("請輸入正確的型別!");
return null;
}
}
}

我們來測試下：

public class FactoryTest {
public static void main(String[] args) {
SendFactory factory = new SendFactory();
Sender sender = factory.produce("sms");
sender.Send();
}
}

輸出：this is sms sender!

22、多個工廠方法模式，是對普通工廠方法模式的改進，在普通工廠方法模式中，如果傳遞的字串出錯，則不能正確建立物件，而多個工廠方法模式是提供多個工廠方法，分別建立物件。關係圖：

將上面的程式碼做下修改，改動下SendFactory類就行，如下：

[java] view plain copy

public class SendFactory {

public Sender produceMail(){

return new MailSender();
}
public Sender produceSms(){
return new SmsSender();
}
}

測試類如下：

[java] view plain copy

public class FactoryTest {
public static void main(String[] args) {
SendFactory factory = new SendFactory();
Sender sender = factory.produceMail();
sender.Send();
}
}

輸出：this is mailsender!

33、靜態工廠方法模式，將上面的多個工廠方法模式裡的方法置為靜態的，不需要建立例項，直接呼叫即可。

[java] view plain copy

public class SendFactory {
public static Sender produceMail(){
return new MailSender();
}
public static Sender produceSms(){
return new SmsSender();
}
}

[java] view plain copy

public class FactoryTest {
public static void main(String[] args) {
Sender sender = SendFactory.produceMail();
sender.Send();
}
}

輸出：this is mailsender!

總體來說，工廠模式適合：凡是出現了大量的產品需要建立，並且具有共同的介面時，可以通過工廠方法模式進行建立。在以上的三種模式中，第一種如果傳入的字串有誤，不能正確建立物件，第三種相對於第二種，不需要例項化工廠類，所以，大多數情況下，我們會選用第三種——靜態工廠方法模式。

2、抽象工廠模式（Abstract Factory）

> 工廠方法模式：核心工廠類不再負責所有產品的建立，而是將具體建立的工作交給子類去做，成為一個抽象工廠角色，僅負責給出具體工廠類必須實現的介面，而不接觸哪一個產品類應當被例項化這種細節。

工廠方法模式有一個問題就是，類的建立依賴工廠類，也就是說，如果想要擴充程式，必須對工廠類進行修改，這違背了閉包原則，所以，從設計角度考慮，有一定的問題，如何解決？就用到抽象工廠模式，建立多個工廠類，這樣一旦需要增加新的功能，直接增加新的工廠類就可以了，不需要修改之前的程式碼。因為抽象工廠不太好理解，我們先看看圖，然後就和程式碼，就比較容易理解。

請看例子：

[java] view plain copy

public interface Sender {
public void Send();
}

兩個實現類：

[java] view plain copy

public class MailSender implements Sender {
@Override
public void Send() {
System.out.println("this is mailsender!");
}
}

[java] view plain copy

public class SmsSender implements Sender {
@Override
public void Send() {
System.out.println("this is sms sender!");
}
}
public interface Provider {
public Sender produce();
}

兩個工廠類：

[java] view plain copy

public class SendMailFactory implements Provider {
@Override
public Sender produce(){
return new MailSender();
}
}

[java] view plain copy

public class SendSmsFactory implements Provider{
@Override
public Sender produce() {
return new SmsSender();
}
}

測試類：

[java] view plain copy

public class Test {
public static void main(String[] args) {
Provider provider = new SendMailFactory();
Sender sender = provider.produce();
sender.Send();
}
}

其實這個模式的好處就是，如果你現在想增加一個功能：發及時資訊，則只需做一個實現類，實現Sender介面，同時做一個工廠類，實現Provider介面，就OK了，無需去改動現成的程式碼。這樣做，擴充性較好！

3、單例模式（Singleton）

> 單例模式：單例模式確保某一個類只有一個例項，而且自行例項化並向整個系統提供這個例項單例模式。單例模式只應在有真正的“單一例項”的需求時才可使用。懶漢式和餓漢式。

單例物件（Singleton）是一種常用的設計模式。在Java應用中，單例物件能保證在一個JVM中，該物件只有一個例項存在。這樣的模式有幾個好處：

1、某些類建立比較頻繁，對於一些大型的物件，這是一筆很大的系統開銷。

2、省去了new操作符，降低了系統記憶體的使用頻率，減輕GC壓力。

3、有些類如交易所的核心交易引擎，控制著交易流程，如果該類可以建立多個的話，系統完全亂了。（比如一個軍隊出現了多個司令員同時指揮，肯定會亂成一團），所以只有使用單例模式，才能保證核心交易伺服器獨立控制整個流程。

首先我們寫一個簡單的單例類：

[java] view plain copy

public class Singleton {
/* 持有私有靜態例項，防止被引用，此處賦值為null，目的是實現延遲載入 */
private static Singleton instance = null;
/* 私有構造方法，防止被例項化 */
private Singleton() {
}
/* 靜態工程方法，建立例項 */
public static Singleton getInstance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}
/* 如果該物件被用於序列化，可以保證物件在序列化前後保持一致 */
public Object readResolve() {
return instance;
}
}

class Singleton{
private volatile static Singleton instance = null;
private Singleton() { }
public static Singleton getInstance() {
if(instance==null) {
synchronized (Singleton.class) {
if(instance==null)
instance = new Singleton();
}
}
return instance;
}
}
這個類可以滿足基本要求，但是，像這樣毫無執行緒安全保護的類，如果我們把它放入多執行緒的環境下，肯定就會出現問題了，如何解決？我們首先會想到對getInstance方法加synchronized關鍵字，如下：

[java] view plain copy

public static synchronized Singleton getInstance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}

但是，synchronized關鍵字鎖住的是這個物件，這樣的用法，在效能上會有所下降，因為每次呼叫getInstance()，都要對物件上鎖，事實上，只有在第一次建立物件的時候需要加鎖，之後就不需要了，所以，這個地方需要改進。我們改成下面這個：

[java] view plain copy

public static Singleton getInstance() {
if (instance == null) {
synchronized (instance) {
if (instance == null) {
instance = new Singleton();
}
}
}
return instance;
}

似乎解決了之前提到的問題，將synchronized關鍵字加在了內部，也就是說當呼叫的時候是不需要加鎖的，只有在instance為null，並建立物件的時候才需要加鎖，效能有一定的提升。但是，這樣的情況，還是有可能有問題的，看下面的情況：在Java指令中建立物件和賦值操作是分開進行的，也就是說instance = new Singleton();語句是分兩步執行的。但是JVM並不保證這兩個操作的先後順序，也就是說有可能JVM會為新的Singleton例項分配空間，然後直接賦值給instance成員，然後再去初始化這個Singleton例項。這樣就可能出錯了，我們以A、B兩個執行緒為例：

a> A、B執行緒同時進入了第一個if判斷；

b> A首先進入synchronized塊，由於instance為null，所以它執行instance = new Singleton();

c> 由於JVM內部的優化機制，JVM先畫出了一些分配給Singleton例項的空白記憶體，並賦值給instance成員（注意此時JVM沒有開始初始化這個例項），然後A離開了synchronized塊。

d> B進入synchronized塊，由於instance此時不是null，因此它馬上離開了synchronized塊並將結果返回給呼叫該方法的程式。

e> 此時B執行緒打算使用Singleton例項，卻發現它沒有被初始化，於是錯誤發生了。

所以程式還是有可能發生錯誤，其實程式在執行過程是很複雜的，從這點我們就可以看出，尤其是在寫多執行緒環境下的程式更有難度，有挑戰性。我們對該程式做進一步優化：

[java] view plain copy

private static class SingletonFactory{
private static Singleton instance = new Singleton();
}
public static Singleton getInstance(){
return SingletonFactory.instance;
}

實際情況是，單例模式使用內部類來維護單例的實現，JVM內部的機制能夠保證當一個類被載入的時候，這個類的載入過程是執行緒互斥的。這樣當我們第一次呼叫 getInstance的時候，JVM能夠幫我們保證instance只被建立一次，並且會保證把賦值給instance的記憶體初始化完畢，這樣我們就不用擔心上面的問題。同時該方法也只會在第一次呼叫的時候使用互斥機制，這樣就解決了低效能問題。這樣我們暫時總結一個完美的單例模式：

[java] view plain copy

public class Singleton {
/* 私有構造方法，防止被例項化 */
private Singleton() {
}
/* 此處使用一個內部類來維護單例 */
private static class SingletonFactory {
private static Singleton instance = new Singleton();
}
/* 獲取例項 */
public static Singleton getInstance() {
return SingletonFactory.instance;
}
/* 如果該物件被用於序列化，可以保證物件在序列化前後保持一致 */
public Object readResolve() {
return getInstance();
}
}

其實說它完美，也不一定，如果在建構函式中丟擲異常，例項將永遠得不到建立，也會出錯。所以說，十分完美的東西是沒有的，我們只能根據實際情況，選擇最適合自己應用場景的實現方法。也有人這樣實現：因為我們只需要在建立類的時候進行同步，所以只要將建立和getInstance()分開，單獨為建立加 synchronized關鍵字，也是可以的：

[java] view plain copy

public class SingletonTest {
private static SingletonTest instance = null;
private SingletonTest() {
}
private static synchronized void syncInit() {
if (instance == null) {
instance = new SingletonTest();
}
}
public static SingletonTest getInstance() {
if (instance == null) {
syncInit();
}
return instance;
}
}

考慮效能的話，整個程式只需建立一次例項，所以效能也不會有什麼影響。

補充：採用"影子例項"的辦法為單例物件的屬性同步更新

[java] view plain copy

public class SingletonTest {
private static SingletonTest instance = null;
private Vector properties = null;
public Vector getProperties() {
return properties;
}
private SingletonTest() {
}
private static synchronized void syncInit() {
if (instance == null) {
instance = new SingletonTest();
}
}
public static SingletonTest getInstance() {
if (instance == null) {
syncInit();
}
return instance;
}
public void updateProperties() {
SingletonTest shadow = new SingletonTest();
properties = shadow.getProperties();
}
}

通過單例模式的學習告訴我們：

1、單例模式理解起來簡單，但是具體實現起來還是有一定的難度。

2、synchronized關鍵字鎖定的是物件，在用的時候，一定要在恰當的地方使用（注意需要使用鎖的物件和過程，可能有的時候並不是整個物件及整個過程都需要鎖）。

到這兒，單例模式基本已經講完了，結尾處，筆者突然想到另一個問題，就是採用類的靜態方法，實現單例模式的效果，也是可行的，此處二者有什麼不同？

首先，靜態類不能實現介面。（從類的角度說是可以的，但是那樣就破壞了靜態了。因為介面中不允許有static修飾的方法，所以即使實現了也是非靜態的）

其次，單例可以被延遲初始化，靜態類一般在第一次載入是初始化。之所以延遲載入，是因為有些類比較龐大，所以延遲載入有助於提升效能。

再次，單例類可以被繼承，他的方法可以被覆寫。但是靜態類內部方法都是static，無法被覆寫。

最後一點，單例類比較靈活，畢竟從實現上只是一個普通的Java類，只要滿足單例的基本需求，你可以在裡面隨心所欲的實現一些其它功能，但是靜態類不行。從上面這些概括中，基本可以看出二者的區別，但是，從另一方面講，我們上面最後實現的那個單例模式，內部就是用一個靜態類來實現的，所以，二者有很大的關聯，只是我們考慮問題的層面不同罷了。兩種思想的結合，才能造就出完美的解決方案，就像HashMap採用陣列+連結串列來實現一樣，其實生活中很多事情都是這樣，單用不同的方法來處理問題，總是有優點也有缺點，最完美的方法是，結合各個方法的優點，才能最好的解決問題！

4、建造者模式（Builder）

> 將產品的內部表象和產品的生成過程分割開來，從而使一個建造過程生成具有不同的內部表象的產品物件。建造模式使得產品內部表象可以獨立的變化，客戶不必知道產品內部組成的細節。建造模式可以強制實行一種分步驟進行的建造過程。

工廠類模式提供的是建立單個類的模式，而建造者模式則是將各種產品集中起來進行管理，用來建立複合物件，所謂複合物件就是指某個類具有不同的屬性，其實建造者模式就是前面抽象工廠模式和最後的Test結合起來得到的。我們看一下程式碼：

還和前面一樣，一個Sender介面，兩個實現類MailSender和SmsSender。最後，建造者類如下：

[java] view plain copy

public class Builder {
private List<Sender> list = new ArrayList<Sender>();
public void produceMailSender(int count){
for(int i=0; i<count; i++){
list.add(new MailSender());
}
}
public void produceSmsSender(int count){
for(int i=0; i<count; i++){
list.add(new SmsSender());
}
}
}

測試類：

[java] view plain copy

public class Test {
public static void main(String[] args) {
Builder builder = new Builder();
builder.produceMailSender(10);
}
}

從這點看出，建造者模式將很多功能整合到一個類裡，這個類可以創造出比較複雜的東西。所以與工程模式的區別就是：工廠模式關注的是建立單個產品，而建造者模式則關注建立符合物件，多個部分。因此，是選擇工廠模式還是建造者模式，依實際情況而定。

5、原型模式（Prototype）

> 通過給出一個原型物件來指明所要建立的物件的型別，然後用複製這個原型物件的方法建立出更多同型別的物件。原始模型模式允許動態的增加或減少產品類，產品類不需要非得有任何事先確定的等級結構，原始模型模式適用於任何的等級結構。缺點是每一個類都必須配備一個克隆方法。

原型模式雖然是建立型的模式，但是與工程模式沒有關係，從名字即可看出，該模式的思想就是將一個物件作為原型，對其進行復制、克隆，產生一個和原物件類似的新物件。本小結會通過物件的複製，進行講解。在Java中，複製物件是通過clone()實現的，先建立一個原型類：

[java] view plain copy

public class Prototype implements Cloneable {
public Object clone() throws CloneNotSupportedException {
Prototype proto = (Prototype) super.clone();
return proto;
}
}

很簡單，一個原型類，只需要實現Cloneable介面，覆寫clone方法，此處clone方法可以改成任意的名稱，因為Cloneable介面是個空接口，你可以任意定義實現類的方法名，如cloneA或者cloneB，因為此處的重點是super.clone()這句話，super.clone()調用的是Object的clone()方法，而在Object類中，clone()是native的，具體怎麼實現，我會在另一篇文章中，關於解讀Java 中本地方法的呼叫，此處不再深究。在這兒，我將結合物件的淺複製和深複製來說一下，首先需要了解物件深、淺複製的概念：

淺複製：將一個物件複製後，基本資料型別的變數都會重新建立，而引用型別，指向的還是原物件所指向的。

深複製：將一個物件複製後，不論是基本資料型別還有引用型別，都是重新建立的。簡單來說，就是深複製進行了完全徹底的複製，而淺複製不徹底。

此處，寫一個深淺複製的例子：

[java] view plain copy

public class Prototype implements Cloneable, Serializable {
private static final long serialVersionUID = 1L;
private String string;
private SerializableObject obj;
/* 淺複製 */
public Object clone() throws CloneNotSupportedException {
Prototype proto = (Prototype) super.clone();
return proto;
}
/* 深複製 */
public Object deepClone() throws IOException, ClassNotFoundException {
/* 寫入當前物件的二進位制流 */
ByteArrayOutputStream bos = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(bos);
oos.writeObject(this);
/* 讀出二進位制流產生的新物件 */
ByteArrayInputStream bis = new ByteArrayInputStream(bos.toByteArray());
ObjectInputStream ois = new ObjectInputStream(bis);
return ois.readObject();
}
public String getString() {
return string;
}
public void setString(String string) {
this.string = string;
}
public SerializableObject getObj() {
return obj;
}
public void setObj(SerializableObject obj) {
this.obj = obj;
}
}
class SerializableObject implements Serializable {
private static final long serialVersionUID = 1L;
}

要實現深複製，需要採用流的形式讀入當前物件的二進位制輸入，再寫出二進位制資料對應的物件。

我們接著討論設計模式，上篇文章我講完了5種建立型模式，這章開始，我將講下7種結構型模式：介面卡模式、裝飾模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。其中物件的介面卡模式是各種模式的起源，我們看下面的圖：

> 介面卡模式：把一個類的介面變換成客戶端所期待的另一種介面，從而使原本因介面原因不匹配而無法一起工作的兩個類能夠一起工作。適配類可以根據引數返還一個合適的例項給客戶端。

介面卡模式將某個類的介面轉換成客戶端期望的另一個介面表示，目的是消除由於介面不匹配所造成的類的相容性問題。主要分為三類：類的介面卡模式、物件的介面卡模式、介面的介面卡模式。首先，我們來看看類的介面卡模式，先看類圖：

核心思想就是：有一個Source類，擁有一個方法，待適配，目標介面時Targetable，通過Adapter類，將Source的功能擴充套件到Targetable裡，看程式碼：類的介面卡模式

[java] view plain copy

public class Source {
public void method1() {
System.out.println("this is original method!");
}
}

[java] view plain copy

public interface Targetable {
/* 與原類中的方法相同 */
public void method1();
/* 新類的方法 */
public void method2();
}

[java] view plain copy

public class Adapter extends Source implements Targetable {
@Override
public void method2() {
System.out.println("this is the targetable method!");
}
}

Adapter類繼承Source類，實現Targetable介面，下面是測試類：

[java] view plain copy

public class AdapterTest {
public static void main(String[] args) {
Targetable target = new Adapter();
target.method1();
target.method2();
}
}

輸出：

this is original method!
this is the targetable method!

這樣Targetable介面的實現類就具有了Source類的功能。

-- 物件的介面卡模式

基本思路和類的介面卡模式相同，只是將Adapter類作修改，這次不繼承Source類，而是持有Source類的例項，以達到解決相容性的問題。看圖：

只需要修改Adapter類的原始碼即可：

[java] view plain copy

public class Wrapper implements Targetable {
private Source source;
public Wrapper(Source source){
super();
this.source = source;
}
@Override
public void method2() {
System.out.println("this is the targetable method!");
}
@Override
public void method1() {
source.method1();
}
}

測試類：

[java] view plain copy

public class AdapterTest {
public static void main(String[] args) {
Source source = new Source();
Targetable target = new Wrapper(source);
target.method1();
target.method2();
}
}

輸出與第一種一樣，只是適配的方法不同而已。

第三種介面卡模式是介面的介面卡模式，介面的介面卡是這樣的：有時我們寫的一個介面中有多個抽象方法，當我們寫該介面的實現類時，必須實現該介面的所有方法，這明顯有時比較浪費，因為並不是所有的方法都是我們需要的，有時只需要某一些，此處為了解決這個問題，我們引入了介面的介面卡模式，藉助於一個抽象類，該抽象類實現了該介面，實現了所有的方法，而我們不和原始的介面打交道，只和該抽象類取得聯絡，所以我們寫一個類，繼承該抽象類，重寫我們需要的方法就行。看一下類圖：

這個很好理解，在實際開發中，我們也常會遇到這種介面中定義了太多的方法，以致於有時我們在一些實現類中並不是都需要。看程式碼：

[java] view plain copy

public interface Sourceable {
public void method1();
public void method2();
}

抽象類Wrapper2：

[java] view plain copy

public abstract class Wrapper2 implements Sourceable{
public void method1(){}
public void method2(){}
}

[java] view plain copy

public class SourceSub1 extends Wrapper2 {
public void method1(){
System.out.println("the sourceable interface's first Sub1!");
}
}

[java] view plain copy

public class SourceSub2 extends Wrapper2 {
public void method2(){
System.out.println("the sourceable interface's second Sub2!");
}
}

[java] view plain copy

public class WrapperTest {
public static void main(String[] args) {
Sourceable source1 = new SourceSub1();
Sourceable source2 = new SourceSub2();
source1.method1();
source1.method2();
source2.method1();
source2.method2();
}
}

測試輸出：

the sourceable interface's first Sub1!
the sourceable interface's second Sub2!

達到了我們的效果！

講了這麼多，總結一下三種介面卡模式的應用場景：

- 類的介面卡模式：當希望將一個類轉換成滿足另一個新介面的類時，可以使用類的介面卡模式，建立一個新類，繼承原有的類，實現新的介面即可。

- 物件的介面卡模式：當希望將一個物件轉換成滿足另一個新介面的物件時，可以建立一個Wrapper類，持有原類的一個例項，在Wrapper類的方法中，呼叫例項的方法就行。

- 介面的介面卡模式：當不希望實現一個介面中所有的方法時，可以建立一個抽象類Wrapper，實現所有方法，我們寫別的類的時候，繼承抽象類即可。

7、裝飾模式（Decorator）

> 裝飾模式以對客戶端透明的方式擴充套件物件的功能，是繼承關係的一個替代方案，提供比繼承更多的靈活性。動態給一個物件增加功能，這些功能可以再動態的撤消。增加由一些基本功能的排列組合而產生的非常大量的功能。

顧名思義，裝飾模式就是給一個物件增加一些新的功能，而且是動態的，要求裝飾物件和被裝飾物件實現同一個介面，裝飾物件持有被裝飾物件的例項，關係圖如下：

Source類是被裝飾類，Decorator類是一個裝飾類，可以為Source類動態的新增一些功能，程式碼如下：

[java] view plain copy

public interface Sourceable {
public void method();
}

[java] view plain copy

public class Source implements Sourceable {
@Override
public void method() {
System.out.println("the original method!");
}
}

[java] view plain copy

public class Decorator implements Sourceable {
private Sourceable source;
public Decorator(Sourceable source){
super();
this.source = source;
}
@Override
public void method() {
System.out.println("before decorator!");
source.method();
System.out.println("after decorator!");
}
}

測試類：

[java] view plain copy

public class DecoratorTest {
public static void main(String[] args) {
Sourceable source = new Source();
Sourceable obj = new Decorator(source);
obj.method();
}
}

輸出：

before decorator!
the original method!
after decorator!

- 裝飾器模式的應用場景：

1、需要擴充套件一個類的功能。

2、動態的為一個物件增加功能，而且還能動態撤銷。（繼承不能做到這一點，繼承的功能是靜態的，不能動態增刪。）

缺點：產生過多相似的物件，不易排錯！

8、代理模式（Proxy）

稱為靜態代理是因為這個是在編譯階段就已經能夠確定的代理關係。
靜態代理具有代理模式的優點就是可以做到隔離業務程式碼與非業務程式碼靜態代理的主要缺點是一個委託類對應於一個代理類，並且需要為每一個需要委託的方法編寫相應的代理方法，對於專案中需要大量用到代理模式的情況，靜態代理會增加非常多的程式碼量。此外，由於代理類與委託類都實現了同樣的介面，假設介面需要變動，代理類也需要同步變動，這樣對於軟體專案維護也會增加不少的工作量與難度。

> 代理模式給某一個物件提供一個代理物件，並由代理物件控制對源物件的引用。代理就是一個人或一個機構代表另一個人或者一個機構採取行動。某些情況下，客戶不想或者不能夠直接引用一個物件，代理物件可以在客戶和目標物件直接起到中介的作用。客戶端分辨不出代理主題物件與真實主題物件。代理模式可以並不知道真正的被代理物件，而僅僅持有一個被代理物件的介面，這時候代理物件不能夠建立被代理物件，被代理物件必須有系統的其他角色代為建立並傳入。

按照代理建立的時期代理類可以分成兩種:
靜態代理:由程式設計師建立或特定工具自動生成原始碼，再對其編譯。在程式執行前，代理類的.class檔案就已經存在了。
動態代理:在程式執行時，運用反射機制動態建立而成(類載入器載入類，然後呼叫類裡面的方法)。動態代理類的原始碼是在程式執行期間由JVM根據反射等機制動態的生成，所以不存在代理類的位元組碼檔案。
Proxy 靜態方法生成動態代理類同樣需要通過類裝載器來進行裝載才能使用，它與普通類的唯一區別就是其位元組碼是由 JVM 在執行時動態生成的而非預存在於任何一個 .class 檔案中。每次生成動態代理類物件時都需要指定一個類裝載器物件。

代理模式中的靜態代理與動態代理的簡單使用-http://www.cnblogs.com/micrari/p/5639084.html

其實每個模式名稱就表明了該模式的作用，代理模式就是多一個代理類出來，替原物件進行一些操作，比如我們在租房子的時候回去找中介，為什麼呢？因為你對該地區房屋的資訊掌握的不夠全面，希望找一個更熟悉的人去幫你做，此處的代理就是這個意思。再如我們有的時候打官司，我們需要請律師，因為律師在法律方面有專長，可以替我們進行操作，表達我們的想法。先來看看關係圖：

根據上文的闡述，代理模式就比較容易的理解了，我們看下程式碼：

[java] view plain copy

public interface Sourceable {
public void method();
}

[java] view plain copy

public class Source implements Sourceable {
@Override
public void method() {
System.out.println("the original method!");
}
}

[java] view plain copy

public class Proxy implements Sourceable {
private Source source;
public Proxy(){
super();
this.source = new Source();
}
@Override
public void method() {
before();
source.method();
atfer();
}
private void atfer() {
System.out.println("after proxy!");
}
private void before() {
System.out.println("before proxy!");
}
}

測試類：

[java] view plain copy

public class ProxyTest {
public static void main(String[] args) {
Sourceable source = new Proxy();
source.method();
}
}

輸出：

before proxy!
the original method!
after proxy!

- 代理模式的應用場景：

如果已有的方法在使用的時候需要對原有的方法進行改進，此時有兩種辦法：

1、修改原有的方法來適應。這樣違反了“對擴充套件開放，對修改關閉”的原則。

2、就是採用一個代理類呼叫原有的方法，且對產生的結果進行控制。這種方法就是代理模式。

使用代理模式，可以將功能劃分的更加清晰，有助於後期維護！

-- 靜態代理和動態代理 java
java的動態代理機制詳解- http://www.cnblogs.com/xiaoluo501395377/p/3383130.html
靜態代理和動態代理的理解- https://blog.csdn.net/wangqyoho/article/details/77584832
/**
* 動態代理物件，無需實現任何介面
* 通過傳入任何型別的目標物件並指定介面
* 呼叫JDK介面動態建立代理物件
* @author jiyukai
*/
public class ProxyFactory {
private Object targetObject;
public ProxyFactory(Object targetObject) {
this.targetObject = targetObject;
}
public Object getProxyInstance(){
return Proxy.newProxyInstance(
targetObject.getClass().getClassLoader(), //和目標物件的類載入器保持一致
targetObject.getClass().getInterfaces(), //目標物件實現的介面，因為需要根據介面動態生成物件
new InvocationHandler() { //InvocationHandler:事件處理器，即對目標物件方法的執行
@Override
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
System.out.println("前攔截...");

Object result = method.invoke(proxy, args);

System.out.println("後攔截...");
return result;
}
});
}
}

9、外觀模式（Facade）

> 外部與一個子系統的通訊必須通過一個統一的門面物件進行。門面模式提供一個高層次的介面，使得子系統更易於使用。每一個子系統只有一個門面類，而且此門面類只有一個例項，也就是說它是一個單例模式。但整個系統可以有多個門面類。

外觀模式是為了解決類與類之家的依賴關係的，像spring一樣，可以將類和類之間的關係配置到配置檔案中，而外觀模式就是將他們的關係放在一個Facade類中，降低了類類之間的耦合度，該模式中沒有涉及到介面，看下類圖：（我們以一個計算機的啟動過程為例）

我們先看下實現類：

[java] view plain copy

public class CPU {
public void startup(){
System.out.println("cpu startup!");
}
public void shutdown(){
System.out.println("cpu shutdown!");
}
}

[java] view plain copy

public class Memory {
public void startup(){
System.out.println("memory startup!");
}
public void shutdown(){
System.out.println("memory shutdown!");
}
}

[java] view plain copy

public class Disk {
public void startup(){
System.out.println("disk startup!");
}
public void shutdown(){
System.out.println("disk shutdown!");
}
}

[java] view plain copy

public class Computer {
private CPU cpu;
private Memory memory;
private Disk disk;
public Computer(){
cpu = new CPU();
memory = new Memory();
disk = new Disk();
}
public void startup(){
System.out.println("start the computer!");
cpu.startup();
memory.startup();
disk.startup();
System.out.println("start computer finished!");
}
public void shutdown(){
System.out.println("begin to close the computer!");
cpu.shutdown();
memory.shutdown();
disk.shutdown();
System.out.println("computer closed!");
}
}

User類如下：

[java] view plain copy

public class User {
public static void main(String[] args) {
Computer computer = new Computer();
computer.startup();
computer.shutdown();
}
}

輸出：

start the computer!
cpu startup!
memory startup!
disk startup!
start computer finished!

begin to close the computer!
cpu shutdown!
memory shutdown!
disk shutdown!
computer closed!

如果我們沒有Computer類，那麼，CPU、Memory、Disk他們之間將會相互持有例項，產生關係，這樣會造成嚴重的依賴，修改一個類，可能會帶來其他類的修改，這不是我們想要看到的，有了Computer類，他們之間的關係被放在了Computer類裡，這樣就起到了解耦的作用，這，就是外觀模式！

10、橋接模式（Bridge）

> 將抽象化與實現化脫耦，使得二者可以獨立的變化，也就是說將他們之間的強關聯變成弱關聯，也就是指在一個軟體系統的抽象化和實現化之間使用組合/聚合關係而不是繼承關係，從而使兩者可以獨立的變化。

橋接模式就是把事物和其具體實現分開，使他們可以各自獨立的變化。橋接的用意是：將抽象化與實現化解耦，使得二者可以獨立變化，像我們常用的JDBC橋DriverManager一樣，JDBC進行連線資料庫的時候，在各個資料庫之間進行切換，基本不需要動太多的程式碼，甚至絲毫不用動，原因就是JDBC提供統一介面，每個資料庫提供各自的實現，用一個叫做資料庫驅動的程式來橋接就行了。我們來看看關係圖：

實現程式碼：

先定義介面：

[java] view plain copy

public interface Sourceable {
public void method();
}

分別定義兩個實現類：

[java] view plain copy

public class SourceSub1 implements Sourceable {
@Override
public void method() {
System.out.println("this is the first sub!");
}
}

[java] view plain copy

public class SourceSub2 implements Sourceable {
@Override
public void method() {
System.out.println("this is the second sub!");
}
}

定義一個橋，持有Sourceable的一個例項：

[java] view plain copy

public abstract class Bridge {
private Sourceable source;
public void method(){
source.method();
}
public Sourceable getSource() {
return source;
}
public void setSource(Sourceable source) {
this.source = source;
}
}

[java] view plain copy

public class MyBridge extends Bridge {
public void method(){
getSource().method();
}
}

測試類：

[java] view plain copy

public class BridgeTest {
public static void main(String[] args) {
Bridge bridge = new MyBridge();
/*呼叫第一個物件*/
Sourceable source1 = new SourceSub1();
bridge.setSource(source1);
bridge.method();
/*呼叫第二個物件*/
Sourceable source2 = new SourceSub2();
bridge.setSource(source2);
bridge.method();
}
}

output：

this is the first sub!
this is the second sub!

這樣，就通過對Bridge類的呼叫，實現了對介面Sourceable的實現類SourceSub1和SourceSub2的呼叫。接下來我再畫個圖，大家就應該明白了，因為這個圖是我們JDBC連線的原理，有資料庫學習基礎的，一結合就都懂了。

11、組合模式（Composite）

> 合成模式將物件組織到樹結構中，可以用來描述整體與部分的關係。合成模式就是一個處理物件的樹結構的模式。合成模式把部分與整體的關係用樹結構表示出來。合成模式使得客戶端把一個個單獨的成分物件和由他們複合而成的合成物件同等看待。

組合模式有時又叫部分-整體模式在處理類似樹形結構的問題時比較方便，看看關係圖：

直接來看程式碼：

[java] view plain copy

public class TreeNode {
private String name;
private TreeNode parent;
private Vector<TreeNode> children = new Vector<TreeNode>();
public TreeNode(String name){
this.name = name;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public TreeNode getParent() {
return parent;
}
public void setParent(TreeNode parent) {
this.parent = parent;
}
//新增孩子節點
public void add(TreeNode node){
children.add(node);
}
//刪除孩子節點
public void remove(TreeNode node){
children.remove(node);
}
//取得孩子節點
public Enumeration<TreeNode> getChildren(){
return children.elements();
}
}

[java] view plain copy

public class Tree {
TreeNode root = null;
public Tree(String name) {
root = new TreeNode(name);
}
public static void main(String[] args) {
Tree tree = new Tree("A");
TreeNode nodeB = new TreeNode("B");
TreeNode nodeC = new TreeNode("C");
nodeB.add(nodeC);
tree.root.add(nodeB);
System.out.println("build the tree finished!");
}
}

使用場景：將多個物件組合在一起進行操作，常用於表示樹形結構中，例如二叉樹，數等。

12、享元模式（Flyweight）

> FLYWEIGHT在拳擊比賽中指最輕量級。享元模式以共享的方式高效的支援大量的細粒度物件。享元模式能做到共享的關鍵是區分內蘊狀態和外蘊狀態。內蘊狀態儲存在享元內部，不會隨環境的改變而有所不同。外蘊狀態是隨環境的改變而改變的。外蘊狀態不能影響內蘊狀態，它們是相互獨立的。將可以共享的狀態和不可以共享的狀態從常規類中區分開來，將不可以共享的狀態從類裡剔除出去。客戶端不可以直接建立被共享的物件，而應當使用一個工廠物件負責建立被共享的物件。享元模式大幅度的降低記憶體中物件的數量。

享元模式的主要目的是實現物件的共享，即共享池，當系統中物件多的時候可以減少記憶體的開銷，通常與工廠模式一起使用。

FlyWeightFactory 負責建立和管理享元單元，當一個客戶端請求時，工廠需要檢查當前物件池中是否有符合條件的物件，如果有，就返回已經存在的物件，如果沒有，則建立一個新對象，FlyWeight是超類。一提到共享池，我們很容易聯想到Java裡面的JDBC連線池，想想每個連線的特點，我們不難總結出：適用於作共享的一些個物件，他們有一些共有的屬性，就拿資料庫連線池來說，url、driverClassName、username、password及dbname，這些屬性對於每個連線來說都是一樣的，所以就適合用享元模式來處理，建一個工廠類，將上述類似屬性作為內部資料，其它的作為外部資料，在方法呼叫時，當做參數傳進來，這樣就節省了空間，減少了例項的數量。

看個例子：

看下資料庫連線池的程式碼：

[java] view plain copy

public class ConnectionPool {
private Vector<Connection> pool;
/*公有屬性*/
private String url = "jdbc:mysql://localhost:3306/test";
private String username = "root";
private String password = "root";
private String driverClassName = "com.mysql.jdbc.Driver";
private int poolSize = 100;
private static ConnectionPool instance = null;
Connection conn = null;
/*構造方法，做一些初始化工作*/
private ConnectionPool() {
pool = new Vector<Connection>(poolSize);
for (int i = 0; i < poolSize; i++) {
try {
Class.forName(driverClassName);
conn = DriverManager.getConnection(url, username, password);
pool.add(conn);
} catch (ClassNotFoundException e) {
e.printStackTrace();
} catch (SQLException e) {
e.printStackTrace();
}
}
}
/* 返回連線到連線池 */
public synchronized void release() {
pool.add(conn);
}
/* 返回連線池中的一個資料庫連線 */
public synchronized Connection getConnection() {
if (pool.size() > 0) {
Connection conn = pool.get(0);
pool.remove(conn);
return conn;
} else {
return null;
}
}
}

通過連線池的管理，實現了資料庫連線的共享，不需要每一次都重新建立連線，節省了資料庫重新建立的開銷，提升了系統的效能！本章講解了7種結構型模式，因為篇幅的問題，剩下的11種行為型模式，

本章是關於設計模式的最後一講，會講到第三種設計模式——行為型模式，共11種：策略模式、模板方法模式、觀察者模式、迭代子模式、責任鏈模式、命令模式、備忘錄模式、狀態模式、訪問者模式、中介者模式、直譯器模式。這段時間一直在寫關於設計模式的東西，終於寫到一半了，寫博文是個很費時間的東西，因為我得為讀者負責，不論是圖還是程式碼還是表述，都希望能儘量寫清楚，以便讀者理解，我想不論是我還是讀者，都希望看到高質量的博文出來，從我本人出發，我會一直堅持下去，不斷更新，源源動力來自於讀者朋友們的不斷支援，我會盡自己的努力，寫好每一篇文章！希望大家能不斷給出意見和建議，共同打造完美的博文！

先來張圖，看看這11中模式的關係：

第一類：通過父類與子類的關係進行實現。第二類：兩個類之間。第三類：類的狀態。第四類：通過中間類

13、策略模式（strategy）

> 策略模式針對一組演算法，將每一個演算法封裝到具有共同介面的獨立的類中，從而使得它們可以相互替換。策略模式使得演算法可以在不影響到客戶端的情況下發生變化。策略模式把行為和環境分開。環境類負責維持和查詢行為類，各種演算法在具體的策略類中提供。由於演算法和環境獨立開來，演算法的增減，修改都不會影響到環境和客戶端。

策略模式定義了一系列演算法，並將每個演算法封裝起來，使他們可以相互替換，且演算法的變化不會影響到使用演算法的客戶。需要設計一個介面，為一系列實現類提供統一的方法，多個實現類實現該介面，設計一個抽象類（可有可無，屬於輔助類），提供輔助函式，關係圖如下：

圖中ICalculator提供同意的方法，
AbstractCalculator是輔助類，提供輔助方法，接下來，依次實現下每個類：

首先統一介面：

[java] view plain copy

public interface ICalculator {
public int calculate(String exp);
}

輔助類：

[java] view plain copy

public abstract class AbstractCalculator {
public int[] split(String exp,String opt){
String array[] = exp.split(opt);
int arrayInt[] = new int[2];
arrayInt[0] = Integer.parseInt(array[0]);
arrayInt[1] = Integer.parseInt(array[1]);
return arrayInt;
}
}

三個實現類：

[java] view plain copy

public class Plus extends AbstractCalculator implements ICalculator {
@Override
public int calculate(String exp) {
int arrayInt[] = split(exp,"\\+");
return arrayInt[0]+arrayInt[1];
}
}

[java] view plain copy

public class Minus extends AbstractCalculator implements ICalculator {
@Override
public int calculate(String exp) {
int arrayInt[] = split(exp,"-");
return arrayInt[0]-arrayInt[1];
}
}

[java] view plain copy

public class Multiply extends AbstractCalculator implements ICalculator {
@Override
public int calculate(String exp) {
int arrayInt[] = split(exp,"\\*");
return arrayInt[0]*arrayInt[1];
}
}

簡單的測試類：

[java] view plain copy

public class StrategyTest {
public static void main(String[] args) {
String exp = "2+8";
ICalculator cal = new Plus();
int result = cal.calculate(exp);
System.out.println(result);
}
}

輸出：10

策略模式的決定權在使用者，系統本身提供不同演算法的實現，新增或者刪除演算法，對各種演算法做封裝。因此，策略模式多用在演算法決策系統中，外部使用者只需要決定用哪個演算法即可。

14、模板方法模式（Template Method）

> 模板方法模式準備一個抽象類，將部分邏輯以具體方法以及具體構造子的形式實現，然後宣告一些抽象方法來迫使子類實現剩餘的邏輯。不同的子類可以以不同的方式實現這些抽象方法，從而對剩餘的邏輯有不同的實現。先制定一個頂級邏輯框架，而將邏輯的細節留給具體的子類去實現。

解釋一下模板方法模式，就是指：一個抽象類中，有一個主方法，再定義1...n個方法，可以是抽象的，也可以是實際的方法，定義一個類，繼承該抽象類，重寫抽象方法，通過呼叫抽象類，實現對子類的呼叫，先看個關係圖：

就是在AbstractCalculator類中定義一個主方法calculate，calculate()呼叫spilt()等，Plus和Minus分別繼承AbstractCalculator類，通過對AbstractCalculator的呼叫實現對子類的呼叫，看下面的例子：

[java] view plain copy

public abstract class AbstractCalculator {
/*主方法，實現對本類其它方法的呼叫*/
public final int calculate(String exp,String opt){
int array[] = split(exp,opt);
return calculate(array[0],array[1]);
}
/*被子類重寫的方法*/
abstract public int calculate(int num1,int num2);
public int[] split(String exp,String opt){
String array[] = exp.split(opt);
int arrayInt[] = new int[2];
arrayInt[0] = Integer.parseInt(array[0]);
arrayInt[1] = Integer.parseInt(array[1]);
return arrayInt;
}
}

[java] view plain copy

public class Plus extends AbstractCalculator {
@Override
public int calculate(int num1,int num2) {
return num1 + num2;
}
}

測試類：

[java] view plain copy

public class StrategyTest {
public static void main(String[] args) {
String exp = "8+8";
AbstractCalculator cal = new Plus();
int result = cal.calculate(exp, "\\+");
System.out.println(result);
}
}

我跟蹤下這個小程式的執行過程：首先將exp和"\\+"做引數，呼叫AbstractCalculator類裡的 calculate(String,String)方法，在calculate(String,String)裡呼叫同類的split()，之後再呼叫 calculate(int ,int)方法，從這個方法進入到子類中，執行完return num1 + num2後，將值返回到AbstractCalculator類，賦給result，列印出來。正好驗證了我們開頭的思路。

15、觀察者模式（Observer）

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

包括這個模式在內的接下來的四個模式，都是類和類之間的關係，不涉及到繼承，學的時候應該記得歸納，記得本文最開始的那個圖。觀察者模式很好理解，類似於郵件訂閱和RSS訂閱，當我們瀏覽一些部落格或wiki時，經常會看到RSS圖示，就這的意思是，當你訂閱了該文章，如果後續有更新，會及時通知你。其實，簡單來講就一句話：當一個物件變化時，其它依賴該物件的物件都會收到通知，並且隨著變化！物件之間是一種一對多的關係。先來看看關係圖：

我解釋下這些類的作用：MySubject類就是我們的主物件，Observer1和Observer2是依賴於MySubject的物件，當 MySubject變化時，Observer1和Observer2必然變化。AbstractSubject類中定義著需要監控的物件列表，可以對其進行修改：增加或刪除被監控物件，且當MySubject變化時，負責通知在列表記憶體在的物件。我們看實現程式碼：

一個Observer介面：

[java] view plain copy

public interface Observer {
public void update();
}

兩個實現類：

[java] view plain copy

public class Observer1 implements Observer {
@Override
public void update() {
System.out.println("observer1 has received!");
}
}

[java] view plain copy

public class Observer2 implements Observer {
@Override
public void update() {
System.out.println("observer2 has received!");
}
}

Subject介面及實現類：

[java] view plain copy

public interface Subject {
/*增加觀察者*/
public void add(Observer observer);
/*刪除觀察者*/
public void del(Observer observer);
/*通知所有的觀察者*/
public void notifyObservers();
/*自身的操作*/
public void operation();
}

[java] view plain copy

public abstract class AbstractSubject implements Subject {
private Vector<Observer> vector = new Vector<Observer>();
@Override
public void add(Observer observer) {
vector.add(observer);
}
@Override
public void del(Observer observer) {
vector.remove(observer);
}
@Override
public void notifyObservers() {
Enumeration<Observer> enumo = vector.elements();
while(enumo.hasMoreElements()){
enumo.nextElement().update();
}
}
}

[java] view plain copy

public class MySubject extends AbstractSubject {
@Override
public void operation() {
System.out.println("update self!");
notifyObservers();
}
}

測試類：

[java] view plain copy

public class ObserverTest {
public static void main(String[] args) {
Subject sub = new MySubject();
sub.add(new Observer1());
sub.add(new Observer2());
sub.operation();
}
}

輸出：

update self!
observer1 has received!
observer2 has received!

這些東西，其實不難，只是有些抽象，不太容易整體理解，建議讀者：根據關係圖，新建專案，自己寫程式碼（或者參考我的程式碼）,按照總體思路走一遍，這樣才能體會它的思想，理解起來容易！

16、迭代子模式（Iterator）

> 迭代子模式可以順序訪問一個聚集中的元素而不必暴露聚集的內部表象。多個物件聚在一起形成的總體稱之為聚集，聚集物件是能夠包容一組物件的容器物件。迭代子模式將迭代邏輯封裝到一個獨立的子物件中，從而與聚集本身隔開。迭代子模式簡化了聚集的介面。每一個聚集物件都可以有一個或一個以上的迭代子物件，每一個迭代子的迭代狀態可以是彼此獨立的。迭代演算法可以獨立於聚集角色變化。

顧名思義，迭代器模式就是順序訪問聚集中的物件，一般來說，集合中非常常見，如果對集合類比較熟悉的話，理解本模式會十分輕鬆。這句話包含兩層意思：一是需要遍歷的物件，即聚集物件，二是迭代器物件，用於對聚集物件進行遍歷訪問。我們看下關係圖：

這個思路和我們常用的一模一樣，MyCollection中定義了集合的一些操作，MyIterator中定義了一系列迭代操作，且持有Collection例項，我們來看看實現程式碼：

兩個介面：

[java] view plain copy

public interface Collection {
public Iterator iterator();
/*取得集合元素*/
public Object get(int i);
/*取得集合大小*/
public int size();
}

[java] view plain copy

public interface Iterator {
//前移
public Object previous();
//後移
public Object next();
public boolean hasNext();
//取得第一個元素
public Object first();
}

兩個實現：

[java] view plain copy

public class MyCollection implements Collection {
public String string[] = {"A","B","C","D","E"};
@Override
public Iterator iterator() {
return new MyIterator(this);
}
@Override
public Object get(int i) {
return string[i];
}
@Override
public int size() {
return string.length;
}
}

[java] view plain copy

public class MyIterator implements Iterator {
private Collection collection;
private int pos = -1;
public MyIterator(Collection collection){
this.collection = collection;
}
@Override
public Object previous() {
if(pos > 0){
pos--;
}
return collection.get(pos);
}
@Override
public Object next() {
if(pos<collection.size()-1){
pos++;
}
return collection.get(pos);
}
@Override
public boolean hasNext() {
if(pos<collection.size()-1){
return true;
}else{
return false;
}
}
@Override
public Object first() {
pos = 0;
return collection.get(pos);
}
}

測試類：

[java] view plain copy

public class Test {
public static void main(String[] args) {
Collection collection = new MyCollection();
Iterator it = collection.iterator();
while(it.hasNext()){
System.out.println(it.next());
}
}
}

輸出：A B C D E

此處我們貌似模擬了一個集合類的過程，感覺是不是很爽？其實JDK中各個類也都是這些基本的東西，加一些設計模式，再加一些優化放到一起的，只要我們把這些東西學會了，掌握好了，我們也可以寫出自己的集合類，甚至框架！

17、責任鏈模式（Chain of Responsibility）

> 在責任鏈模式中，很多物件由每一個物件對其下家的引用而接起來形成一條鏈。請求在這個鏈上傳遞，直到鏈上的某一個物件決定處理此請求。客戶並不知道鏈上的哪一個物件最終處理這個請求，系統可以在不影響客戶端的情況下動態的重新組織鏈和分配責任。處理者有兩個選擇：承擔責任或者把責任推給下家。一個請求可以最終不被任何接收端物件所接受。
接下來我們將要談談責任鏈模式，有多個物件，每個物件持有對下一個物件的引用，這樣就會形成一條鏈，請求在這條鏈上傳遞，直到某一物件決定處理該請求。但是發出者並不清楚到底最終那個物件會處理該請求，所以，責任鏈模式可以實現，在隱瞞客戶端的情況下，對系統進行動態的調整。先看看關係圖：

Abstracthandler類提供了get和set方法，方便MyHandle類設定和修改引用物件，MyHandle類是核心，例項化後生成一系列相互持有的物件，構成一條鏈。

[java] view plain copy

public interface Handler {
public void operator();
}

[java] view plain copy

public abstract class AbstractHandler {
private Handler handler;
public Handler getHandler() {
return handler;
}
public void setHandler(Handler handler) {
this.handler = handler;
}
}

[java] view plain copy

public class MyHandler extends AbstractHandler implements Handler {
private String name;
public MyHandler(String name) {
this.name = name;
}
@Override
public void operator() {
System.out.println(name+"deal!");
if(getHandler()!=null){
getHandler().operator();
}
}
}

[java] view plain copy

public class Test {
public static void main(String[] args) {
MyHandler h1 = new MyHandler("h1");
MyHandler h2 = new MyHandler("h2");
MyHandler h3 = new MyHandler("h3");
h1.setHandler(h2);
h2.setHandler(h3);
h1.operator();
}
}

輸出：

h1deal!
h2deal!
h3deal!

此處強調一點就是，連結上的請求可以是一條鏈，可以是一個樹，還可以是一個環，模式本身不約束這個，需要我們自己去實現，同時，在一個時刻，命令只允許由一個物件傳給另一個物件，而不允許傳給多個物件。

18、命令模式（Command）

> 命令模式把一個請求或者操作封裝到一個物件中。命令模式把發出命令的責任和執行命令的責任分割開，委派給不同的物件。命令模式允許請求的一方和傳送的一方獨立開來，使得請求的一方不必知道接收請求的一方的介面，更不必知道請求是怎麼被接收，以及操作是否執行，何時被執行以及是怎麼被執行的。系統支援命令的撤消。

命令模式很好理解，舉個例子，司令員下令讓士兵去幹件事情，從整個事情的角度來考慮，司令員的作用是，發出口令，口令經過傳遞，傳到了士兵耳朵裡，士兵去執行。這個過程好在，三者相互解耦，任何一方都不用去依賴其他人，只需要做好自己的事兒就行，司令員要的是結果，不會去關注到底士兵是怎麼實現的。我們看看關係圖：

Invoker是呼叫者（司令員），Receiver是被呼叫者（士兵），MyCommand是命令，實現了Command介面，持有接收物件，看實現程式碼：

[java] view plain copy

public interface Command {
public void exe();
}

[java] view plain copy

public class Receiver {
public void action(){
System.out.println("command received!");
}
}

[java] view plain copy

public class MyCommand implements Command {
private Receiver receiver;
public MyCommand(Receiver receiver) {
this.receiver = receiver;
}
@Override
public void exe() {
receiver.action();
}
}

[java] view plain copy

public class Invoker {
private Command command;
public Invoker(Command command) {
this.command = command;
}
public void action(){
command.exe();
}
}

[java] view plain copy

public class Test {
public static void main(String[] args) {
Receiver receiver = new Receiver();
Command cmd = new MyCommand(receiver);
Invoker invoker = new Invoker(cmd);
invoker.action();
}
}

輸出：command received!

這個很哈理解，命令模式的目的就是達到命令的發出者和執行者之間解耦，實現請求和執行分開，熟悉Struts的同學應該知道，Struts其實就是一種將請求和呈現分離的技術，其中必然涉及命令模式的思想！

其實每個設計模式都是很重要的一種思想，看上去很熟，其實是因為我們在學到的東西中都有涉及，儘管有時我們並不知道，其實在Java本身的設計之中處處都有體現，像AWT、JDBC、集合類、IO管道或者是Web框架，裡面設計模式無處不在。因為我們篇幅有限，很難講每一個設計模式都講的很詳細，不過我會盡我所能，儘量在有限的空間和篇幅內，把意思寫清楚了，更好讓大家明白。本章不出意外的話，應該是設計模式最後一講了，首先還是上一下上篇開頭的那個圖：

本章講講第三類和第四類。

19、備忘錄模式（Memento）

> 備忘錄物件是一個用來儲存另外一個物件內部狀態的快照的物件。備忘錄模式的用意是在不破壞封裝的條件下，將一個物件的狀態捉住，並外部化，儲存起來，從而可以在將來合適的時候把這個物件還原到儲存起來的狀態。

主要目的是儲存一個物件的某個狀態，以便在適當的時候恢復物件，個人覺得叫備份模式更形象些，通俗的講下：假設有原始類A，A中有各種屬性，A可以決定需要備份的屬性，備忘錄類B是用來儲存A的一些內部狀態，類C呢，就是一個用來儲存備忘錄的，且只能儲存，不能修改等操作。做個圖來分析一下：

Original類是原始類，裡面有需要儲存的屬性value及建立一個備忘錄類，用來儲存value值。Memento類是備忘錄類，Storage類是儲存備忘錄的類，持有Memento類的例項，該模式很好理解。直接看原始碼：

[java] view plain copy

public class Original {
private String value;
public String getValue() {
return value;
}
public void setValue(String value) {
this.value = value;
}
public Original(String value) {
this.value = value;
}
public Memento createMemento(){
return new Memento(value);
}
public void restoreMemento(Memento memento){
this.value = memento.getValue();
}
}

[java] view plain copy

public class Memento {
private String value;
public Memento(String value) {
this.value = value;
}
public String getValue() {
return value;
}
public void setValue(String value) {
this.value = value;
}
}

[java] view plain copy

public class Storage {
private Memento memento;
public Storage(Memento memento) {
this.memento = memento;
}
public Memento getMemento() {
return memento;
}
public void setMemento(Memento memento) {
this.memento = memento;
}
}

測試類：

[java] view plain copy

public class Test {
public static void main(String[] args) {
// 建立原始類
Original origi = new Original("egg");
// 建立備忘錄
Storage storage = new Storage(origi.createMemento());
// 修改原始類的狀態
System.out.println("初始化狀態為：" + origi.getValue());
origi.setValue("niu");
System.out.println("修改後的狀態為：" + origi.getValue());
// 回覆原始類的狀態
origi.restoreMemento(storage.getMemento());
System.out.println("恢復後的狀態為：" + origi.getValue());
}
}

輸出：

初始化狀態為：egg
修改後的狀態為：niu
恢復後的狀態為：egg

簡單描述下：新建原始類時，value被初始化為egg，後經過修改，將value的值置為niu，最後倒數第二行進行恢復狀態，結果成功恢復了。其實我覺得這個模式叫“備份-恢復”模式最形象。

20、狀態模式（State）

> 狀態模式允許一個物件在其內部狀態改變的時候改變行為。這個物件看上去象是改變了它的類一樣。狀態模式把所研究的物件的行為包裝在不同的狀態物件裡，每一個狀態物件都屬於一個抽象狀態類的一個子類。狀態模式的意圖是讓一個物件在其內部狀態改變的時候，其行為也隨之改變。狀態模式需要對每一個系統可能取得的狀態創立一個狀態類的子類。當系統的狀態變化時，系統便改變所選的子類。

核心思想就是：當物件的狀態改變時，同時改變其行為，很好理解！就拿QQ來說，有幾種狀態，線上、隱身、忙碌等，每個狀態對應不同的操作，而且你的好友也能看到你的狀態，所以，狀態模式就兩點：1、可以通過改變狀態來獲得不同的行為。2、你的好友能同時看到你的變化。看圖：

State類是個狀態類，Context類可以實現切換，我們來看看程式碼：

[java] view plain copy

package com.xtfggef.dp.state;
/**
* 狀態類的核心類
* 2012-12-1
* @author erqing
*
*/
public class State {
private String value;
public String getValue() {
return value;
}
public void setValue(String value) {
this.value = value;
}
public void method1(){
System.out.println("execute the first opt!");
}
public void method2(){
System.out.println("execute the second opt!");
}
}

[java] view plain copy

package com.xtfggef.dp.state;
/**
* 狀態模式的切換類 2012-12-1
* @author erqing
*
*/
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 method() {
if (state.getValue().equals("state1")) {
state.method1();
} else if (state.getValue().equals("state2")) {
state.method2();
}
}
}

測試類：

[java] view plain copy

public class Test {
public static void main(String[] args) {
State state = new State();
Context context = new Context(state);
//設定第一種狀態
state.setValue("state1");
context.method();
//設定第二種狀態
state.setValue("state2");
context.method();
}
}

輸出：

execute the first opt!
execute the second opt!

根據這個特性，狀態模式在日常開發中用的挺多的，尤其是做網站的時候，我們有時希望根據物件的某一屬性，區別開他們的一些功能，比如說簡單的許可權控制等。
21、訪問者模式（Visitor）

> 訪問者模式：訪問者模式的目的是封裝一些施加於某種資料結構元素之上的操作。一旦這些操作需要修改的話，接受這個操作的資料結構可以保持不變。訪問者模式適用於資料結構相對未定的系統，它把資料結構和作用於結構上的操作之間的耦合解脫開，使得操作集合可以相對自由的演化。訪問者模式使得增加新的操作變的很容易，就是增加一個新的訪問者類。訪問者模式將有關的行為集中到一個訪問者物件中，而不是分散到一個個的節點類中。當使用訪問者模式時，要將盡可能多的物件瀏覽邏輯放在訪問者類中，而不是放到它的子類中。訪問者模式可以跨過幾個類的等級結構訪問屬於不同的等級結構的成員類。

訪問者模式把資料結構和作用於結構上的操作解耦合，使得操作集合可相對自由地演化。訪問者模式適用於資料結構相對穩定演算法又易變化的系統。因為訪問者模式使得演算法操作增加變得容易。若系統資料結構物件易於變化，經常有新的資料物件增加進來，則不適合使用訪問者模式。訪問者模式的優點是增加操作很容易，因為增加操作意味著增加新的訪問者。訪問者模式將有關行為集中到一個訪問者物件中，其改變不影響系統資料結構。其缺點就是增加新的資料結構很困難。—— From 百科

簡單來說，訪問者模式就是一種分離物件資料結構與行為的方法，通過這種分離，可達到為一個被訪問者動態新增新的操作而無需做其它的修改的效果。簡單關係圖：

來看看原碼：一個Visitor類，存放要訪問的物件，

[java] view plain copy

public interface Visitor {
public void visit(Subject sub);
}

[java] view plain copy

public class MyVisitor implements Visitor {
@Override
public void visit(Subject sub) {
System.out.println("visit the subject："+sub.getSubject());
}
}

Subject類，accept方法，接受將要訪問它的物件，getSubject()獲取將要被訪問的屬性，

[java] view plain copy

public interface Subject {
public void accept(Visitor visitor);
public String getSubject();
}

[java] view plain copy

public class MySubject implements Subject {
@Override
public void accept(Visitor visitor) {
visitor.visit(this);
}
@Override
public String getSubject() {
return "love";
}
}

測試：

[java] view plain copy

public class Test {
public static void main(String[] args) {
Visitor visitor = new MyVisitor();
Subject sub = new MySubject();
sub.accept(visitor);
}
}

輸出：visit the subject：love

該模式適用場景：如果我們想為一個現有的類增加新功能，不得不考慮幾個事情：1、新功能會不會與現有功能出現相容性問題？2、以後會不會再需要新增？3、如果類不允許修改程式碼怎麼辦？面對這些問題，最好的解決方法就是使用訪問者模式，訪問者模式適用於資料結構相對穩定的系統，把資料結構和演算法解耦，
22、中介者模式（Mediator）

> 調停者模式包裝了一系列物件相互作用的方式，使得這些物件不必相互明顯作用。從而使他們可以鬆散偶合。當某些物件之間的作用發生改變時，不會立即影響其他的一些物件之間的作用。保證這些作用可以彼此獨立的變化。調停者模式將多對多的相互作用轉化為一對多的相互作用。調停者模式將物件的行為和協作抽象化，把物件在小尺度的行為上與其他物件的相互作用分開處理。

中介者模式也是用來降低類類之間的耦合的，因為如果類類之間有依賴關係的話，不利於功能的擴充和維護，因為只要修改一個物件，其它關聯的物件都得進行修改。如果使用中介者模式，只需關心和Mediator類的關係，具體類類之間的關係及排程交給Mediator就行，這有點像spring容器的作用。先看看圖：

User 類統一介面，User1和User2分別是不同的物件，二者之間有關聯，如果不採用中介者模式，則需要二者相互持有引用，這樣二者的耦合度很高，為了解耦，引入了Mediator類，提供統一介面，MyMediator為其實現類，裡面持有User1和User2的例項，用來實現對User1和 User2的控制。這樣User1和User2兩個物件相互獨立，他們只需要保持好和Mediator之間的關係就行，剩下的全由MyMediator類來維護！基本實現：

[java] view plain copy

public interface Mediator {
public void createMediator();
public void workAll();
}

[java] view plain copy

public class MyMediator implements Mediator {
private User user1;
private User user2;
public User getUser1() {
return user1;
}
public User getUser2() {
return user2;
}
@Override
public void createMediator() {
user1 = new User1(this);
user2 = new User2(this);
}
@Override
public void workAll() {
user1.work();
user2.work();
}
}

[java] view plain copy

public abstract class User {
private Mediator mediator;
public Mediator getMediator(){
return mediator;
}
public User(Mediator mediator) {
this.mediator = mediator;
}
public abstract void work();
}

[java] view plain copy

public class User1 extends User {
public User1(Mediator mediator){
super(mediator);
}
@Override
public void work() {
System.out.println("user1 exe!");
}
}

[java] view plain copy

public class User2 extends User {
public User2(Mediator mediator){
super(mediator);
}
@Override
public void work() {
System.out.println("user2 exe!");
}
}

測試類：

[java] view plain copy

public class Test {
public static void main(String[] args) {
Mediator mediator = new MyMediator();
mediator.createMediator();
mediator.workAll();
}
}

輸出：

user1 exe!
user2 exe!
23、直譯器模式（Interpreter）

> 直譯器模式：給定一個語言後，直譯器模式可以定義出其文法的一種表示，並同時提供一個直譯器。客戶端可以使用這個直譯器來解釋這個語言中的句子。直譯器模式將描述怎樣在有了一個簡單的文法後，使用模式設計解釋這些語句。在直譯器模式裡面提到的語言是指任何直譯器物件能夠解釋的任何組合。在直譯器模式中需要定義一個代表文法的命令類的等級結構，也就是一系列的組合規則。每一個命令物件都有一個解釋方法，代表對命令物件的解釋。命令物件的等級結構中的物件的任何排列組合都是一個語言。
直譯器模式是我們暫時的最後一講，一般主要應用在OOP開發中的編譯器的開發中，所以適用面比較窄。

Context類是一個上下文環境類，Plus和Minus分別是用來計算的實現，程式碼如下：

[java] view plain copy

public interface Expression {
public int interpret(Context context);
}

[java] view plain copy

public class Plus implements Expression {
@Override
public int interpret(Context context) {
return context.getNum1()+context.getNum2();
}
}

[java] view plain copy

public class Minus implements Expression {
@Override
public int interpret(Context context) {
return context.getNum1()-context.getNum2();
}
}

[java] view plain copy

public class Context {
private int num1;
private int num2;
public Context(int num1, int num2) {
this.num1 = num1;
this.num2 = num2;
}
public int getNum1() {
return num1;
}
public void setNum1(int num1) {
this.num1 = num1;
}
public int getNum2() {
return num2;
}
public void setNum2(int num2) {
this.num2 = num2;
}
}

[java] view plain copy

public class Test {
public static void main(String[] args) {
// 計算9+2-8的值
int result = new Minus().interpret((new Context(new Plus().interpret(new Context(9, 2)), 8)));
System.out.println(result);
}
}

最後輸出正確的結果：3。

基本就這樣，直譯器模式用來做各種各樣的直譯器，如正規表示式等的直譯器等等！

> 23種設計模式的總結

1、工廠模式：客戶類和工廠類分開。消費者任何時候需要某種產品，只需向工廠請求即可。消費者無須修改就可以接納新產品。缺點是當產品修改時，工廠類也要做相應的修改。如：如何建立及如何向客戶端提供。

　　2、建造模式：將產品的內部表象和產品的生成過程分割開來，從而使一個建造過程生成具有不同的內部表象的產品物件。建造模式使得產品內部表象可以獨立的變化，客戶不必知道產品內部組成的細節。建造模式可以強制實行一種分步驟進行的建造過程。

　　3、工廠方法模式：核心工廠類不再負責所有產品的建立，而是將具體建立的工作交給子類去做，成為一個抽象工廠角色，僅負責給出具體工廠類必須實現的介面，而不接觸哪一個產品類應當被例項化這種細節。

　　4、原始模型模式：通過給出一個原型物件來指明所要建立的物件的型別，然後用複製這個原型物件的方法建立出更多同型別的物件。原始模型模式允許動態的增加或減少產品類，產品類不需要非得有任何事先確定的等級結構，原始模型模式適用於任何的等級結構。缺點是每一個類都必須配備一個克隆方法。

　　5、單例模式：單例模式確保某一個類只有一個例項，而且自行例項化並向整個系統提供這個例項單例模式。單例模式只應在有真正的“單一例項”的需求時才可使用。

　　6、介面卡(變壓器)模式：把一個類的介面變換成客戶端所期待的另一種介面，從而使原本因介面原因不匹配而無法一起工作的兩個類能夠一起工作。適配類可以根據引數返還一個合適的例項給客戶端。

　　7、橋樑模式：將抽象化與實現化脫耦，使得二者可以獨立的變化，也就是說將他們之間的強關聯變成弱關聯，也就是指在一個軟體系統的抽象化和實現化之間使用組合/聚合關係而不是繼承關係，從而使兩者可以獨立的變化。

　　8、合成模式：合成模式將物件組織到樹結構中，可以用來描述整體與部分的關係。合成模式就是一個處理物件的樹結構的模式。合成模式把部分與整體的關係用樹結構表示出來。合成模式使得客戶端把一個個單獨的成分物件和由他們複合而成的合成物件同等看待。

　　9、裝飾模式：裝飾模式以對客戶端透明的方式擴充套件物件的功能，是繼承關係的一個替代方案，提供比繼承更多的靈活性。動態給一個物件增加功能，這些功能可以再動態的撤消。增加由一些基本功能的排列組合而產生的非常大量的功能。

　　10、門面模式：外部與一個子系統的通訊必須通過一個統一的門面物件進行。門面模式提供一個高層次的介面，使得子系統更易於使用。每一個子系統只有一個門面類，而且此門面類只有一個例項，也就是說它是一個單例模式。但整個系統可以有多個門面類。

　　11、享元模式：FLYWEIGHT在拳擊比賽中指最輕量級。享元模式以共享的方式高效的支援大量的細粒度物件。享元模式能做到共享的關鍵是區分內蘊狀態和外蘊狀態。內蘊狀態儲存在享元內部，不會隨環境的改變而有所不同。外蘊狀態是隨環境的改變而改變的。外蘊狀態不能影響內蘊狀態，它們是相互獨立的。將可以共享的狀態和不可以共享的狀態從常規類中區分開來，將不可以共享的狀態從類裡剔除出去。客戶端不可以直接建立被共享的物件，而應當使用一個工廠物件負責建立被共享的物件。享元模式大幅度的降低記憶體中物件的數量。

　　12、代理模式：代理模式給某一個物件提供一個代理物件，並由代理物件控制對源物件的引用。代理就是一個人或一個機構代表另一個人或者一個機構採取行動。某些情況下，客戶不想或者不能夠直接引用一個物件，代理物件可以在客戶和目標物件直接起到中介的作用。客戶端分辨不出代理主題物件與真實主題物件。代理模式可以並不知道真正的被代理物件，而僅僅持有一個被代理物件的介面，這時候代理物件不能夠建立被代理物件，被代理物件必須有系統的其他角色代為建立並傳入。

　　13、責任鏈模式：在責任鏈模式中，很多物件由每一個物件對其下家的引用而接起來形成一條鏈。請求在這個鏈上傳遞，直到鏈上的某一個物件決定處理此請求。客戶並不知道鏈上的哪一個物件最終處理這個請求，系統可以在不影響客戶端的情況下動態的重新組織鏈和分配責任。處理者有兩個選擇：承擔責任或者把責任推給下家。一個請求可以最終不被任何接收端物件所接受。

　　14、命令模式：命令模式把一個請求或者操作封裝到一個物件中。命令模式把發出命令的責任和執行命令的責任分割開，委派給不同的物件。命令模式允許請求的一方和傳送的一方獨立開來，使得請求的一方不必知道接收請求的一方的介面，更不必知道請求是怎麼被接收，以及操作是否執行，何時被執行以及是怎麼被執行的。系統支援命令的撤消。

　　15、直譯器模式：給定一個語言後，直譯器模式可以定義出其文法的一種表示，並同時提供一個直譯器。客戶端可以使用這個直譯器來解釋這個語言中的句子。直譯器模式將描述怎樣在有了一個簡單的文法後，使用模式設計解釋這些語句。在直譯器模式裡面提到的語言是指任何直譯器物件能夠解釋的任何組合。在直譯器模式中需要定義一個代表文法的命令類的等級結構，也就是一系列的組合規則。每一個命令物件都有一個解釋方法，代表對命令物件的解釋。命令物件的等級結構中的物件的任何排列組合都是一個語言。

　　16、迭代子模式：迭代子模式可以順序訪問一個聚集中的元素而不必暴露聚集的內部表象。多個物件聚在一起形成的總體稱之為聚集，聚集物件是能夠包容一組物件的容器物件。迭代子模式將迭代邏輯封裝到一個獨立的子物件中，從而與聚集本身隔開。迭代子模式簡化了聚集的介面。每一個聚集物件都可以有一個或一個以上的迭代子物件，每一個迭代子的迭代狀態可以是彼此獨立的。迭代演算法可以獨立於聚集角色變化。

　　17、調停者模式：調停者模式包裝了一系列物件相互作用的方式，使得這些物件不必相互明顯作用。從而使他們可以鬆散偶合。當某些物件之間的作用發生改變時，不會立即影響其他的一些物件之間的作用。保證這些作用可以彼此獨立的變化。調停者模式將多對多的相互作用轉化為一對多的相互作用。調停者模式將物件的行為和協作抽象化，把物件在小尺度的行為上與其他物件的相互作用分開處理。

　　18、備忘錄模式：備忘錄物件是一個用來儲存另外一個物件內部狀態的快照的物件。備忘錄模式的用意是在不破壞封裝的條件下，將一個物件的狀態捉住，並外部化，儲存起來，從而可以在將來合適的時候把這個物件還原到儲存起來的狀態。

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

　　20、狀態模式：狀態模式允許一個物件在其內部狀態改變的時候改變行為。這個物件看上去象是改變了它的類一樣。狀態模式把所研究的物件的行為包裝在不同的狀態物件裡，每一個狀態物件都屬於一個抽象狀態類的一個子類。狀態模式的意圖是讓一個物件在其內部狀態改變的時候，其行為也隨之改變。狀態模式需要對每一個系統可能取得的狀態創立一個狀態類的子類。當系統的狀態變化時，系統便改變所選的子類。

　　21、策略模式：策略模式針對一組演算法，將每一個演算法封裝到具有共同介面的獨立的類中，從而使得它們可以相互替換。策略模式使得演算法可以在不影響到客戶端的情況下發生變化。策略模式把行為和環境分開。環境類負責維持和查詢行為類，各種演算法在具體的策略類中提供。由於演算法和環境獨立開來，演算法的增減，修改都不會影響到環境和客戶端。

　　22、模板方法模式：模板方法模式準備一個抽象類，將部分邏輯以具體方法以及具體構造子的形式實現，然後宣告一些抽象方法來迫使子類實現剩餘的邏輯。不同的子類可以以不同的方式實現這些抽象方法，從而對剩餘的邏輯有不同的實現。先制定一個頂級邏輯框架，而將邏輯的細節留給具體的子類去實現。

　　23、訪問者模式：訪問者模式的目的是封裝一些施加於某種資料結構元素之上的操作。一旦這些操作需要修改的話，接受這個操作的資料結構可以保持不變。訪問者模式適用於資料結構相對未定的系統，它把資料結構和作用於結構上的操作之間的耦合解脫開，使得操作集合可以相對自由的演化。訪問者模式使得增加新的操作變的很容易，就是增加一個新的訪問者類。訪問者模式將有關的行為集中到一個訪問者物件中，而不是分散到一個個的節點類中。當使用訪問者模式時，要將盡可能多的物件瀏覽邏輯放在訪問者類中，而不是放到它的子類中。訪問者模式可以跨過幾個類的等級結構訪問屬於不同的等級結構的成員類。

> 物件導向的原則：
1.面向介面程式設計而不是針對實現程式設計
2.優先使用物件組合而不是類繼承
Abtract Factory：提供一個建立一系列相關或相互依賴物件的藉口，而無需指定他們具體的類
Adapter：將一個介面轉換成使用者希望的另一種介面，使得原本因為介面不相容的那些類能一起工作
Bridge：將抽象部分和它的實現部分分離，使兩者可以獨立的變化
Builder：將一個複雜物件的構建和它的表示分離，使得同樣的構建過程可以建立不同的表示
Chain of responsibility：為接觸請求的傳送者和接受者之間的耦合，使得多個物件都有機會處理這個請求。將這些物件連成一條鏈，並沿著這條鏈傳遞該請求，直到有一個物件處理它。
Command：將一個請求封裝成一個物件，從而使你可用不同的請求對客戶進行引數化；對請求排隊或者記錄請求日誌，以及支援可取消的操作
Composite：將物件組合成樹形結構以表示“部分-整體”的層次結構，Composite使得客戶對單個物件和複合物件的使用具有一致性
Decorator：動態的給一個物件新增一些額外的職責，就擴充套件功能而言，Decorator模式比生成子類模式更為靈活
Facade(fe'said):為子系統的一組介面提供一個一致的介面，Facade模式定義了一個高層介面，這個介面使得這一子系統更加容易使用
Factory Method：定義一個用於建立物件的介面，讓子類決定哪一個類將例項化，Factory Method使一個類的例項化延遲到子類。
Flyweight：運用共享技術有效的支援大量細粒度的物件
Interpreter：給定一種語言，定義它文法的一種表示，並定義一個直譯器，該直譯器使用該表示來解釋語言中的句子
Iterator：提供一種方法訪問聚合物件中的各個元素，而又不需要暴露該物件的內部表示
Mediator：使用一箇中介物件來封裝一系列的物件互動。中介者使個物件不需要顯示的相互引用，從而使其耦合鬆散，而且可以獨立的改變它們的互動。
Memento：在不破壞封裝性的前提下，捕獲一個物件的內部狀態，並在該物件外儲存該狀態。這樣以後就可以將該物件恢復到儲存的狀態
Observer：定義物件建議中一對多的依賴關係，以便當一個物件的狀態發生改變時，所有依賴於它的物件都得到通知並自動重新整理
Prototype：用原型例項指定建立物件的種類，並通過拷貝這個例項來建立新的物件
Proxy：為其他物件提供一個代理以控制這個物件的訪問
Singleton：保證一個類僅有一個例項，並提供一個訪問它的全域性訪問點
State：允許一個物件在其內部狀態改變時改變它的行為。物件看起來似乎修改了它所屬的類
Strategy：定義一系列演算法，並將他們一個個封裝起來，並且它們可以相互替換。使演算法的變化可以獨立於它的客戶
Template Method：定義一個操作中演算法的骨架，而降一些步驟延遲到子類中。使子類可以不改變一個演算法的結構即可重定義該演算法的某些特定步驟
Visitor：一個作用於某物件結構中各元素的的操作。使你在不改變各元素的類的前提下定義作用於這些元素的新操作

> 策略模式是通過不同的演算法做同一件事情：例如排序

而命令模式則是通過不同的命令做不同的事情，常含有（關聯）接收者。目標不同！

命令模式是含有不同的命令（含有接收者的請求）：做不同的事情；隱藏接收者執行細節。常見選單事件，

而策略模式含有不同的演算法，做相同的事情；

區別在於是否含有接收者。命令模式含有，策略模式不含有。

命令模式中的命令可以單獨執行。

打個比喻就是：命令模式等於選單中的複製，移動，壓縮等，而策略模式是其中一個選單的例如複製到不同演算法實現。

--------------------------------------

android 24種設計模式介紹與6大設計原則 -- http://download.csdn.net/detail/qq2220810599/9600987

設計模式【遊戲設計模式】之四《遊戲程式設計模式》全書內容提煉總結- http://blog.csdn.net/poem_qianmo/article/details/53240330

> Java中的24種設計模式與7大原則:
一、建立型模式
1、抽象工廠模式(Abstract factory pattern): 提供一個介面, 用於建立相關或依賴物件的家族, 而不需要指定具體類.
2、生成器模式(Builder pattern): 使用生成器模式封裝一個產品的構造過程, 並允許按步驟構造. 將一個複雜物件的構建與它的表示分離, 使得同樣的構建過程可以建立不同的表示.
3、工廠模式(factory method pattern): 定義了一個建立物件的介面, 但由子類決定要例項化的類是哪一個. 工廠方法讓類把例項化推遲到子類.
4、原型模式(prototype pattern): 當建立給定類的例項過程很昂貴或很複雜時, 就使用原形模式.
5、單例了模式(Singleton pattern): 確保一個類只有一個例項, 並提供全域性訪問點.
6、多例模式(Multition pattern): 在一個解決方案中結合兩個或多個模式, 以解決一般或重複發生的問題.

二、結構型模式
1、介面卡模式(Adapter pattern): 將一個類的介面, 轉換成客戶期望的另一個介面. 介面卡讓原本介面不相容的類可以合作無間. 物件介面卡使用組合, 類介面卡使用多重繼承.
2、橋接模式(Bridge pattern): 使用橋接模式通過將實現和抽象放在兩個不同的類層次中而使它們可以獨立改變.
3、組合模式(composite pattern): 允許你將物件組合成樹形結構來表現"整體/部分"層次結構. 組合能讓客戶以一致的方式處理個別物件以及物件組合.
4、裝飾者模式(decorator pattern): 動態地將責任附加到物件上, 若要擴充套件功能, 裝飾者提供了比繼承更有彈性的替代方案.
5、外觀模式(facade pattern): 提供了一個統一的介面, 用來訪問子系統中的一群介面. 外觀定義了一個高層介面, 讓子系統更容易使用.
6、亨元模式(Flyweight Pattern): 如想讓某個類的一個例項能用來提供許多"虛擬例項", 就使用蠅量模式.
7、代理模式(Proxy pattern): 為另一個物件提供一個替身或佔位符以控制對這個物件的訪問.

三、行為型模式
1、責任鏈模式(Chain of responsibility pattern): 通過責任鏈模式, 你可以為某個請求建立一個物件鏈. 每個物件依序檢查此請求並對其進行處理或者將它傳給鏈中的下一個物件.
2、命令模式(Command pattern): 將"請求"封閉成物件, 以便使用不同的請求,佇列或者日誌來引數化其他物件. 命令模式也支援可撤銷的操作.
3、直譯器模式(Interpreter pattern): 使用直譯器模式為語言建立直譯器.
4、迭代器模式(iterator pattern): 提供一種方法順序訪問一個聚合物件中的各個元素, 而又不暴露其內部的表示.
5、中介者模式(Mediator pattern) : 使用中介者模式來集中相關物件之間複雜的溝通和控制方式.
6、備忘錄模式(Memento pattern): 當你需要讓物件返回之前的狀態時(例如, 你的使用者請求"撤銷"), 你使用備忘錄模式.
7、觀察者模式(observer pattern): 在物件之間定義一對多的依賴, 這樣一來, 當一個物件改變狀態, 依賴它的物件都會收到通知, 並自動更新.
8、狀態模式(State pattern): 允許物件在內部狀態改變時改變它的行為, 物件看起來好象改了它的類.
9、策略模式(strategy pattern): 定義了演算法族, 分別封閉起來, 讓它們之間可以互相替換, 此模式讓演算法的變化獨立於使用演算法的客戶.
10、模板方法模式(Template pattern): 在一個方法中定義一個演算法的骨架, 而將一些步驟延遲到子類中. 模板方法使得子類可以在不改變演算法結構的情況下, 重新定義演算法中的某些步驟.
11、訪問者模式(visitor pattern): 當你想要為一個物件的組合增加新的能力, 且封裝並不重要時, 就使用訪問者模式.

七大設計原則：
1、單一職責原則【SINGLE RESPONSIBILITY PRINCIPLE】：一個類負責一項職責.
2、里氏替換原則【LISKOV SUBSTITUTION PRINCIPLE】：繼承與派生的規則.
3、依賴倒置原則【DEPENDENCE INVERSION PRINCIPLE】：高層模組不應該依賴低層模組，二者都應該依賴其抽象；抽象不應該依賴細節；細節應該依賴抽象。即針對介面程式設計，不要針對實現程式設計.
4、介面隔離原則【INTERFACE SEGREGATION PRINCIPLE】：建立單一介面，不要建立龐大臃腫的介面，儘量細化介面，介面中的方法儘量少.
5、迪米特法則【LOW OF DEMETER】：低耦合，高內聚.
6、開閉原則【OPEN CLOSE PRINCIPLE】：一個軟體實體如類、模組和函式應該對擴充套件開放，對修改關閉.
7、組合/聚合複用原則【Composition/Aggregation Reuse Principle(CARP) 】：儘量使用組合和聚合少使用繼承的關係來達到複用的原則.

設計模式，及在Java中的應用

相關文章