那些大工廠里常用到的那些設計模式挺勿,你們平常都在用么曲横?


一、設計模式的分類

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

創(chuàng)建型模式不瓶,共五種:工廠方法模式禾嫉、抽象工廠模式、單例模式湃番、建造者模式夭织、原型模式。

結構型模式吠撮,共七種:適配器模式尊惰、裝飾器模式讲竿、代理模式、外觀模式弄屡、橋接模式题禀、組合模式、享元模式膀捷。

行為型模式迈嘹,共十一種:策略模式、模板方法模式全庸、觀察者模式秀仲、迭代子模式、責任鏈模式壶笼、命令模式神僵、備忘錄模式、狀態(tài)模式覆劈、訪問者模式保礼、中介者模式、解釋器模式责语。

其實還有兩類:并發(fā)型模式和線程池模式炮障。用一個圖片來整體描述一下:

請點擊此處輸入圖片描述

二、設計模式常用到的六大原則

1坤候、開閉原則(Open Close Principle)

開閉原則就是說對擴展開放胁赢,對修改關閉。在程序需要進行拓展的時候铐拐,不能去修改原有的代碼徘键,實現(xiàn)一個熱插拔的效果。所以一句話概括就是:為了使程序的擴展性好遍蟋,易于維護和升級。想要達到這樣的效果螟凭,我們需要使用接口和抽象類虚青,后面的具體設計中我們會提到這點。

2螺男、里氏代換原則(Liskov Substitution Principle)

里氏代換原則(Liskov Substitution Principle LSP)面向對象設計的基本原則之一棒厘。 里氏代換原則中說,任何基類可以出現(xiàn)的地方下隧,子類一定可以出現(xiàn)奢人。 LSP是繼承復用的基石,只有當衍生類可以替換掉基類淆院,軟件單位的功能不受到影響時何乎,基類才能真正被復用,而衍生類也能夠在基類的基礎上增加新的行為。里氏代換原則是對“開-閉”原則的補充支救。實現(xiàn)“開-閉”原則的關鍵步驟就是抽象化抢野。而基類與子類的繼承關系就是抽象化的具體實現(xiàn),所以里氏代換原則是對實現(xiàn)抽象化的具體步驟的規(guī)范各墨≈腹拢—— From Baidu 百科

3、依賴倒轉原則(Dependence Inversion Principle)

這個是開閉原則的基礎贬堵,具體內(nèi)容:真對接口編程恃轩,依賴于抽象而不依賴于具體。

4黎做、接口隔離原則(Interface Segregation Principle)

這個原則的意思是:使用多個隔離的接口详恼,比使用單個接口要好。還是一個降低類之間的耦合度的意思引几,從這兒我們看出昧互,其實設計模式就是一個軟件的設計思想,從大型軟件架構出發(fā)伟桅,為了升級和維護方便敞掘。所以上文中多次出現(xiàn):降低依賴,降低耦合楣铁。

5玖雁、迪米特法則(最少知道原則)(Demeter Principle)

為什么叫最少知道原則,就是說:一個實體應當盡量少的與其他實體之間發(fā)生相互作用盖腕,使得系統(tǒng)功能模塊相對獨立赫冬。

6、合成復用原則(Composite Reuse Principle)

原則是盡量使用合成/聚合的方式溃列,而不是使用繼承劲厌。

各大工廠里常用到的設計模式

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

1雅任、工廠方法模式(Factory Method)

工廠方法模式分為三種:

1.1:普通工廠模式风范,就是建立一個工廠類,對實現(xiàn)了同一接口的一些類進行實例的創(chuàng)建沪么。首先看下關系圖:

請點擊此處輸入圖片描述

舉例如下:(我們舉一個發(fā)送郵件和短信的例子)

首先硼婿,創(chuàng)建二者的共同接口:

[java]view plaincopy

publicinterface?Sender?{??

????publicvoid?Send();??

}??

其次,創(chuàng)建實現(xiàn)類:

[java]view plaincopy

publicclass?MailSender?implements?Sender?{??

@Override

????publicvoid?Send()?{??

????????System.out.println("this?is?mailsender!");??

????}??

}??

[java]view plaincopy

publicclass?SmsSender?implements?Sender?{??


@Override

????publicvoid?Send()?{??

????????System.out.println("this?is?sms?sender!");??

????}??

}??

最后禽车,建工廠類:

[java]view plaincopy

publicclass?SendFactory?{??


????public?Sender?produce(String?type)?{??

????????if?("mail".equals(type))?{??

????????????returnnew?MailSender();??

????????}?elseif?("sms".equals(type))?{??

????????????returnnew?SmsSender();??

????????}?else?{??

????????????System.out.println("請輸入正確的類型!");??

????????????returnnull;??

????????}??

????}??

}??

我們來測試下:

publicclass?FactoryTest?{??


????publicstaticvoid?main(String[]?args)?{??

????????SendFactory?factory?=?new?SendFactory();??

????????Sender?sender?=?factory.produce("sms");??

????????sender.Send();??

????}??

}??

輸出:this is sms sender!

1.2:多個工廠方法模式订歪,是對普通工廠方法模式的改進,在普通工廠方法模式中径缅,如果傳遞的字符串出錯,則不能正確創(chuàng)建對象冗澈,而多個工廠方法模式是提供多個工廠方法,分別創(chuàng)建對象陋葡。關系圖:

請點擊此處輸入圖片描述

將上面的代碼做下修改亚亲,改動下SendFactory類就行,如下:

[java]view plaincopypublicclass?SendFactory?{

public?Sender?produceMail(){ ?

????????returnnew?MailSender();??

????}??


????public?Sender?produceSms(){??

????????returnnew?SmsSender();??

????}??

}??

測試類如下:

[java]view plaincopy

publicclass?FactoryTest?{??


????publicstaticvoid?main(String[]?args)?{??

????????SendFactory?factory?=?new?SendFactory();??

????????Sender?sender?=?factory.produceMail();??

????????sender.Send();??

????}??

}??

輸出:this is mailsender!

1.3:靜態(tài)工廠方法模式腐缤,將上面的多個工廠方法模式里的方法置為靜態(tài)的捌归,不需要創(chuàng)建實例,直接調(diào)用即可岭粤。

[java]view plaincopy

publicclass?SendFactory?{??


????publicstatic?Sender?produceMail(){??

????????returnnew?MailSender();??

????}??


????publicstatic?Sender?produceSms(){??

????????returnnew?SmsSender();??

????}??

}??

[java]view plaincopy

publicclass?FactoryTest?{??


????publicstaticvoid?main(String[]?args)?{??????

????????Sender?sender?=?SendFactory.produceMail();??

????????sender.Send();??

????}??

}??

輸出:this is mailsender!

總體來說惜索,工廠模式適合:凡是出現(xiàn)了大量的產(chǎn)品需要創(chuàng)建,并且具有共同的接口時剃浇,可以通過工廠方法模式進行創(chuàng)建巾兆。在以上的三種模式中,第一種如果傳入的字符串有誤虎囚,不能正確創(chuàng)建對象角塑,第三種相對于第二種,不需要實例化工廠類淘讥,所以圃伶,大多數(shù)情況下,我們會選用第三種——靜態(tài)工廠方法模式蒲列。

2窒朋、抽象工廠模式(Abstract Factory)

工廠方法模式有一個問題就是,類的創(chuàng)建依賴工廠類蝗岖,也就是說侥猩,如果想要拓展程序,必須對工廠類進行修改剪侮,這違背了閉包原則拭宁,所以,從設計角度考慮瓣俯,有一定的問題,如何解決兵怯?就用到抽象工廠模式彩匕,創(chuàng)建多個工廠類,這樣一旦需要增加新的功能媒区,直接增加新的工廠類就可以了驼仪,不需要修改之前的代碼掸犬。因為抽象工廠不太好理解,我們先看看圖绪爸,然后就和代碼湾碎,就比較容易理解。

請點擊此處輸入圖片描述

請看例子:

[java]view plaincopy

publicinterface?Sender?{??

????publicvoid?Send();??

}??

兩個實現(xiàn)類:

[java]view plaincopy

publicclass?MailSender?implements?Sender?{??

@Override

????publicvoid?Send()?{??

????????System.out.println("this?is?mailsender!");??

????}??

}??

[java]view plaincopy

publicclass?SmsSender?implements?Sender?{??


@Override

????publicvoid?Send()?{??

????????System.out.println("this?is?sms?sender!");??

????}??

}??

兩個工廠類:

[java]view plaincopy

publicclass?SendMailFactory?implements?Provider?{??


@Override

????public?Sender?produce(){??

????????returnnew?MailSender();??

????}??

}??

[java]view plaincopy

publicclass?SendSmsFactory?implements?Provider{??


????@Override

????public?Sender?produce()?{??

????????returnnew?SmsSender();??

????}??

}??

在提供一個接口:

[java]view plaincopy

publicinterface?Provider?{??

????public?Sender?produce();??

}??

測試類:

[java]view plaincopy

publicclass?Test?{??


????publicstaticvoid?main(String[]?args)?{??

????????Provider?provider?=?new?SendMailFactory();??

????????Sender?sender?=?provider.produce();??

????????sender.Send();??

????}??

}??

其實這個模式的好處就是奠货,如果你現(xiàn)在想增加一個功能:發(fā)及時信息介褥,則只需做一個實現(xiàn)類,實現(xiàn)Sender接口递惋,同時做一個工廠類柔滔,實現(xiàn)Provider接口,就OK了萍虽,無需去改動現(xiàn)成的代碼睛廊。這樣做,拓展性較好杉编!

3超全、單例模式(Singleton)

單例對象(Singleton)是一種常用的設計模式。在Java應用中邓馒,單例對象能保證在一個JVM中嘶朱,該對象只有一個實例存在。這樣的模式有幾個好處:

1绒净、某些類創(chuàng)建比較頻繁见咒,對于一些大型的對象,這是一筆很大的系統(tǒng)開銷挂疆。

2改览、省去了new操作符,降低了系統(tǒng)內(nèi)存的使用頻率缤言,減輕GC壓力宝当。

3、有些類如交易所的核心交易引擎胆萧,控制著交易流程庆揩,如果該類可以創(chuàng)建多個的話,系統(tǒng)完全亂了跌穗。(比如一個軍隊出現(xiàn)了多個司令員同時指揮订晌,肯定會亂成一團),所以只有使用單例模式蚌吸,才能保證核心交易服務器獨立控制整個流程锈拨。

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

[java]view plaincopy

publicclass?Singleton?{??


????/*?持有私有靜態(tài)實例,防止被引用羹唠,此處賦值為null奕枢,目的是實現(xiàn)延遲加載?*/

????privatestatic?Singleton?instance?=?null;??


????/*?私有構造方法娄昆,防止被實例化?*/

????private?Singleton()?{??

????}??


????/*?靜態(tài)工程方法,創(chuàng)建實例?*/

????publicstatic?Singleton?getInstance()?{??

????????if?(instance?==?null)?{??

????????????instance?=?new?Singleton();??

????????}??

????????return?instance;??

????}??


????/*?如果該對象被用于序列化缝彬,可以保證對象在序列化前后保持一致?*/

????public?Object?readResolve()?{??

????????return?instance;??

????}??

}??

這個類可以滿足基本要求萌焰,但是,像這樣毫無線程安全保護的類谷浅,如果我們把它放入多線程的環(huán)境下扒俯,肯定就會出現(xiàn)問題了,如何解決壳贪?我們首先會想到對getInstance方法加synchronized關鍵字陵珍,如下:

[java]view plaincopy

publicstaticsynchronized?Singleton?getInstance()?{??

????????if?(instance?==?null)?{??

????????????instance?=?new?Singleton();??

????????}??

????????return?instance;??

????}??

但是,synchronized關鍵字鎖住的是這個對象违施,這樣的用法互纯,在性能上會有所下降,因為每次調(diào)用getInstance()磕蒲,都要對對象上鎖留潦,事實上,只有在第一次創(chuàng)建對象的時候需要加鎖辣往,之后就不需要了兔院,所以,這個地方需要改進站削。我們改成下面這個:

[java]view plaincopy

publicstatic?Singleton?getInstance()?{??

????????if?(instance?==?null)?{??

????????????synchronized?(instance)?{??

????????????????if?(instance?==?null)?{??

????????????????????instance?=?new?Singleton();??

????????????????}??

????????????}??

????????}??

????????return?instance;??

????}??

似乎解決了之前提到的問題坊萝,將synchronized關鍵字加在了內(nèi)部,也就是說當調(diào)用的時候是不需要加鎖的许起,只有在instance為null十偶,并創(chuàng)建對象的時候才需要加鎖,性能有一定的提升园细。但是惦积,這樣的情況,還是有可能有問題的猛频,看下面的情況:在Java指令中創(chuàng)建對象和賦值操作是分開進行的狮崩,也就是說instance = new Singleton();語句是分兩步執(zhí)行的。但是JVM并不保證這兩個操作的先后順序鹿寻,也就是說有可能JVM會為新的Singleton實例分配空間睦柴,然后直接賦值給instance成員,然后再去初始化這個Singleton實例毡熏。這樣就可能出錯了爱只,我們以A、B兩個線程為例:

a>A招刹、B線程同時進入了第一個if判斷

b>A首先進入synchronized塊恬试,由于instance為null,所以它執(zhí)行instance = new Singleton();

c>由于JVM內(nèi)部的優(yōu)化機制疯暑,JVM先畫出了一些分配給Singleton實例的空白內(nèi)存训柴,并賦值給instance成員(注意此時JVM沒有開始初始化這個實例),然后A離開了synchronized塊妇拯。

d>B進入synchronized塊幻馁,由于instance此時不是null,因此它馬上離開了synchronized塊并將結果返回給調(diào)用該方法的程序越锈。

e>此時B線程打算使用Singleton實例仗嗦,卻發(fā)現(xiàn)它沒有被初始化,于是錯誤發(fā)生了甘凭。

所以程序還是有可能發(fā)生錯誤稀拐,其實程序在運行過程是很復雜的,從這點我們就可以看出丹弱,尤其是在寫多線程環(huán)境下的程序更有難度德撬,有挑戰(zhàn)性。我們對該程序做進一步優(yōu)化:

[java]view plaincopy

privatestaticclass?SingletonFactory{???????????

????????privatestatic?Singleton?instance?=?new?Singleton();???????????

????}???????????

????publicstatic?Singleton?getInstance(){???????????

????????return?SingletonFactory.instance;???????????

????}???

實際情況是躲胳,單例模式使用內(nèi)部類來維護單例的實現(xiàn)蜓洪,JVM內(nèi)部的機制能夠保證當一個類被加載的時候,這個類的加載過程是線程互斥的坯苹。這樣當我們第一次調(diào)用getInstance的時候隆檀,JVM能夠幫我們保證instance只被創(chuàng)建一次,并且會保證把賦值給instance的內(nèi)存初始化完畢粹湃,這樣我們就不用擔心上面的問題恐仑。同時該方法也只會在第一次調(diào)用的時候使用互斥機制,這樣就解決了低性能問題再芋。這樣我們暫時總結一個完美的單例模式:

[java]view plaincopy

publicclass?Singleton?{??


????/*?私有構造方法菊霜,防止被實例化?*/

????private?Singleton()?{??

????}??


????/*?此處使用一個內(nèi)部類來維護單例?*/

????privatestaticclass?SingletonFactory?{??

????????privatestatic?Singleton?instance?=?new?Singleton();??

????}??


????/*?獲取實例?*/

????publicstatic?Singleton?getInstance()?{??

????????return?SingletonFactory.instance;??

????}??


????/*?如果該對象被用于序列化,可以保證對象在序列化前后保持一致?*/

????public?Object?readResolve()?{??

????????return?getInstance();??

????}??

}??

其實說它完美济赎,也不一定鉴逞,如果在構造函數(shù)中拋出異常,實例將永遠得不到創(chuàng)建司训,也會出錯构捡。所以說,十分完美的東西是沒有的壳猜,我們只能根據(jù)實際情況勾徽,選擇最適合自己應用場景的實現(xiàn)方法。也有人這樣實現(xiàn):因為我們只需要在創(chuàng)建類的時候進行同步统扳,所以只要將創(chuàng)建和getInstance()分開喘帚,單獨為創(chuàng)建加synchronized關鍵字畅姊,也是可以的:

[java]view plaincopy

publicclass?SingletonTest?{??


????privatestatic?SingletonTest?instance?=?null;??


????private?SingletonTest()?{??

????}??


????privatestaticsynchronizedvoid?syncInit()?{??

????????if?(instance?==?null)?{??

????????????instance?=?new?SingletonTest();??

????????}??

????}??


????publicstatic?SingletonTest?getInstance()?{??

????????if?(instance?==?null)?{??

????????????syncInit();??

????????}??

????????return?instance;??

????}??

}??

考慮性能的話,整個程序只需創(chuàng)建一次實例吹由,所以性能也不會有什么影響若未。

補充:采用"影子實例"的辦法為單例對象的屬性同步更新

[java]view plaincopy

publicclass?SingletonTest?{??


????privatestatic?SingletonTest?instance?=?null;??

????private?Vector?properties?=?null;??


????public?Vector?getProperties()?{??

????????return?properties;??

????}??


????private?SingletonTest()?{??

????}??


????privatestaticsynchronizedvoid?syncInit()?{??

????????if?(instance?==?null)?{??

????????????instance?=?new?SingletonTest();??

????????}??

????}??


????publicstatic?SingletonTest?getInstance()?{??

????????if?(instance?==?null)?{??

????????????syncInit();??

????????}??

????????return?instance;??

????}??


????publicvoid?updateProperties()?{??

????????SingletonTest?shadow?=?new?SingletonTest();??

????????properties?=?shadow.getProperties();??

????}??

}??

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

1、單例模式理解起來簡單倾鲫,但是具體實現(xiàn)起來還是有一定的難度粗合。

2、synchronized關鍵字鎖定的是對象乌昔,在用的時候隙疚,一定要在恰當?shù)牡胤绞褂茫ㄗ⒁庑枰褂面i的對象和過程,可能有的時候并不是整個對象及整個過程都需要鎖)磕道。

到這兒供屉,單例模式基本已經(jīng)講完了,結尾處捅厂,筆者突然想到另一個問題贯卦,就是采用類的靜態(tài)方法,實現(xiàn)單例模式的效果焙贷,也是可行的撵割,此處二者有什么不同?

首先辙芍,靜態(tài)類不能實現(xiàn)接口啡彬。(從類的角度說是可以的,但是那樣就破壞了靜態(tài)了故硅。因為接口中不允許有static修飾的方法庶灿,所以即使實現(xiàn)了也是非靜態(tài)的)

其次,單例可以被延遲初始化吃衅,靜態(tài)類一般在第一次加載是初始化往踢。之所以延遲加載,是因為有些類比較龐大徘层,所以延遲加載有助于提升性能峻呕。

再次,單例類可以被繼承趣效,他的方法可以被覆寫瘦癌。但是靜態(tài)類內(nèi)部方法都是static,無法被覆寫跷敬。

最后一點讯私,單例類比較靈活,畢竟從實現(xiàn)上只是一個普通的Java類,只要滿足單例的基本需求斤寇,你可以在里面隨心所欲的實現(xiàn)一些其它功能桶癣,但是靜態(tài)類不行。從上面這些概括中抡驼,基本可以看出二者的區(qū)別鬼廓,但是,從另一方面講致盟,我們上面最后實現(xiàn)的那個單例模式,內(nèi)部就是用一個靜態(tài)類來實現(xiàn)的尤慰,所以馏锡,二者有很大的關聯(lián),只是我們考慮問題的層面不同罷了伟端。兩種思想的結合杯道,才能造就出完美的解決方案,就像HashMap采用數(shù)組+鏈表來實現(xiàn)一樣责蝠,其實生活中很多事情都是這樣,單用不同的方法來處理問題,總是有優(yōu)點也有缺點告材,最完美的方法是或南,結合各個方法的優(yōu)點,才能最好的解決問題肴敛!

4署海、建造者模式(Builder)

工廠類模式提供的是創(chuàng)建單個類的模式,而建造者模式則是將各種產(chǎn)品集中起來進行管理医男,用來創(chuàng)建復合對象砸狞,所謂復合對象就是指某個類具有不同的屬性,其實建造者模式就是前面抽象工廠模式和最后的Test結合起來得到的镀梭。我們看一下代碼:

還和前面一樣刀森,一個Sender接口,兩個實現(xiàn)類MailSender和SmsSender报账。最后研底,建造者類如下:

[java]view plaincopy

publicclass?Builder?{??


????private?List?list?=?new?ArrayList();??


????publicvoid?produceMailSender(int?count){??

????????for(int?i=0;?i

????????????list.add(new?MailSender());??

????????}??

????}??


????publicvoid?produceSmsSender(int?count){??

????????for(int?i=0;?i

????????????list.add(new?SmsSender());??

????????}??

????}??

}??

測試類:

[java]view plaincopy

publicclass?Test?{??


????publicstaticvoid?main(String[]?args)?{??

????????Builder?builder?=?new?Builder();??

????????builder.produceMailSender(10);??

????}??

}??

從這點看出,建造者模式將很多功能集成到一個類里笙什,這個類可以創(chuàng)造出比較復雜的東西飘哨。所以與工程模式的區(qū)別就是:工廠模式關注的是創(chuàng)建單個產(chǎn)品,而建造者模式則關注創(chuàng)建符合對象琐凭,多個部分芽隆。因此,是選擇工廠模式還是建造者模式,依實際情況而定胚吁。

5牙躺、原型模式(Prototype)

原型模式雖然是創(chuàng)建型的模式,但是與工程模式?jīng)]有關系腕扶,從名字即可看出孽拷,該模式的思想就是將一個對象作為原型,對其進行復制半抱、克隆脓恕,產(chǎn)生一個和原對象類似的新對象。本小結會通過對象的復制窿侈,進行講解炼幔。在Java中,復制對象是通過clone()實現(xiàn)的史简,先創(chuàng)建一個原型類:

[java]view plaincopy

publicclass?Prototype?implements?Cloneable?{??


????public?Object?clone()?throws?CloneNotSupportedException?{??

????????Prototype?proto?=?(Prototype)?super.clone();??

????????return?proto;??

????}??

}??

很簡單乃秀,一個原型類,只需要實現(xiàn)Cloneable接口圆兵,覆寫clone方法跺讯,此處clone方法可以改成任意的名稱,因為Cloneable接口是個空接口殉农,你可以任意定義實現(xiàn)類的方法名刀脏,如cloneA或者cloneB,因為此處的重點是super.clone()這句話统抬,super.clone()調(diào)用的是Object的clone()方法火本,而在Object類中,clone()是native的聪建,具體怎么實現(xiàn)钙畔,我會在另一篇文章中,關于解讀Java中本地方法的調(diào)用金麸,此處不再深究擎析。在這兒,我將結合對象的淺復制和深復制來說一下挥下,首先需要了解對象深揍魂、淺復制的概念:

淺復制:將一個對象復制后,基本數(shù)據(jù)類型的變量都會重新創(chuàng)建棚瘟,而引用類型现斋,指向的還是原對象所指向的。

深復制:將一個對象復制后偎蘸,不論是基本數(shù)據(jù)類型還有引用類型庄蹋,都是重新創(chuàng)建的瞬内。簡單來說,就是深復制進行了完全徹底的復制限书,而淺復制不徹底虫蝶。

此處,寫一個深淺復制的例子:

[java]view plaincopy

publicclass?Prototype?implements?Cloneable,?Serializable?{??


????privatestaticfinallong?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);??


????????/*?讀出二進制流產(chǎn)生的新對象?*/

????????ByteArrayInputStream?bis?=?new?ByteArrayInputStream(bos.toByteArray());??

????????ObjectInputStream?ois?=?new?ObjectInputStream(bis);??

????????return?ois.readObject();??

????}??


????public?String?getString()?{??

????????return?string;??

????}??


????publicvoid?setString(String?string)?{??

????????this.string?=?string;??

????}??


????public?SerializableObject?getObj()?{??

????????return?obj;??

????}??


????publicvoid?setObj(SerializableObject?obj)?{??

????????this.obj?=?obj;??

????}??


}??


class?SerializableObject?implements?Serializable?{??

????privatestaticfinallong?serialVersionUID?=?1L;??

}??

要實現(xiàn)深復制倦西,需要采用流的形式讀入當前對象的二進制輸入能真,再寫出二進制數(shù)據(jù)對應的對象。

我們接著討論設計模式扰柠,上篇文章我講完了5種創(chuàng)建型模式粉铐,這章開始,我將講下7種結構型模式:適配器模式耻矮、裝飾模式秦躯、代理模式、外觀模式裆装、橋接模式、組合模式倡缠、享元模式哨免。其中對象的適配器模式是各種模式的起源,我們看下面的圖:

請點擊此處輸入圖片描述

適配器模式將某個類的接口轉換成客戶端期望的另一個接口表示昙沦,目的是消除由于接口不匹配所造成的類的兼容性問題琢唾。主要分為三類:類的適配器模式、對象的適配器模式盾饮、接口的適配器模式采桃。首先,我們來看看類的適配器模式丘损,先看類圖:

請點擊此處輸入圖片描述

核心思想就是:有一個Source類普办,擁有一個方法,待適配徘钥,目標接口時Targetable衔蹲,通過Adapter類,將Source的功能擴展到Targetable里呈础,看代碼:

[java]view plaincopy

publicclass?Source?{??


????publicvoid?method1()?{??

????????System.out.println("this?is?original?method!");??

????}??

}??

[java]view plaincopy

publicinterface?Targetable?{??


????/*?與原類中的方法相同?*/

????publicvoid?method1();??


????/*?新類的方法?*/

????publicvoid?method2();??

}??

[java]view plaincopy

publicclass?Adapter?extends?Source?implements?Targetable?{??


????@Override

????publicvoid?method2()?{??

????????System.out.println("this?is?the?targetable?method!");??

????}??

}??

Adapter類繼承Source類舆驶,實現(xiàn)Targetable接口,下面是測試類:

[java]view plaincopy

publicclass?AdapterTest?{??


????publicstaticvoid?main(String[]?args)?{??

????????Targetable?target?=?new?Adapter();??

????????target.method1();??

????????target.method2();??

????}??

}??

輸出:

this is original method!

this is the targetable method!

這樣Targetable接口的實現(xiàn)類就具有了Source類的功能而钞。

對象的適配器模式

基本思路和類的適配器模式相同沙廉,只是將Adapter類作修改,這次不繼承Source類臼节,而是持有Source類的實例撬陵,以達到解決兼容性的問題珊皿。看圖:

請點擊此處輸入圖片描述

只需要修改Adapter類的源碼即可:

[java]view plaincopy

publicclass?Wrapper?implements?Targetable?{??


????private?Source?source;??


????public?Wrapper(Source?source){??

????????super();??

????????this.source?=?source;??

????}??

????@Override

????publicvoid?method2()?{??

????????System.out.println("this?is?the?targetable?method!");??

????}??


????@Override

????publicvoid?method1()?{??

????????source.method1();??

????}??

}??

測試類:

[java]view plaincopy

publicclass?AdapterTest?{??


????publicstaticvoid?main(String[]?args)?{??

????????Source?source?=?new?Source();??

????????Targetable?target?=?new?Wrapper(source);??

????????target.method1();??

????????target.method2();??

????}??

}??

輸出與第一種一樣袱结,只是適配的方法不同而已亮隙。

第三種適配器模式是接口的適配器模式,接口的適配器是這樣的:有時我們寫的一個接口中有多個抽象方法垢夹,當我們寫該接口的實現(xiàn)類時溢吻,必須實現(xiàn)該接口的所有方法,這明顯有時比較浪費果元,因為并不是所有的方法都是我們需要的促王,有時只需要某一些,此處為了解決這個問題而晒,我們引入了接口的適配器模式蝇狼,借助于一個抽象類,該抽象類實現(xiàn)了該接口倡怎,實現(xiàn)了所有的方法迅耘,而我們不和原始的接口打交道,只和該抽象類取得聯(lián)系监署,所以我們寫一個類颤专,繼承該抽象類,重寫我們需要的方法就行钠乏∑茱酰看一下類圖:

請點擊此處輸入圖片描述

這個很好理解,在實際開發(fā)中晓避,我們也常會遇到這種接口中定義了太多的方法簇捍,以致于有時我們在一些實現(xiàn)類中并不是都需要∏喂埃看代碼:

[java]view plaincopy

publicinterface?Sourceable?{??


????publicvoid?method1();??

????publicvoid?method2();??

}??

抽象類Wrapper2:

[java]view plaincopy

publicabstractclass?Wrapper2?implements?Sourceable{??


????publicvoid?method1(){}??

????publicvoid?method2(){}??

}??

[java]view plaincopy

publicclass?SourceSub1?extends?Wrapper2?{??

????publicvoid?method1(){??

????????System.out.println("the?sourceable?interface's?first?Sub1!");??

????}??

}??

[java]view plaincopy

publicclass?SourceSub2?extends?Wrapper2?{??

????publicvoid?method2(){??

????????System.out.println("the?sourceable?interface's?second?Sub2!");??

????}??

}??

[java]view plaincopy

publicclass?WrapperTest?{??


????publicstaticvoid?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!

達到了我們的效果暑塑!

?講了這么多,總結一下三種適配器模式的應用場景:

類的適配器模式:當希望將一個類轉換成滿足另一個新接口的類時彰触,可以使用類的適配器模式梯投,創(chuàng)建一個新類,繼承原有的類况毅,實現(xiàn)新的接口即可分蓖。

對象的適配器模式:當希望將一個對象轉換成滿足另一個新接口的對象時,可以創(chuàng)建一個Wrapper類尔许,持有原類的一個實例么鹤,在Wrapper類的方法中,調(diào)用實例的方法就行味廊。

接口的適配器模式:當不希望實現(xiàn)一個接口中所有的方法時蒸甜,可以創(chuàng)建一個抽象類Wrapper棠耕,實現(xiàn)所有方法,我們寫別的類的時候柠新,繼承抽象類即可窍荧。

7、裝飾模式(Decorator)

顧名思義恨憎,裝飾模式就是給一個對象增加一些新的功能蕊退,而且是動態(tài)的,要求裝飾對象和被裝飾對象實現(xiàn)同一個接口憔恳,裝飾對象持有被裝飾對象的實例瓤荔,關系圖如下:

請點擊此處輸入圖片描述

Source類是被裝飾類,Decorator類是一個裝飾類钥组,可以為Source類動態(tài)的添加一些功能输硝,代碼如下:

[java]view plaincopy

publicinterface?Sourceable?{??

????publicvoid?method();??

}??

[java]view plaincopy

publicclass?Source?implements?Sourceable?{??


????@Override

????publicvoid?method()?{??

????????System.out.println("the?original?method!");??

????}??

}??

[java]view plaincopy

publicclass?Decorator?implements?Sourceable?{??


????private?Sourceable?source;??


????public?Decorator(Sourceable?source){??

????????super();??

????????this.source?=?source;??

????}??

????@Override

????publicvoid?method()?{??

????????System.out.println("before?decorator!");??

????????source.method();??

????????System.out.println("after?decorator!");??

????}??

}??

測試類:

[java]view plaincopy

publicclass?DecoratorTest?{??


????publicstaticvoid?main(String[]?args)?{??

????????Sourceable?source?=?new?Source();??

????????Sourceable?obj?=?new?Decorator(source);??

????????obj.method();??

????}??

}??

輸出:

before decorator!

the original method!

after decorator!

裝飾器模式的應用場景:

1、需要擴展一個類的功能程梦。

2点把、動態(tài)的為一個對象增加功能,而且還能動態(tài)撤銷屿附。(繼承不能做到這一點愉粤,繼承的功能是靜態(tài)的,不能動態(tài)增刪拿撩。)

缺點:產(chǎn)生過多相似的對象,不易排錯如蚜!

8压恒、代理模式(Proxy)

其實每個模式名稱就表明了該模式的作用,代理模式就是多一個代理類出來错邦,替原對象進行一些操作探赫,比如我們在租房子的時候回去找中介,為什么呢撬呢?因為你對該地區(qū)房屋的信息掌握的不夠全面伦吠,希望找一個更熟悉的人去幫你做,此處的代理就是這個意思魂拦。再如我們有的時候打官司毛仪,我們需要請律師,因為律師在法律方面有專長芯勘,可以替我們進行操作箱靴,表達我們的想法。先來看看關系圖:

請點擊此處輸入圖片描述

根據(jù)上文的闡述荷愕,代理模式就比較容易的理解了衡怀,我們看下代碼:

[java]view plaincopy

publicinterface?Sourceable?{??

????publicvoid?method();??

}??

[java]view plaincopy

publicclass?Source?implements?Sourceable?{??


????@Override

????publicvoid?method()?{??

????????System.out.println("the?original?method!");??

????}??

}??

[java]view plaincopy

publicclass?Proxy?implements?Sourceable?{??


????private?Source?source;??

????public?Proxy(){??

????????super();??

????????this.source?=?new?Source();??

????}??

????@Override

????publicvoid?method()?{??

????????before();??

????????source.method();??

????????atfer();??

????}??

????privatevoid?atfer()?{??

????????System.out.println("after?proxy!");??

????}??

????privatevoid?before()?{??

????????System.out.println("before?proxy!");??

????}??

}??

測試類:

[java]view plaincopy

publicclass?ProxyTest?{??


????publicstaticvoid?main(String[]?args)?{??

????????Sourceable?source?=?new?Proxy();??

????????source.method();??

????}??


}??

輸出:

before proxy!

the original method!

after proxy!

代理模式的應用場景:

如果已有的方法在使用的時候需要對原有的方法進行改進棍矛,此時有兩種辦法:

1、修改原有的方法來適應抛杨。這樣違反了“對擴展開放够委,對修改關閉”的原則。

2怖现、就是采用一個代理類調(diào)用原有的方法茁帽,且對產(chǎn)生的結果進行控制。這種方法就是代理模式真竖。

使用代理模式脐雪,可以將功能劃分的更加清晰,有助于后期維護恢共!

9战秋、外觀模式(Facade)

外觀模式是為了解決類與類之家的依賴關系的,像spring一樣讨韭,可以將類和類之間的關系配置到配置文件中脂信,而外觀模式就是將他們的關系放在一個Facade類中,降低了類類之間的耦合度透硝,該模式中沒有涉及到接口狰闪,看下類圖:(我們以一個計算機的啟動過程為例)

請點擊此處輸入圖片描述

我們先看下實現(xiàn)類:

[java]view plaincopy

publicclass?CPU?{??


????publicvoid?startup(){??

????????System.out.println("cpu?startup!");??

????}??


????publicvoid?shutdown(){??

????????System.out.println("cpu?shutdown!");??

????}??

}??

[java]view plaincopy

publicclass?Memory?{??


????publicvoid?startup(){??

????????System.out.println("memory?startup!");??

????}??


????publicvoid?shutdown(){??

????????System.out.println("memory?shutdown!");??

????}??

}??

[java]view plaincopy

publicclass?Disk?{??


????publicvoid?startup(){??

????????System.out.println("disk?startup!");??

????}??


????publicvoid?shutdown(){??

????????System.out.println("disk?shutdown!");??

????}??

}??

[java]view plaincopy

publicclass?Computer?{??

????private?CPU?cpu;??

????private?Memory?memory;??

????private?Disk?disk;??


????public?Computer(){??

????????cpu?=?new?CPU();??

????????memory?=?new?Memory();??

????????disk?=?new?Disk();??

????}??


????publicvoid?startup(){??

????????System.out.println("start?the?computer!");??

????????cpu.startup();??

????????memory.startup();??

????????disk.startup();??

????????System.out.println("start?computer?finished!");??

????}??


????publicvoid?shutdown(){??

????????System.out.println("begin?to?close?the?computer!");??

????????cpu.shutdown();??

????????memory.shutdown();??

????????disk.shutdown();??

????????System.out.println("computer?closed!");??

????}??

}??

User類如下:

[java]view plaincopy

publicclass?User?{??


????publicstaticvoid?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他們之間將會相互持有實例罪治,產(chǎn)生關系丽声,這樣會造成嚴重的依賴,修改一個類觉义,可能會帶來其他類的修改雁社,這不是我們想要看到的,有了Computer類晒骇,他們之間的關系被放在了Computer類里霉撵,這樣就起到了解耦的作用,這洪囤,就是外觀模式徒坡!

在此我向大家推薦一個交流學習群:575745314 ?里面會分享一些資深架構師錄制的視頻錄像:有Spring,MyBatis箍鼓,Netty源碼分析崭参,高并發(fā)、高性能款咖、分布式何暮、微服務架構的原理奄喂,JVM性能優(yōu)化這些成為架構師必備的知識體系。還能領取免費的學習資源海洼,目前受益良多

10跨新、橋接模式(Bridge)

橋接模式就是把事物和其具體實現(xiàn)分開,使他們可以各自獨立的變化坏逢。橋接的用意是:將抽象化與實現(xiàn)化解耦域帐,使得二者可以獨立變化梳杏,像我們常用的JDBC橋DriverManager一樣锹雏,JDBC進行連接數(shù)據(jù)庫的時候谎懦,在各個數(shù)據(jù)庫之間進行切換陈症,基本不需要動太多的代碼,甚至絲毫不用動牡拇,原因就是JDBC提供統(tǒng)一接口尽爆,每個數(shù)據(jù)庫提供各自的實現(xiàn)浇借,用一個叫做數(shù)據(jù)庫驅動的程序來橋接就行了事秀。我們來看看關系圖:

請點擊此處輸入圖片描述

實現(xiàn)代碼:

先定義接口:

[java]view plaincopy

publicinterface?Sourceable?{??

????publicvoid?method();??

}??

分別定義兩個實現(xiàn)類:

[java]view plaincopy

publicclass?SourceSub1?implements?Sourceable?{??


????@Override

????publicvoid?method()?{??

????????System.out.println("this?is?the?first?sub!");??

????}??

}??

[java]view plaincopy

publicclass?SourceSub2?implements?Sourceable?{??


????@Override

????publicvoid?method()?{??

????????System.out.println("this?is?the?second?sub!");??

????}??

}??

定義一個橋彤断,持有Sourceable的一個實例:

[java]view plaincopy

publicabstractclass?Bridge?{??

????private?Sourceable?source;??


????publicvoid?method(){??

????????source.method();??

????}??


????public?Sourceable?getSource()?{??

????????return?source;??

????}??


????publicvoid?setSource(Sourceable?source)?{??

????????this.source?=?source;??

????}??

}??

[java]view plaincopy

publicclass?MyBridge?extends?Bridge?{??

????publicvoid?method(){??

????????getSource().method();??

????}??

}??

測試類:

[java]view plaincopy

publicclass?BridgeTest?{??


????publicstaticvoid?main(String[]?args)?{??


????????Bridge?bridge?=?new?MyBridge();??


????????/*調(diào)用第一個對象*/

????????Sourceable?source1?=?new?SourceSub1();??

????????bridge.setSource(source1);??

????????bridge.method();??


????????/*調(diào)用第二個對象*/

????????Sourceable?source2?=?new?SourceSub2();??

????????bridge.setSource(source2);??

????????bridge.method();??

????}??

}??

output:

this is the first sub!

this is the second sub!

這樣,就通過對Bridge類的調(diào)用易迹,實現(xiàn)了對接口Sourceable的實現(xiàn)類SourceSub1和SourceSub2的調(diào)用宰衙。接下來我再畫個圖,大家就應該明白了睹欲,因為這個圖是我們JDBC連接的原理供炼,有數(shù)據(jù)庫學習基礎的,一結合就都懂了窘疮。

請點擊此處輸入圖片描述

11劲蜻、組合模式(Composite)

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

請點擊此處輸入圖片描述

直接來看代碼:

[java]view plaincopy

publicclass?TreeNode?{??


????private?String?name;??

????private?TreeNode?parent;??

????private?Vector?children?=?new?Vector();??


????public?TreeNode(String?name){??

????????this.name?=?name;??

????}??


????public?String?getName()?{??

????????return?name;??

????}??


????publicvoid?setName(String?name)?{??

????????this.name?=?name;??

????}??


????public?TreeNode?getParent()?{??

????????return?parent;??

????}??


????publicvoid?setParent(TreeNode?parent)?{??

????????this.parent?=?parent;??

????}??


????//添加孩子節(jié)點

????publicvoid?add(TreeNode?node){??

????????children.add(node);??

????}??


????//刪除孩子節(jié)點

????publicvoid?remove(TreeNode?node){??

????????children.remove(node);??

????}??


????//取得孩子節(jié)點

????public?Enumeration?getChildren(){??

????????return?children.elements();??

????}??

}??

[java]view plaincopy

publicclass?Tree?{??


????TreeNode?root?=?null;??


????public?Tree(String?name)?{??

????????root?=?new?TreeNode(name);??

????}??


????publicstaticvoid?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!");??

????}??

}??

使用場景:將多個對象組合在一起進行操作考余,常用于表示樹形結構中,例如二叉樹轧苫,數(shù)等楚堤。

12、享元模式(Flyweight)

享元模式的主要目的是實現(xiàn)對象的共享含懊,即共享池身冬,當系統(tǒng)中對象多的時候可以減少內(nèi)存的開銷,通常與工廠模式一起使用岔乔。

請點擊此處輸入圖片描述

FlyWeightFactory負責創(chuàng)建和管理享元單元酥筝,當一個客戶端請求時,工廠需要檢查當前對象池中是否有符合條件的對象雏门,如果有嘿歌,就返回已經(jīng)存在的對象掸掏,如果沒有,則創(chuàng)建一個新對象宙帝,F(xiàn)lyWeight是超類丧凤。一提到共享池,我們很容易聯(lián)想到Java里面的JDBC連接池步脓,想想每個連接的特點愿待,我們不難總結出:適用于作共享的一些個對象,他們有一些共有的屬性靴患,就拿數(shù)據(jù)庫連接池來說仍侥,url、driverClassName鸳君、username农渊、password及dbname,這些屬性對于每個連接來說都是一樣的相嵌,所以就適合用享元模式來處理腿时,建一個工廠類,將上述類似屬性作為內(nèi)部數(shù)據(jù)饭宾,其它的作為外部數(shù)據(jù)批糟,在方法調(diào)用時,當做參數(shù)傳進來看铆,這樣就節(jié)省了空間徽鼎,減少了實例的數(shù)量。

看個例子:

請點擊此處輸入圖片描述

看下數(shù)據(jù)庫連接池的代碼:

[java]view plaincopy

publicclass?ConnectionPool?{??


????private?Vector?pool;??


????/*公有屬性*/

????private?String?url?=?"jdbc:mysql://localhost:3306/test";??

????private?String?username?=?"root";??

????private?String?password?=?"root";??

????private?String?driverClassName?=?"com.mysql.jdbc.Driver";??


????privateint?poolSize?=?100;??

????privatestatic?ConnectionPool?instance?=?null;??

????Connection?conn?=?null;??


????/*構造方法弹惦,做一些初始化工作*/

????private?ConnectionPool()?{??

????????pool?=?new?Vector(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();??

????????????}??

????????}??

????}??


????/*?返回連接到連接池?*/

????publicsynchronizedvoid?release()?{??

????????pool.add(conn);??

????}??


????/*?返回連接池中的一個數(shù)據(jù)庫連接?*/

????publicsynchronized?Connection?getConnection()?{??

????????if?(pool.size()?>?0)?{??

????????????Connection?conn?=?pool.get(0);??

????????????pool.remove(conn);??

????????????return?conn;??

????????}?else?{??

????????????returnnull;??

????????}??

????}??

}??

通過連接池的管理否淤,實現(xiàn)了數(shù)據(jù)庫連接的共享,不需要每一次都重新創(chuàng)建連接棠隐,節(jié)省了數(shù)據(jù)庫重新創(chuàng)建的開銷石抡,提升了系統(tǒng)的性能!本章講解了7種結構型模式助泽,因為篇幅的問題啰扛,剩下的11種行為型模式,

本章是關于設計模式的最后一講嗡贺,會講到第三種設計模式——行為型模式隐解,共11種:策略模式、模板方法模式诫睬、觀察者模式煞茫、迭代子模式、責任鏈模式、命令模式续徽、備忘錄模式蚓曼、狀態(tài)模式、訪問者模式炸宵、中介者模式辟躏、解釋器模式。這段時間一直在寫關于設計模式的東西土全,終于寫到一半了捎琐,寫博文是個很費時間的東西,因為我得為讀者負責裹匙,不論是圖還是代碼還是表述瑞凑,都希望能盡量寫清楚,以便讀者理解概页,我想不論是我還是讀者籽御,都希望看到高質量的博文出來,從我本人出發(fā)惰匙,我會一直堅持下去技掏,不斷更新,源源動力來自于讀者朋友們的不斷支持项鬼,我會盡自己的努力哑梳,寫好每一篇文章!希望大家能不斷給出意見和建議绘盟,共同打造完美的博文鸠真!

先來張圖,看看這11中模式的關系:

第一類:通過父類與子類的關系進行實現(xiàn)龄毡。第二類:兩個類之間吠卷。第三類:類的狀態(tài)。第四類:通過中間類

替換高清大圖

請點擊此處輸入圖片描述

13沦零、策略模式(strategy)

策略模式定義了一系列算法祭隔,并將每個算法封裝起來,使他們可以相互替換路操,且算法的變化不會影響到使用算法的客戶序攘。需要設計一個接口,為一系列實現(xiàn)類提供統(tǒng)一的方法寻拂,多個實現(xiàn)類實現(xiàn)該接口,設計一個抽象類(可有可無丈牢,屬于輔助類)祭钉,提供輔助函數(shù),關系圖如下:

請點擊此處輸入圖片描述

圖中ICalculator提供同意的方法己沛,

AbstractCalculator是輔助類慌核,提供輔助方法距境,接下來,依次實現(xiàn)下每個類:

首先統(tǒng)一接口:

[java]view plaincopy

publicinterface?ICalculator?{??

????publicint?calculate(String?exp);??

}??

輔助類:

[java]view plaincopy

publicabstractclass?AbstractCalculator?{??


????publicint[]?split(String?exp,String?opt){??

????????String?array[]?=?exp.split(opt);??

????????int?arrayInt[]?=?newint[2];??

????????arrayInt[0]?=?Integer.parseInt(array[0]);??

????????arrayInt[1]?=?Integer.parseInt(array[1]);??

????????return?arrayInt;??

????}??

}??

三個實現(xiàn)類:

[java]view plaincopy

publicclass?Plus?extends?AbstractCalculator?implements?ICalculator?{??


????@Override

????publicint?calculate(String?exp)?{??

????????int?arrayInt[]?=?split(exp,"\\+");??

????????return?arrayInt[0]+arrayInt[1];??

????}??

}??

[java]view plaincopy

publicclass?Minus?extends?AbstractCalculator?implements?ICalculator?{??


????@Override

????publicint?calculate(String?exp)?{??

????????int?arrayInt[]?=?split(exp,"-");??

????????return?arrayInt[0]-arrayInt[1];??

????}??


}??

[java]view plaincopy

publicclass?Multiply?extends?AbstractCalculator?implements?ICalculator?{??


????@Override

????publicint?calculate(String?exp)?{??

????????int?arrayInt[]?=?split(exp,"\\*");??

????????return?arrayInt[0]*arrayInt[1];??

????}??

}??

簡單的測試類:

[java]view plaincopy

publicclass?StrategyTest?{??


????publicstaticvoid?main(String[]?args)?{??

????????String?exp?=?"2+8";??

????????ICalculator?cal?=?new?Plus();??

????????int?result?=?cal.calculate(exp);??

????????System.out.println(result);??

????}??

}??

輸出:10

策略模式的決定權在用戶垮卓,系統(tǒng)本身提供不同算法的實現(xiàn)垫桂,新增或者刪除算法,對各種算法做封裝粟按。因此诬滩,策略模式多用在算法決策系統(tǒng)中,外部用戶只需要決定用哪個算法即可灭将。

14疼鸟、模板方法模式(Template Method)

解釋一下模板方法模式,就是指:一個抽象類中庙曙,有一個主方法空镜,再定義1...n個方法,可以是抽象的捌朴,也可以是實際的方法吴攒,定義一個類,繼承該抽象類砂蔽,重寫抽象方法洼怔,通過調(diào)用抽象類,實現(xiàn)對子類的調(diào)用察皇,先看個關系圖:

請點擊此處輸入圖片描述

就是在AbstractCalculator類中定義一個主方法calculate茴厉,calculate()調(diào)用spilt()等,Plus和Minus分別繼承AbstractCalculator類什荣,通過對AbstractCalculator的調(diào)用實現(xiàn)對子類的調(diào)用矾缓,看下面的例子:

[java]view plaincopy

publicabstractclass?AbstractCalculator?{??


????/*主方法,實現(xiàn)對本類其它方法的調(diào)用*/

????publicfinalint?calculate(String?exp,String?opt){??

????????int?array[]?=?split(exp,opt);??

????????return?calculate(array[0],array[1]);??

????}??


????/*被子類重寫的方法*/

????abstractpublicint?calculate(int?num1,int?num2);??


????publicint[]?split(String?exp,String?opt){??

????????String?array[]?=?exp.split(opt);??

????????int?arrayInt[]?=?newint[2];??

????????arrayInt[0]?=?Integer.parseInt(array[0]);??

????????arrayInt[1]?=?Integer.parseInt(array[1]);??

????????return?arrayInt;??

????}??

}??

[java]view plaincopy

publicclass?Plus?extends?AbstractCalculator?{??


????@Override

????publicint?calculate(int?num1,int?num2)?{??

????????return?num1?+?num2;??

????}??

}??

測試類:

[java]view plaincopy

publicclass?StrategyTest?{??


????publicstaticvoid?main(String[]?args)?{??

????????String?exp?=?"8+8";??

????????AbstractCalculator?cal?=?new?Plus();??

????????int?result?=?cal.calculate(exp,?"\\+");??

????????System.out.println(result);??

????}??

}??

我跟蹤下這個小程序的執(zhí)行過程:首先將exp和"\\+"做參數(shù)稻爬,調(diào)用AbstractCalculator類里的calculate(String,String)方法嗜闻,在calculate(String,String)里調(diào)用同類的split(),之后再調(diào)用calculate(int ,int)方法桅锄,從這個方法進入到子類中琉雳,執(zhí)行完return num1 + num2后,將值返回到AbstractCalculator類友瘤,賦給result翠肘,打印出來。正好驗證了我們開頭的思路辫秧。

15束倍、觀察者模式(Observer)

包括這個模式在內(nèi)的接下來的四個模式,都是類和類之間的關系,不涉及到繼承绪妹,學的時候應該 記得歸納甥桂,記得本文最開始的那個圖。觀察者模式很好理解邮旷,類似于郵件訂閱和RSS訂閱黄选,當我們?yōu)g覽一些博客或wiki時,經(jīng)常會看到RSS圖標婶肩,就這的意思是办陷,當你訂閱了該文章,如果后續(xù)有更新狡孔,會及時通知你懂诗。其實,簡單來講就一句話:當一個對象變化時苗膝,其它依賴該對象的對象都會收到通知殃恒,并且隨著變化!對象之間是一種一對多的關系辱揭。先來看看關系圖:

請點擊此處輸入圖片描述

我解釋下這些類的作用:MySubject類就是我們的主對象离唐,Observer1和Observer2是依賴于MySubject的對象,當MySubject變化時问窃,Observer1和Observer2必然變化亥鬓。AbstractSubject類中定義著需要監(jiān)控的對象列表,可以對其進行修改:增加或刪除被監(jiān)控對象域庇,且當MySubject變化時嵌戈,負責通知在列表內(nèi)存在的對象。我們看實現(xiàn)代碼:

一個Observer接口:

[java]view plaincopy

publicinterface?Observer?{??

????publicvoid?update();??

}??

兩個實現(xiàn)類:

[java]view plaincopy

publicclass?Observer1?implements?Observer?{??


????@Override

????publicvoid?update()?{??

????????System.out.println("observer1?has?received!");??

????}??

}??

[java]view plaincopy

publicclass?Observer2?implements?Observer?{??


????@Override

????publicvoid?update()?{??

????????System.out.println("observer2?has?received!");??

????}??


}??

Subject接口及實現(xiàn)類:

[java]view plaincopy

publicinterface?Subject?{??


????/*增加觀察者*/

????publicvoid?add(Observer?observer);??


????/*刪除觀察者*/

????publicvoid?del(Observer?observer);??


????/*通知所有的觀察者*/

????publicvoid?notifyObservers();??


????/*自身的操作*/

????publicvoid?operation();??

}??

[java]view plaincopy

publicabstractclass?AbstractSubject?implements?Subject?{??


????private?Vector?vector?=?new?Vector();??

????@Override

????publicvoid?add(Observer?observer)?{??

????????vector.add(observer);??

????}??


????@Override

????publicvoid?del(Observer?observer)?{??

????????vector.remove(observer);??

????}??


????@Override

????publicvoid?notifyObservers()?{??

????????Enumeration?enumo?=?vector.elements();??

????????while(enumo.hasMoreElements()){??

????????????enumo.nextElement().update();??

????????}??

????}??

}??

[java]view plaincopy

publicclass?MySubject?extends?AbstractSubject?{??


????@Override

????publicvoid?operation()?{??

????????System.out.println("update?self!");??

????????notifyObservers();??

????}??


}??

測試類:

[java]view plaincopy

publicclass?ObserverTest?{??


????publicstaticvoid?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!

這些東西听皿,其實不難熟呛,只是有些抽象,不太容易整體理解尉姨,建議讀者:根據(jù)關系圖庵朝,新建項目,自己寫代碼(或者參考我的代碼),按照總體思路走一遍又厉,這樣才能體會它的思想九府,理解起來容易!

16覆致、迭代子模式(Iterator)

顧名思義侄旬,迭代器模式就是順序訪問聚集中的對象,一般來說煌妈,集合中非常常見儡羔,如果對集合類比較熟悉的話婆排,理解本模式會十分輕松。這句話包含兩層意思:一是需要遍歷的對象笔链,即聚集對象,二是迭代器對象腮猖,用于對聚集對象進行遍歷訪問鉴扫。我們看下關系圖:

請點擊此處輸入圖片描述

這個思路和我們常用的一模一樣,MyCollection中定義了集合的一些操作澈缺,MyIterator中定義了一系列迭代操作坪创,且持有Collection實例,我們來看看實現(xiàn)代碼:

兩個接口:

[java]view plaincopy

publicinterface?Collection?{??


????public?Iterator?iterator();??


????/*取得集合元素*/

????public?Object?get(int?i);??


????/*取得集合大小*/

????publicint?size();??

}??

[java]view plaincopy

publicinterface?Iterator?{??

????//前移

????public?Object?previous();??


????//后移

????public?Object?next();??

????publicboolean?hasNext();??


????//取得第一個元素

????public?Object?first();??

}??

兩個實現(xiàn):

[java]view plaincopy

publicclass?MyCollection?implements?Collection?{??


????public?String?string[]?=?{"A","B","C","D","E"};??

????@Override

????public?Iterator?iterator()?{??

????????returnnew?MyIterator(this);??

????}??


????@Override

????public?Object?get(int?i)?{??

????????return?string[i];??

????}??


????@Override

????publicint?size()?{??

????????return?string.length;??

????}??

}??

[java]view plaincopy

publicclass?MyIterator?implements?Iterator?{??


????private?Collection?collection;??

????privateint?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

????????????pos++;??

????????}??

????????return?collection.get(pos);??

????}??


????@Override

????publicboolean?hasNext()?{??

????????if(pos

????????????returntrue;??

????????}else{??

????????????returnfalse;??

????????}??

????}??


????@Override

????public?Object?first()?{??

????????pos?=?0;??

????????return?collection.get(pos);??

????}??


}??

測試類:

[java]view plaincopy

publicclass?Test?{??


????publicstaticvoid?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中各個類也都是這些基本的東西,加一些設計模式项滑,再加一些優(yōu)化放到一起的依沮,只要我們把這些東西學會了,掌握好了枪狂,我們也可以寫出自己的集合類危喉,甚至框架!

17州疾、責任鏈模式(Chain of Responsibility)

接下來我們將要談談責任鏈模式辜限,有多個對象,每個對象持有對下一個對象的引用严蓖,這樣就會形成一條鏈薄嫡,請求在這條鏈上傳遞,直到某一對象決定處理該請求颗胡。但是發(fā)出者并不清楚到底最終那個對象會處理該請求毫深,所以,責任鏈模式可以實現(xiàn)杭措,在隱瞞客戶端的情況下费什,對系統(tǒng)進行動態(tài)的調(diào)整。先看看關系圖:

請點擊此處輸入圖片描述

Abstracthandler類提供了get和set方法手素,方便MyHandle類設置和修改引用對象鸳址,MyHandle類是核心,實例化后生成一系列相互持有的對象泉懦,構成一條鏈稿黍。

[java]view plaincopy

publicinterface?Handler?{??

????publicvoid?operator();??

}??

[java]view plaincopy

publicabstractclass?AbstractHandler?{??


????private?Handler?handler;??


????public?Handler?getHandler()?{??

????????return?handler;??

????}??


????publicvoid?setHandler(Handler?handler)?{??

????????this.handler?=?handler;??

????}??


}??

[java]view plaincopy

publicclass?MyHandler?extends?AbstractHandler?implements?Handler?{??


????private?String?name;??


????public?MyHandler(String?name)?{??

????????this.name?=?name;??

????}??


????@Override

????publicvoid?operator()?{??

????????System.out.println(name+"deal!");??

????????if(getHandler()!=null){??

????????????getHandler().operator();??

????????}??

????}??

}??

[java]view plaincopy

publicclass?Test?{??


????publicstaticvoid?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!

此處強調(diào)一點就是,鏈接上的請求可以是一條鏈崩哩,可以是一個樹巡球,還可以是一個環(huán)言沐,模式本身不約束這個,需要我們自己去實現(xiàn)酣栈,同時险胰,在一個時刻,命令只允許由一個對象傳給另一個對象矿筝,而不允許傳給多個對象起便。

?18、命令模式(Command)

命令模式很好理解窖维,舉個例子榆综,司令員下令讓士兵去干件事情,從整個事情的角度來考慮铸史,司令員的作用是鼻疮,發(fā)出口令,口令經(jīng)過傳遞琳轿,傳到了士兵耳朵里判沟,士兵去執(zhí)行。這個過程好在利赋,三者相互解耦水评,任何一方都不用去依賴其他人,只需要做好自己的事兒就行媚送,司令員要的是結果中燥,不會去關注到底士兵是怎么實現(xiàn)的。我們看看關系圖:

請點擊此處輸入圖片描述

Invoker是調(diào)用者(司令員)塘偎,Receiver是被調(diào)用者(士兵)疗涉,MyCommand是命令,實現(xiàn)了Command接口吟秩,持有接收對象咱扣,看實現(xiàn)代碼:

[java]view plaincopy

publicinterface?Command?{??

????publicvoid?exe();??

}??

[java]view plaincopy

publicclass?MyCommand?implements?Command?{??


????private?Receiver?receiver;??


????public?MyCommand(Receiver?receiver)?{??

????????this.receiver?=?receiver;??

????}??


????@Override

????publicvoid?exe()?{??

????????receiver.action();??

????}??

}??

[java]view plaincopy

publicclass?Receiver?{??

????publicvoid?action(){??

????????System.out.println("command?received!");??

????}??

}??

[java]view plaincopy

publicclass?Invoker?{??


????private?Command?command;??


????public?Invoker(Command?command)?{??

????????this.command?=?command;??

????}??


????publicvoid?action(){??

????????command.exe();??

????}??

}??

[java]view plaincopy

publicclass?Test?{??


????publicstaticvoid?main(String[]?args)?{??

????????Receiver?receiver?=?new?Receiver();??

????????Command?cmd?=?new?MyCommand(receiver);??

????????Invoker?invoker?=?new?Invoker(cmd);??

????????invoker.action();??

????}??

}??

輸出:command received!

這個很哈理解,命令模式的目的就是達到命令的發(fā)出者和執(zhí)行者之間解耦涵防,實現(xiàn)請求和執(zhí)行分開闹伪,熟悉Struts的同學應該知道,Struts其實就是一種將請求和呈現(xiàn)分離的技術壮池,其中必然涉及命令模式的思想偏瓤!

其實每個設計模式都是很重要的一種思想,看上去很熟椰憋,其實是因為我們在學到的東西中都有涉及厅克,盡管有時我們并不知道,其實在Java本身的設計之中處處都有體現(xiàn)橙依,像AWT证舟、JDBC硕旗、集合類彭沼、IO管道或者是Web框架智什,里面設計模式無處不在。因為我們篇幅有限膀曾,很難講每一個設計模式都講的很詳細抵知,不過我會盡我所能浪读,盡量在有限的空間和篇幅內(nèi),把意思寫清楚了辛藻,更好讓大家明白。本章不出意外的話互订,應該是設計模式最后一講了吱肌,首先還是上一下上篇開頭的那個圖:

請點擊此處輸入圖片描述

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

19仰禽、備忘錄模式(Memento)

主要目的是保存一個對象的某個狀態(tài)氮墨,以便在適當?shù)臅r候恢復對象,個人覺得叫備份模式更形象些吐葵,通俗的講下:假設有原始類A规揪,A中有各種屬性,A可以決定需要備份的屬性温峭,備忘錄類B是用來存儲A的一些內(nèi)部狀態(tài)猛铅,類C呢,就是一個用來存儲備忘錄的凤藏,且只能存儲奸忽,不能修改等操作。做個圖來分析一下:

請點擊此處輸入圖片描述

Original類是原始類揖庄,里面有需要保存的屬性value及創(chuàng)建一個備忘錄類栗菜,用來保存value值。Memento類是備忘錄類蹄梢,Storage類是存儲備忘錄的類疙筹,持有Memento類的實例,該模式很好理解禁炒。直接看源碼:

[java]view plaincopy

publicclass?Original?{??


????private?String?value;??


????public?String?getValue()?{??

????????return?value;??

????}??


????publicvoid?setValue(String?value)?{??

????????this.value?=?value;??

????}??


????public?Original(String?value)?{??

????????this.value?=?value;??

????}??


????public?Memento?createMemento(){??

????????returnnew?Memento(value);??

????}??


????publicvoid?restoreMemento(Memento?memento){??

????????this.value?=?memento.getValue();??

????}??

}??

[java]view plaincopy

publicclass?Memento?{??


????private?String?value;??


????public?Memento(String?value)?{??

????????this.value?=?value;??

????}??


????public?String?getValue()?{??

????????return?value;??

????}??


????publicvoid?setValue(String?value)?{??

????????this.value?=?value;??

????}??

}??

[java]view plaincopy

publicclass?Storage?{??


????private?Memento?memento;??


????public?Storage(Memento?memento)?{??

????????this.memento?=?memento;??

????}??


????public?Memento?getMemento()?{??

????????return?memento;??

????}??


????publicvoid?setMemento(Memento?memento)?{??

????????this.memento?=?memento;??

????}??

}??

測試類:

[java]view plaincopy

publicclass?Test?{??


????publicstaticvoid?main(String[]?args)?{??


????????//?創(chuàng)建原始類

????????Original?origi?=?new?Original("egg");??


????????//?創(chuàng)建備忘錄

????????Storage?storage?=?new?Storage(origi.createMemento());??


????????//?修改原始類的狀態(tài)

????????System.out.println("初始化狀態(tài)為:"?+?origi.getValue());??

????????origi.setValue("niu");??

????????System.out.println("修改后的狀態(tài)為:"?+?origi.getValue());??


????????//?回復原始類的狀態(tài)

????????origi.restoreMemento(storage.getMemento());??

????????System.out.println("恢復后的狀態(tài)為:"?+?origi.getValue());??

????}??

}??

輸出:

初始化狀態(tài)為:egg

修改后的狀態(tài)為:niu

恢復后的狀態(tài)為:egg

簡單描述下:新建原始類時而咆,value被初始化為egg,后經(jīng)過修改齐苛,將value的值置為niu翘盖,最后倒數(shù)第二行進行恢復狀態(tài),結果成功恢復了凹蜂。其實我覺得這個模式叫“備份-恢復”模式最形象馍驯。

在此我向大家推薦一個交流學習群:575745314 ?里面會分享一些資深架構師錄制的視頻錄像:有Spring阁危,MyBatis,Netty源碼分析汰瘫,高并發(fā)狂打、高性能、分布式混弥、微服務架構的原理趴乡,JVM性能優(yōu)化這些成為架構師必備的知識體系。還能領取免費的學習資源蝗拿,目前受益良多

20晾捏、狀態(tài)模式(State)

核心思想就是:當對象的狀態(tài)改變時,同時改變其行為哀托,很好理解惦辛!就拿QQ來說,有幾種狀態(tài)仓手,在線胖齐、隱身、忙碌等嗽冒,每個狀態(tài)對應不同的操作呀伙,而且你的好友也能看到你的狀態(tài),所以添坊,狀態(tài)模式就兩點:1剿另、可以通過改變狀態(tài)來獲得不同的行為。2贬蛙、你的好友能同時看到你的變化驰弄。看圖:

請點擊此處輸入圖片描述

State類是個狀態(tài)類速客,Context類可以實現(xiàn)切換戚篙,我們來看看代碼:

[java]view plaincopy

package?com.xtfggef.dp.state;??


/**?

?*?狀態(tài)類的核心類?

?*?2012-12-1?

?*?@author?erqing?

?*?

?*/

publicclass?State?{??


????private?String?value;??


????public?String?getValue()?{??

????????return?value;??

????}??


????publicvoid?setValue(String?value)?{??

????????this.value?=?value;??

????}??


????publicvoid?method1(){??

????????System.out.println("execute?the?first?opt!");??

????}??


????publicvoid?method2(){??

????????System.out.println("execute?the?second?opt!");??

????}??

}??

[java]view plaincopy

package?com.xtfggef.dp.state;??


/**?

?*?狀態(tài)模式的切換類???2012-12-1?

?*?@author?erqing?

?*??

?*/

publicclass?Context?{??


????private?State?state;??


????public?Context(State?state)?{??

????????this.state?=?state;??

????}??


????public?State?getState()?{??

????????return?state;??

????}??


????publicvoid?setState(State?state)?{??

????????this.state?=?state;??

????}??


????publicvoid?method()?{??

????????if?(state.getValue().equals("state1"))?{??

????????????state.method1();??

????????}?elseif?(state.getValue().equals("state2"))?{??

????????????state.method2();??

????????}??

????}??

}??

測試類:

[java]view plaincopy

publicclass?Test?{??


????publicstaticvoid?main(String[]?args)?{??


????????State?state?=?new?State();??

????????Context?context?=?new?Context(state);??


????????//設置第一種狀態(tài)

????????state.setValue("state1");??

????????context.method();??


????????//設置第二種狀態(tài)

????????state.setValue("state2");??

????????context.method();??

????}??

}??

輸出:

execute the first opt!

execute the second opt!

根據(jù)這個特性,狀態(tài)模式在日常開發(fā)中用的挺多的溺职,尤其是做網(wǎng)站的時候岔擂,我們有時希望根據(jù)對象的某一屬性,區(qū)別開他們的一些功能浪耘,比如說簡單的權限控制等乱灵。

21、訪問者模式(Visitor)

訪問者模式把數(shù)據(jù)結構和作用于結構上的操作解耦合七冲,使得操作集合可相對自由地演化痛倚。訪問者模式適用于數(shù)據(jù)結構相對穩(wěn)定算法又易變化的系統(tǒng)。因為訪問者模式使得算法操作增加變得容易澜躺。若系統(tǒng)數(shù)據(jù)結構對象易于變化蝉稳,經(jīng)常有新的數(shù)據(jù)對象增加進來抒蚜,則不適合使用訪問者模式。訪問者模式的優(yōu)點是增加操作很容易耘戚,因為增加操作意味著增加新的訪問者嗡髓。訪問者模式將有關行為集中到一個訪問者對象中,其改變不影響系統(tǒng)數(shù)據(jù)結構收津。其缺點就是增加新的數(shù)據(jù)結構很困難饿这。—— From 百科

簡單來說撞秋,訪問者模式就是一種分離對象數(shù)據(jù)結構與行為的方法长捧,通過這種分離,可達到為一個被訪問者動態(tài)添加新的操作而無需做其它的修改的效果吻贿。簡單關系圖:

請點擊此處輸入圖片描述

來看看原碼:一個Visitor類唆姐,存放要訪問的對象,

[java]view plaincopy

publicinterface?Visitor?{??

????publicvoid?visit(Subject?sub);??

}??

[java]view plaincopy

publicclass?MyVisitor?implements?Visitor?{??


????@Override

????publicvoid?visit(Subject?sub)?{??

????????System.out.println("visit?the?subject:"+sub.getSubject());??

????}??

}??

Subject類廓八,accept方法,接受將要訪問它的對象赵抢,getSubject()獲取將要被訪問的屬性剧蹂,

[java]view plaincopy

publicinterface?Subject?{??

????publicvoid?accept(Visitor?visitor);??

????public?String?getSubject();??

}??

[java]view plaincopy

publicclass?MySubject?implements?Subject?{??


????@Override

????publicvoid?accept(Visitor?visitor)?{??

????????visitor.visit(this);??

????}??


????@Override

????public?String?getSubject()?{??

????????return"love";??

????}??

} ?

測試:

[java]view plaincopy

publicclass?Test?{??


????publicstaticvoid?main(String[]?args)?{??


????????Visitor?visitor?=?new?MyVisitor();??

????????Subject?sub?=?new?MySubject();??

????????sub.accept(visitor);??????

????}??

}??

輸出:visit the subject:love

該模式適用場景:如果我們想為一個現(xiàn)有的類增加新功能,不得不考慮幾個事情:1烦却、新功能會不會與現(xiàn)有功能出現(xiàn)兼容性問題宠叼?2、以后會不會再需要添加其爵?3冒冬、如果類不允許修改代碼怎么辦?面對這些問題摩渺,最好的解決方法就是使用訪問者模式简烤,訪問者模式適用于數(shù)據(jù)結構相對穩(wěn)定的系統(tǒng),把數(shù)據(jù)結構和算法解耦摇幻,

22横侦、中介者模式(Mediator)

中介者模式也是用來降低類類之間的耦合的,因為如果類類之間有依賴關系的話绰姻,不利于功能的拓展和維護枉侧,因為只要修改一個對象,其它關聯(lián)的對象都得進行修改狂芋。如果使用中介者模式榨馁,只需關心和Mediator類的關系,具體類類之間的關系及調(diào)度交給Mediator就行帜矾,這有點像spring容器的作用翼虫。先看看圖:

請點擊此處輸入圖片描述

User類統(tǒng)一接口屑柔,User1和User2分別是不同的對象,二者之間有關聯(lián)蛙讥,如果不采用中介者模式锯蛀,則需要二者相互持有引用,這樣二者的耦合度很高次慢,為了解耦旁涤,引入了Mediator類,提供統(tǒng)一接口迫像,MyMediator為其實現(xiàn)類劈愚,里面持有User1和User2的實例,用來實現(xiàn)對User1和User2的控制闻妓。這樣User1和User2兩個對象相互獨立菌羽,他們只需要保持好和Mediator之間的關系就行,剩下的全由MyMediator類來維護由缆!基本實現(xiàn):

[java]view plaincopy

publicinterface?Mediator?{??

????publicvoid?createMediator();??

????publicvoid?workAll();??

}??

[java]view plaincopy

publicclass?MyMediator?implements?Mediator?{??


????private?User?user1;??

????private?User?user2;??


????public?User?getUser1()?{??

????????return?user1;??

????}??


????public?User?getUser2()?{??

????????return?user2;??

????}??


????@Override

????publicvoid?createMediator()?{??

????????user1?=?new?User1(this);??

????????user2?=?new?User2(this);??

????}??


????@Override

????publicvoid?workAll()?{??

????????user1.work();??

????????user2.work();??

????}??

}??

[java]view plaincopy

publicabstractclass?User?{??


????private?Mediator?mediator;??


????public?Mediator?getMediator(){??

????????return?mediator;??

????}??


????public?User(Mediator?mediator)?{??

????????this.mediator?=?mediator;??

????}??


????publicabstractvoid?work();??

}??

[java]view plaincopy

publicclass?User1?extends?User?{??


????public?User1(Mediator?mediator){??

????????super(mediator);??

????}??


????@Override

????publicvoid?work()?{??

????????System.out.println("user1?exe!");??

????}??

}??

[java]view plaincopy

publicclass?User2?extends?User?{??


????public?User2(Mediator?mediator){??

????????super(mediator);??

????}??


????@Override

????publicvoid?work()?{??

????????System.out.println("user2?exe!");??

????}??

}??

測試類:

[java]view plaincopy

publicclass?Test?{??


????publicstaticvoid?main(String[]?args)?{??

????????Mediator?mediator?=?new?MyMediator();??

????????mediator.createMediator();??

????????mediator.workAll();??

????}??

}??

輸出:

user1 exe!

user2 exe!

23注祖、解釋器模式(Interpreter)

解釋器模式是我們暫時的最后一講,一般主要應用在OOP開發(fā)中的編譯器的開發(fā)中均唉,所以適用面比較窄是晨。

請點擊此處輸入圖片描述

Context類是一個上下文環(huán)境類,Plus和Minus分別是用來計算的實現(xiàn)舔箭,代碼如下:

[java]view plaincopy

publicinterface?Expression?{??

????publicint?interpret(Context?context);??

}??

[java]view plaincopy

publicclass?Plus?implements?Expression?{??


????@Override

????publicint?interpret(Context?context)?{??

????????return?context.getNum1()+context.getNum2();??

????}??

}??

[java]view plaincopy

publicclass?Minus?implements?Expression?{??


????@Override

????publicint?interpret(Context?context)?{??

????????return?context.getNum1()-context.getNum2();??

????}??

}??

[java]view plaincopy

publicclass?Context?{??


????privateint?num1;??

????privateint?num2;??


????public?Context(int?num1,?int?num2)?{??

????????this.num1?=?num1;??

????????this.num2?=?num2;??

????}??


????publicint?getNum1()?{??

????????return?num1;??

????}??

????publicvoid?setNum1(int?num1)?{??

????????this.num1?=?num1;??

????}??

????publicint?getNum2()?{??

????????return?num2;??

????}??

????publicvoid?setNum2(int?num2)?{??

????????this.num2?=?num2;??

????}??



}??

[java]view plaincopy

publicclass?Test?{??


????publicstaticvoid?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種設計模式做全面的闡述戳表,此處讀者可將它作為一個理論基礎去學習焰薄。通過這篇博文,先基本有個概念扒袖,雖然我講的有些簡單塞茅,但基本都能說明問題及他們的特點,如果對哪一個感興趣季率,可以繼續(xù)深入研究野瘦!同時我也會不斷更新,盡量補全遺漏、修正不足鞭光,歡迎廣大讀者及時提出好的建議吏廉。

最后編輯于
?著作權歸作者所有,轉載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市惰许,隨后出現(xiàn)的幾起案子席覆,更是在濱河造成了極大的恐慌,老刑警劉巖汹买,帶你破解...
    沈念sama閱讀 207,113評論 6 481
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件佩伤,死亡現(xiàn)場離奇詭異,居然都是意外死亡晦毙,警方通過查閱死者的電腦和手機生巡,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 88,644評論 2 381
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來见妒,“玉大人孤荣,你說我怎么就攤上這事⌒氪В” “怎么了盐股?”我有些...
    開封第一講書人閱讀 153,340評論 0 344
  • 文/不壞的土叔 我叫張陵,是天一觀的道長耻卡。 經(jīng)常有香客問我疯汁,道長,這世上最難降的妖魔是什么劲赠? 我笑而不...
    開封第一講書人閱讀 55,449評論 1 279
  • 正文 為了忘掉前任,我火速辦了婚禮秸谢,結果婚禮上凛澎,老公的妹妹穿的比我還像新娘。我一直安慰自己估蹄,他們只是感情好塑煎,可當我...
    茶點故事閱讀 64,445評論 5 374
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著臭蚁,像睡著了一般最铁。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上垮兑,一...
    開封第一講書人閱讀 49,166評論 1 284
  • 那天冷尉,我揣著相機與錄音,去河邊找鬼系枪。 笑死雀哨,一個胖子當著我的面吹牛,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播雾棺,決...
    沈念sama閱讀 38,442評論 3 401
  • 文/蒼蘭香墨 我猛地睜開眼膊夹,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了捌浩?” 一聲冷哼從身側響起放刨,我...
    開封第一講書人閱讀 37,105評論 0 261
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎尸饺,沒想到半個月后进统,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 43,601評論 1 300
  • 正文 獨居荒郊野嶺守林人離奇死亡侵佃,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 36,066評論 2 325
  • 正文 我和宋清朗相戀三年麻昼,在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片馋辈。...
    茶點故事閱讀 38,161評論 1 334
  • 序言:一個原本活蹦亂跳的男人離奇死亡抚芦,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出迈螟,到底是詐尸還是另有隱情叉抡,我是刑警寧澤,帶...
    沈念sama閱讀 33,792評論 4 323
  • 正文 年R本政府宣布答毫,位于F島的核電站褥民,受9級特大地震影響,放射性物質發(fā)生泄漏洗搂。R本人自食惡果不足惜消返,卻給世界環(huán)境...
    茶點故事閱讀 39,351評論 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望耘拇。 院中可真熱鬧撵颊,春花似錦、人聲如沸惫叛。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,352評論 0 19
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽嘉涌。三九已至妻熊,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間仑最,已是汗流浹背扔役。 一陣腳步聲響...
    開封第一講書人閱讀 31,584評論 1 261
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留警医,地道東北人厅目。 一個月前我還...
    沈念sama閱讀 45,618評論 2 355
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親损敷。 傳聞我的和親對象是個殘疾皇子葫笼,可洞房花燭夜當晚...
    茶點故事閱讀 42,916評論 2 344

推薦閱讀更多精彩內(nèi)容

  • 一、設計模式的分類 總體來說設計模式分為三大類: 創(chuàng)建型模式拗馒,共五種:工廠方法模式路星、抽象工廠模式、單例模式诱桂、建造者...
    RamboLI閱讀 744評論 0 1
  • 原文鏈接:http://blog.csdn.net/zhangerqing http://www.cnblogs....
    孤獨雜貨鋪閱讀 1,508評論 0 3
  • 文章部分內(nèi)容轉載自:http://blog.csdn.net/zhangerqing 一洋丐、設計模式的分類 總體來說...
    j_cong閱讀 2,058評論 0 20
  • 一、設計模式的分類 總體來說設計模式分為三大類: 創(chuàng)建型模式挥等,共五種:工廠方法模式友绝、抽象工廠模式、單例模式肝劲、建造者...
    lichengjin閱讀 887評論 0 8
  • 1. 停暖了迁客。 天氣也暖了。 已經(jīng)可以穿薄外套出門也不用擦鼻涕辞槐。 光屁股睡覺一點不覺得冷掷漱。 呵呵呵呵呵呵呵呵呵呵。...
    你要做個好人閱讀 206評論 0 0