Java開發中的23種設計模式詳解(轉)
設計模式(Design Patterns)
——可複用物件導向軟體的基礎
設計模式(Design pattern)是一套被反覆使用、多數人知曉的、經過分類編目的、程式碼設計經驗的總結。使用設計模式是為了可重用程式碼、讓程式碼更容易被他人理解、保證程式碼可靠性。 毫無疑問,設計模式於己於他人於系統都是多贏的,設計模式使程式碼編制真正工程化,設計模式是軟體工程的基石,如同大廈的一塊塊磚石一樣。專案中合理的運用設計模式可以完美的解決很多問題,每種模式在現在中都有相應的原理來與之對應,每一個模式描述了一個在我們周圍不斷重複發生的問題,以及該問題的核心解決方案,這也是它能被廣泛應用的原因。本章系Java之美[從菜鳥到高手演變]系列之設計模式,我們會以理論與實踐相結合的方式來進行本章的學習,希望廣大程式愛好者,學好設計模式,做一個優秀的軟體工程師!
企業級專案實戰(帶原始碼)地址:http://zz563143188.iteye.com/blog/1825168
一、設計模式的分類
總體來說設計模式分為三大類:
建立型模式,共五種:工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式。
結構型模式,共七種:介面卡模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。
行為型模式,共十一種:策略模式、模板方法模式、觀察者模式、迭代子模式、責任鏈模式、命令模式、備忘錄模式、狀態模式、訪問者模式、中介者模式、直譯器模式。
其實還有兩類:併發型模式和執行緒池模式。用一個圖片來整體描述一下:
二、設計模式的六大原則
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、普通工廠模式,就是建立一個工廠類,對實現了同一介面的一些類進行例項的建立。首先看下關係圖:
舉例如下:(我們舉一個傳送郵件和簡訊的例子)
首先,建立二者的共同介面:
- public interface Sender {
- public void Send();
- }
其次,建立實現類:
- public class MailSender implements Sender {
- @Override
- public void Send() {
- System.out.println("this is mailsender!");
- }
- }
- public class SmsSender implements Sender {
- @Override
- public void Send() {
- System.out.println("this is sms sender!");
- }
- }
最後,建工廠類:
- 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類就行,如下:
- return new MailSender();
- }
- public Sender produceSms(){
- return new SmsSender();
- }
- }
測試類如下:
- public class FactoryTest {
- public static void main(String[] args) {
- SendFactory factory = new SendFactory();
- Sender sender = factory.produceMail();
- sender.Send();
- }
- }
輸出:this is mailsender!
33、靜態工廠方法模式,將上面的多個工廠方法模式裡的方法置為靜態的,不需要建立例項,直接呼叫即可。
- public class SendFactory {
- public static Sender produceMail(){
- return new MailSender();
- }
- public static Sender produceSms(){
- return new SmsSender();
- }
- }
- public class FactoryTest {
- public static void main(String[] args) {
- Sender sender = SendFactory.produceMail();
- sender.Send();
- }
- }
輸出:this is mailsender!
總體來說,工廠模式適合:凡是出現了大量的產品需要建立,並且具有共同的介面時,可以通過工廠方法模式進行建立。在以上的三種模式中,第一種如果傳入的字串有誤,不能正確建立物件,第三種相對於第二種,不需要例項化工廠類,所以,大多數情況下,我們會選用第三種——靜態工廠方法模式。
2、抽象工廠模式(Abstract Factory)
工廠方法模式有一個問題就是,類的建立依賴工廠類,也就是說,如果想要擴充程式,必須對工廠類進行修改,這違背了閉包原則,所以,從設計角度考慮,有一定的問題,如何解決?就用到抽象工廠模式,建立多個工廠類,這樣一旦需要增加新的功能,直接增加新的工廠類就可以了,不需要修改之前的程式碼。因為抽象工廠不太好理解,我們先看看圖,然後就和程式碼,就比較容易理解。
請看例子:
- public interface Sender {
- public void Send();
- }
兩個實現類:
- public class MailSender implements Sender {
- @Override
- public void Send() {
- System.out.println("this is mailsender!");
- }
- }
- public class SmsSender implements Sender {
- @Override
- public void Send() {
- System.out.println("this is sms sender!");
- }
- }
兩個工廠類:
- public class SendMailFactory implements Provider {
- @Override
- public Sender produce(){
- return new MailSender();
- }
- }
- public class SendSmsFactory implements Provider{
- @Override
- public Sender produce() {
- return new SmsSender();
- }
- }
在提供一個介面:
- public interface Provider {
- public Sender produce();
- }
測試類:
- 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、有些類如交易所的核心交易引擎,控制著交易流程,如果該類可以建立多個的話,系統完全亂了。(比如一個軍隊出現了多個司令員同時指揮,肯定會亂成一團),所以只有使用單例模式,才能保證核心交易伺服器獨立控制整個流程。
首先我們寫一個簡單的單例類:
- 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;
- }
- }
這個類可以滿足基本要求,但是,像這樣毫無執行緒安全保護的類,如果我們把它放入多執行緒的環境下,肯定就會出現問題了,如何解決?我們首先會想到對getInstance方法加synchronized關鍵字,如下:
- public static synchronized Singleton getInstance() {
- if (instance == null) {
- instance = new Singleton();
- }
- return instance;
- }
但是,synchronized關鍵字鎖住的是這個物件,這樣的用法,在效能上會有所下降,因為每次呼叫getInstance(),都要對物件上鎖,事實上,只有在第一次建立物件的時候需要加鎖,之後就不需要了,所以,這個地方需要改進。我們改成下面這個:
- 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例項,卻發現它沒有被初始化,於是錯誤發生了。
所以程式還是有可能發生錯誤,其實程式在執行過程是很複雜的,從這點我們就可以看出,尤其是在寫多執行緒環境下的程式更有難度,有挑戰性。我們對該程式做進一步優化:
- private static class SingletonFactory{
- private static Singleton instance = new Singleton();
- }
- public static Singleton getInstance(){
- return SingletonFactory.instance;
- }
實際情況是,單例模式使用內部類來維護單例的實現,JVM內部的機制能夠保證當一個類被載入的時候,這個類的載入過程是執行緒互斥的。這樣當我們第一次呼叫getInstance的時候,JVM能夠幫我們保證instance只被建立一次,並且會保證把賦值給instance的記憶體初始化完畢,這樣我們就不用擔心上面的問題。同時該方法也只會在第一次呼叫的時候使用互斥機制,這樣就解決了低效能問題。這樣我們暫時總結一個完美的單例模式:
- 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關鍵字,也是可以的:
- 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;
- }
- }
考慮效能的話,整個程式只需建立一次例項,所以效能也不會有什麼影響。
補充:採用"影子例項"的辦法為單例物件的屬性同步更新
- 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。最後,建造者類如下:
- 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());
- }
- }
- }
測試類:
- public class Test {
- public static void main(String[] args) {
- Builder builder = new Builder();
- builder.produceMailSender(10);
- }
- }
從這點看出,建造者模式將很多功能整合到一個類裡,這個類可以創造出比較複雜的東西。所以與工程模式的區別就是:工廠模式關注的是建立單個產品,而建造者模式則關注建立符合物件,多個部分。因此,是選擇工廠模式還是建造者模式,依實際情況而定。
5、原型模式(Prototype)
原型模式雖然是建立型的模式,但是與工程模式沒有關係,從名字即可看出,該模式的思想就是將一個物件作為原型,對其進行復制、克隆,產生一個和原物件類似的新物件。本小結會通過物件的複製,進行講解。在Java中,複製物件是通過clone()實現的,先建立一個原型類:
- 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中本地方法的呼叫,此處不再深究。在這兒,我將結合物件的淺複製和深複製來說一下,首先需要了解物件深、淺複製的概念:
淺複製:將一個物件複製後,基本資料型別的變數都會重新建立,而引用型別,指向的還是原物件所指向的。
深複製:將一個物件複製後,不論是基本資料型別還有引用型別,都是重新建立的。簡單來說,就是深複製進行了完全徹底的複製,而淺複製不徹底。
此處,寫一個深淺複製的例子:
- 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裡,看程式碼:
- public class Source {
- public void method1() {
- System.out.println("this is original method!");
- }
- }
- public interface Targetable {
- /* 與原類中的方法相同 */
- public void method1();
- /* 新類的方法 */
- public void method2();
- }
- public class Adapter extends Source implements Targetable {
- @Override
- public void method2() {
- System.out.println("this is the targetable method!");
- }
- }
Adapter類繼承Source類,實現Targetable介面,下面是測試類:
- 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類的原始碼即可:
- 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();
- }
- }
測試類:
- public class AdapterTest {
- public static void main(String[] args) {
- Source source = new Source();
- Targetable target = new Wrapper(source);
- target.method1();
- target.method2();
- }
- }
輸出與第一種一樣,只是適配的方法不同而已。
第三種介面卡模式是介面的介面卡模式,介面的介面卡是這樣的:有時我們寫的一個介面中有多個抽象方法,當我們寫該介面的實現類時,必須實現該介面的所有方法,這明顯有時比較浪費,因為並不是所有的方法都是我們需要的,有時只需要某一些,此處為了解決這個問題,我們引入了介面的介面卡模式,藉助於一個抽象類,該抽象類實現了該介面,實現了所有的方法,而我們不和原始的介面打交道,只和該抽象類取得聯絡,所以我們寫一個類,繼承該抽象類,重寫我們需要的方法就行。看一下類圖:
這個很好理解,在實際開發中,我們也常會遇到這種介面中定義了太多的方法,以致於有時我們在一些實現類中並不是都需要。看程式碼:
- public interface Sourceable {
- public void method1();
- public void method2();
- }
抽象類Wrapper2:
- public abstract class Wrapper2 implements Sourceable{
- public void method1(){}
- public void method2(){}
- }
- public class SourceSub1 extends Wrapper2 {
- public void method1(){
- System.out.println("the sourceable interface's first Sub1!");
- }
- }
- public class SourceSub2 extends Wrapper2 {
- public void method2(){
- System.out.println("the sourceable interface's second Sub2!");
- }
- }
- 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類動態的新增一些功能,程式碼如下:
- public interface Sourceable {
- public void method();
- }
- public class Source implements Sourceable {
- @Override
- public void method() {
- System.out.println("the original method!");
- }
- }
- 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!");
- }
- }
測試類:
- 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)
其實每個模式名稱就表明了該模式的作用,代理模式就是多一個代理類出來,替原物件進行一些操作,比如我們在租房子的時候回去找中介,為什麼呢?因為你對該地區房屋的資訊掌握的不夠全面,希望找一個更熟悉的人去幫你做,此處的代理就是這個意思。再如我們有的時候打官司,我們需要請律師,因為律師在法律方面有專長,可以替我們進行操作,表達我們的想法。先來看看關係圖:
根據上文的闡述,代理模式就比較容易的理解了,我們看下程式碼:
- public interface Sourceable {
- public void method();
- }
- public class Source implements Sourceable {
- @Override
- public void method() {
- System.out.println("the original method!");
- }
- }
- 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!");
- }
- }
測試類:
- public class ProxyTest {
- public static void main(String[] args) {
- Sourceable source = new Proxy();
- source.method();
- }
- }
輸出:
before proxy!
the original method!
after proxy!
代理模式的應用場景:
如果已有的方法在使用的時候需要對原有的方法進行改進,此時有兩種辦法:
1、修改原有的方法來適應。這樣違反了“對擴充套件開放,對修改關閉”的原則。
2、就是採用一個代理類呼叫原有的方法,且對產生的結果進行控制。這種方法就是代理模式。
使用代理模式,可以將功能劃分的更加清晰,有助於後期維護!
9、外觀模式(Facade)
外觀模式是為了解決類與類之家的依賴關係的,像spring一樣,可以將類和類之間的關係配置到配置檔案中,而外觀模式就是將他們的關係放在一個Facade類中,降低了類類之間的耦合度,該模式中沒有涉及到介面,看下類圖:(我們以一個計算機的啟動過程為例)
我們先看下實現類:
- public class CPU {
- public void startup(){
- System.out.println("cpu startup!");
- }
- public void shutdown(){
- System.out.println("cpu shutdown!");
- }
- }
- public class Memory {
- public void startup(){
- System.out.println("memory startup!");
- }
- public void shutdown(){
- System.out.println("memory shutdown!");
- }
- }
- public class Disk {
- public void startup(){
- System.out.println("disk startup!");
- }
- public void shutdown(){
- System.out.println("disk shutdown!");
- }
- }
- 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類如下:
- 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提供統一介面,每個資料庫提供各自的實現,用一個叫做資料庫驅動的程式來橋接就行了。我們來看看關係圖:
實現程式碼:
先定義介面:
- public interface Sourceable {
- public void method();
- }
分別定義兩個實現類:
- public class SourceSub1 implements Sourceable {
- @Override
- public void method() {
- System.out.println("this is the first sub!");
- }
- }
- public class SourceSub2 implements Sourceable {
- @Override
- public void method() {
- System.out.println("this is the second sub!");
- }
- }
定義一個橋,持有Sourceable的一個例項:
- 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;
- }
- }
- public class MyBridge extends Bridge {
- public void method(){
- getSource().method();
- }
- }
測試類:
- 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)
組合模式有時又叫部分-整體模式在處理類似樹形結構的問題時比較方便,看看關係圖:
直接來看程式碼:
- 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();
- }
- }
- 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)
享元模式的主要目的是實現物件的共享,即共享池,當系統中物件多的時候可以減少記憶體的開銷,通常與工廠模式一起使用。
FlyWeightFactory負責建立和管理享元單元,當一個客戶端請求時,工廠需要檢查當前物件池中是否有符合條件的物件,如果有,就返回已經存在的物件,如果沒有,則建立一個新物件,FlyWeight是超類。一提到共享池,我們很容易聯想到Java裡面的JDBC連線池,想想每個連線的特點,我們不難總結出:適用於作共享的一些個物件,他們有一些共有的屬性,就拿資料庫連線池來說,url、driverClassName、username、password及dbname,這些屬性對於每個連線來說都是一樣的,所以就適合用享元模式來處理,建一個工廠類,將上述類似屬性作為內部資料,其它的作為外部資料,在方法呼叫時,當做引數傳進來,這樣就節省了空間,減少了例項的數量。
看個例子:
看下資料庫連線池的程式碼:
- 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;
- }
- }
- }
本章是關於設計模式的最後一講,會講到第三種設計模式——行為型模式,共11種:策略模式、模板方法模式、觀察者模式、迭代子模式、責任鏈模式、命令模式、備忘錄模式、狀態模式、訪問者模式、中介者模式、直譯器模式。這段時間一直在寫關於設計模式的東西,終於寫到一半了,寫博文是個很費時間的東西,因為我得為讀者負責,不論是圖還是程式碼還是表述,都希望能儘量寫清楚,以便讀者理解,我想不論是我還是讀者,都希望看到高質量的博文出來,從我本人出發,我會一直堅持下去,不斷更新,源源動力來自於讀者朋友們的不斷支援,我會盡自己的努力,寫好每一篇文章!希望大家能不斷給出意見和建議,共同打造完美的博文!
先來張圖,看看這11中模式的關係:
第一類:通過父類與子類的關係進行實現。第二類:兩個類之間。第三類:類的狀態。第四類:通過中間類
13、策略模式(strategy)
策略模式定義了一系列演算法,並將每個演算法封裝起來,使他們可以相互替換,且演算法的變化不會影響到使用演算法的客戶。需要設計一個介面,為一系列實現類提供統一的方法,多個實現類實現該介面,設計一個抽象類(可有可無,屬於輔助類),提供輔助函式,關係圖如下:
圖中ICalculator提供同意的方法,
AbstractCalculator是輔助類,提供輔助方法,接下來,依次實現下每個類:
首先統一介面:
- public interface ICalculator {
- public int calculate(String exp);
- }
輔助類:
- 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;
- }
- }
三個實現類:
- public class Plus extends AbstractCalculator implements ICalculator {
- @Override
- public int calculate(String exp) {
- int arrayInt[] = split(exp,"\\+");
- return arrayInt[0]+arrayInt[1];
- }
- }
- public class Minus extends AbstractCalculator implements ICalculator {
- @Override
- public int calculate(String exp) {
- int arrayInt[] = split(exp,"-");
- return arrayInt[0]-arrayInt[1];
- }
- }
- public class Multiply extends AbstractCalculator implements ICalculator {
- @Override
- public int calculate(String exp) {
- int arrayInt[] = split(exp,"\\*");
- return arrayInt[0]*arrayInt[1];
- }
- }
簡單的測試類:
- 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的呼叫實現對子類的呼叫,看下面的例子:
- 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;
- }
- }
- public class Plus extends AbstractCalculator {
- @Override
- public int calculate(int num1,int num2) {
- return num1 + num2;
- }
- }
測試類:
- 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介面:
- public interface Observer {
- public void update();
- }
兩個實現類:
- public class Observer1 implements Observer {
- @Override
- public void update() {
- System.out.println("observer1 has received!");
- }
- }
- public class Observer2 implements Observer {
- @Override
- public void update() {
- System.out.println("observer2 has received!");
- }
- }
Subject介面及實現類:
- public interface Subject {
- /*增加觀察者*/
- public void add(Observer observer);
- /*刪除觀察者*/
- public void del(Observer observer);
- /*通知所有的觀察者*/
- public void notifyObservers();
- /*自身的操作*/
- public void operation();
- }
- 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();
- }
- }
- }
- public class MySubject extends AbstractSubject {
- @Override
- public void operation() {
- System.out.println("update self!");
- notifyObservers();
- }
- }
測試類:
- 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例項,我們來看看實現程式碼:
兩個介面:
- public interface Collection {
- public Iterator iterator();
- /*取得集合元素*/
- public Object get(int i);
- /*取得集合大小*/
- public int size();
- }
- public interface Iterator {
- //前移
- public Object previous();
- //後移
- public Object next();
- public boolean hasNext();
- //取得第一個元素
- public Object first();
- }
兩個實現:
- 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;
- }
- }
- 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);
- }
- }
測試類:
- 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類是核心,例項化後生成一系列相互持有的物件,構成一條鏈。
- public interface Handler {
- public void operator();
- }
- public abstract class AbstractHandler {
- private Handler handler;
- public Handler getHandler() {
- return handler;
- }
- public void setHandler(Handler handler) {
- this.handler = handler;
- }
- }
- 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();
- }
- }
- }
- 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介面,持有接收物件,看實現程式碼:
- public interface Command {
- public void exe();
- }
- public class MyCommand implements Command {
- private Receiver receiver;
- public MyCommand(Receiver receiver) {
- this.receiver = receiver;
- }
- @Override
- public void exe() {
- receiver.action();
- }
- }
- public class Receiver {
- public void action(){
- System.out.println("command received!");
- }
- }
- public class Invoker {
- private Command command;
- public Invoker(Command command) {
- this.command = command;
- }
- public void action(){
- command.exe();
- }
- }
- 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類的例項,該模式很好理解。直接看原始碼:
- 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();
- }
- }
- 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;
- }
- }
- 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;
- }
- }
測試類:
- 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類可以實現切換,我們來看看程式碼:
- 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!");
- }
- }
- 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();
- }
- }
- }
- 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類,存放要訪問的物件,
- public interface Visitor {
- public void visit(Subject sub);
- }
- public class MyVisitor implements Visitor {
- @Override
- public void visit(Subject sub) {
- System.out.println("visit the subject:"+sub.getSubject());
- }
- }
- public interface Subject {
- public void accept(Visitor visitor);
- public String getSubject();
- }
- public class MySubject implements Subject {
- @Override
- public void accept(Visitor visitor) {
- visitor.visit(this);
- }
- @Override
- public String getSubject() {
- return "love";
- }
- }
- public class Test {
- public static void main(String[] args) {
- Visitor visitor = new MyVisitor();
- Subject sub = new MySubject();
- sub.accept(visitor);
- }
- }
該模式適用場景:如果我們想為一個現有的類增加新功能,不得不考慮幾個事情:1、新功能會不會與現有功能出現相容性問題?2、以後會不會再需要新增?3、如果類不允許修改程式碼怎麼辦?面對這些問題,最好的解決方法就是使用訪問者模式,訪問者模式適用於資料結構相對穩定的系統,把資料結構和演算法解耦,
22、中介者模式(Mediator)
中介者模式也是用來降低類類之間的耦合的,因為如果類類之間有依賴關係的話,不利於功能的擴充和維護,因為只要修改一個物件,其它關聯的物件都得進行修改。如果使用中介者模式,只需關心和Mediator類的關係,具體類類之間的關係及排程交給Mediator就行,這有點像spring容器的作用。先看看圖:
User類統一介面,User1和User2分別是不同的物件,二者之間有關聯,如果不採用中介者模式,則需要二者相互持有引用,這樣二者的耦合度很高,為了解耦,引入了Mediator類,提供統一介面,MyMediator為其實現類,裡面持有User1和User2的例項,用來實現對User1和User2的控制。這樣User1和User2兩個物件相互獨立,他們只需要保持好和Mediator之間的關係就行,剩下的全由MyMediator類來維護!基本實現:
- public interface Mediator {
- public void createMediator();
- public void workAll();
- }
- 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();
- }
- }
- public abstract class User {
- private Mediator mediator;
- public Mediator getMediator(){
- return mediator;
- }
- public User(Mediator mediator) {
- this.mediator = mediator;
- }
- public abstract void work();
- }
- public class User1 extends User {
- public User1(Mediator mediator){
- super(mediator);
- }
- @Override
- public void work() {
- System.out.println("user1 exe!");
- }
- }
- public class User2 extends User {
- public User2(Mediator mediator){
- super(mediator);
- }
- @Override
- public void work() {
- System.out.println("user2 exe!");
- }
- }
- 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分別是用來計算的實現,程式碼如下:
- public interface Expression {
- public int interpret(Context context);
- }
- public class Plus implements Expression {
- @Override
- public int interpret(Context context) {
- return context.getNum1()+context.getNum2();
- }
- }
- public class Minus implements Expression {
- @Override
- public int interpret(Context context) {
- return context.getNum1()-context.getNum2();
- }
- }
- 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;
- }
- }
- 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);
- }
- }
基本就這樣,直譯器模式用來做各種各樣的直譯器,如正規表示式等的直譯器等等!
資源:http://download.csdn.net/detail/zhangerqing/4835830
原文連結:http://blog.csdn.net/zhangerqing
相關文章
- Java開發中的23種設計模式詳解之一:5種建立型模式Java設計模式
- Java開發中的23種設計模式Java設計模式
- Java開發中的23種設計模式詳解之二:7種結構型模式Java設計模式
- Java開發中的23種設計模式詳解之三:11種行為型模式Java設計模式
- 圖文詳解23種設計模式設計模式
- 詳細講解23種設計模式設計模式
- Java中的設計模式詳解Java設計模式
- java 23種設計模式 /Java設計模式
- 23種java設計模式Java設計模式
- java中23種設計模式--原型模式(Portotype)Java設計模式原型
- iOS開發中的21種設計模式iOS設計模式
- 詳解 Java 中的三種代理模式Java模式
- 追MM與Java的23種設計模式Java設計模式
- 四種設計模式詳解設計模式
- java 23種設計模式 深入理解Java設計模式
- 【圖解設計模式系列】23句話總結23種設計模式圖解設計模式
- java23種設計模式—— 二、單例模式Java設計模式單例
- java23種設計模式——三、工廠模式Java設計模式
- java23種設計模式——四、原型模式Java設計模式原型
- java23種設計模式——五、建造者模式Java設計模式
- java23種設計模式——八、組合模式Java設計模式
- 23種設計模式設計模式
- 詳解Java 容器(第②篇)——容器中的設計模式Java設計模式
- PHP 中的設計模式詳解PHP設計模式
- java23種設計模式-門面模式(外觀模式)Java設計模式
- java23中設計模式–代理模式ProxyJava設計模式
- java23中設計模式--代理模式ProxyJava設計模式
- Java23種設計模式【22】----》觀察者模式(Observer)Java設計模式Server
- java23種設計模式——六、介面卡模式Java設計模式
- java23種設計模式之抽象工廠模式Java設計模式抽象
- 關於23種設計模式的有趣見解設計模式
- 關於 23 種設計模式的有趣見解設計模式
- Java設計模式之策略模式詳解Java設計模式
- 23種設計模式(二)---策略設計模式設計模式
- 23種設計模式(八)-原型設計模式設計模式原型
- Java中23種設計模式:六大設計原則的分析與介紹Java設計模式
- 一張圖快速瞭解23種設計模式設計模式
- 23種設計模式(四)-代理模式設計模式