java中設計模式詳解

時間 2019-11-08

標籤 java 設計模式詳解欄目 Java 简体版

原文原文鏈接

1、設計模式的分類html

整體來講設計模式分爲三大類：java

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

（2）結構型模式，共七種：適配器模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。git

（3）行爲型模式，共十一種：策略模式、模板方法模式、觀察者模式、迭代子模式、責任鏈模式、命令模式、備忘錄模式、狀態模式、訪問者模式、中介者模式、解釋器模式。github

其實還有兩類：併發型模式和線程池模式。用一個圖片來總體描述一下：數據庫

2、設計模式的六大原則編程

一、開閉原則（Open Close Principle）設計模式

開閉原則就是說對擴展開放，對修改關閉。在程序須要進行拓展的時候，不能去修改原有的代碼，實現一個熱插拔的效果。因此一句話歸納就是：爲了使程序的擴展性好，易於維護和升級。想要達到這樣的效果，咱們須要使用接口和抽象類，後面的具體設計中咱們會提到這點。數組

二、里氏代換原則（Liskov Substitution Principle）安全

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

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

這個是開閉原則的基礎，具體內容：真對接口編程，依賴於抽象而不依賴於具體。

四、接口隔離原則（Interface Segregation Principle）

這個原則的意思是：使用多個隔離的接口，比使用單個接口要好。仍是一個下降類之間的耦合度的意思，從這兒咱們看出，其實設計模式就是一個軟件的設計思想，從大型軟件架構出發，爲了升級和維護方便。因此上文中屢次出現：下降依賴，下降耦合。

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

爲何叫最少知道原則，就是說：一個實體應當儘可能少的與其餘實體之間發生相互做用，使得系統功能模塊相對獨立。

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

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

3、Java的23中設計模式

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

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

工廠方法模式分爲如下三種：

（1）、普通工廠模式

就是創建一個工廠類，對實現了同一接口的一些類進行實例的建立。首先看下關係圖：

舉例以下：（咱們舉一個發送郵件和短信的例子）

首先，建立兩者的共同接口：

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!

(2)多個工廠方法模式

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

將上面的代碼作下修改，改動下SendFactory類就行，以下：

  public Sender produceMail(){  

            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!

（3）靜態工廠方法模式

將上面的多個工廠方法模式裏的方法置爲靜態的，不須要建立實例，直接調用便可。

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!

整體來講，工廠模式適合：凡是出現了大量的產品須要建立，而且具備共同的接口時，能夠經過工廠方法模式進行建立。在以上的三種模式中，第一種若是傳入的字符串有誤，不能正確建立對象，第三種相對於第二種，不須要實例化工廠類，因此，大多數狀況下，咱們會選用第三種——靜態工廠方法模式。

二、抽象工廠模式（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了，無需去改動現成的代碼。這樣作，拓展性較好！

三、單例模式（Singleton）

單例模式是設計模式中最多見也最簡單的一種設計模式，保證了在程序中只有一個實例存在而且能全局的訪問到。好比在Android實際APP 開發中用到的帳號信息對象管理，數據庫對象（SQLiteOpenHelper）等都會用到單例模式。這樣的模式有幾個好處：

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

二、省去了new操做符，下降了系統內存的使用頻率，減輕GC壓力。

三、有些類如交易所的核心交易引擎，控制着交易流程，若是該類能夠建立多個的話，系統徹底亂了。（好比一個軍隊出現了多個司令員同時指揮，確定會亂成一團），因此只有使用單例模式，才能保證核心交易服務器獨立控制整個流程。下面針對一些例子分析一下咱們在開發過程當中應用單例模式須要注意的點。
1、做用
單例模式（Singleton）：保證一個類僅有一個實例，並提供一個訪問它的全局訪問點

2、適用場景

1. 應用中某個實例對象須要頻繁的被訪問。

2. 應用中每次啓動只會存在一個實例。如帳號系統，數據庫系統。

3、經常使用的使用方式

（1）懶漢式

優勢：延遲加載（須要的時候纔去加載）

缺點：線程不安全，在多線程中很容易出現不一樣步的狀況，如在數據庫對象進行的頻繁讀寫操做時。

具體實現以下：

public class Singleton {  
  
    /* 持有私有靜態實例，防止被引用，此處賦值爲null，目的是實現延遲加載 */  
    private static Singleton instance = null;  
  
    /* 私有構造方法，防止被實例化 */  
    private Singleton() {  
    }  
  
    /* 1:懶漢式，靜態工程方法，建立實例 */  
    public static Singleton getInstance() {  
        if (instance == null) {  
            instance = new Singleton();  
        }  
        return instance;  
    }  
}

（2）加同步鎖

優勢：解決了線程不安全的問題。

缺點：效率有點低，每次調用實例都要判斷同步鎖

注：在Android源碼中使用的該單例方法有：InputMethodManager，AccessibilityManager等都是使用這種單例模式。

具體代碼以下：

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

或

    /*加上synchronized，可是每次調用實例時都會加載**/  
     public static Singleton getInstance() {  
         synchronized (Singleton.class) {  
             if (instance == null) {  
                 instance = new Singleton();  
             }  
         }  
         return instance;  
     }

（3）雙重檢驗鎖

要優化（2）中由於每次調用實例都要判斷同步鎖的問題，不少人都使用下面的一種雙重判斷校驗的辦法。

優勢：在併發量很少，安全性不高的狀況下或許能很完美運行單例模式

缺點：不一樣平臺編譯過程當中可能會存在嚴重安全隱患。

補充：在android圖像開源項目Android-Universal-Image-Loader （https://github.com/nostra13/Android-Universal-Image-Loader）中使用的是這種方式。

/*3.雙重鎖定:只在第一次初始化的時候加上同步鎖*/  
  public static Singleton getInstance() {  
      if (instance == null) {  
          synchronized (Singleton.class) {  
              if (instance == null) {  
                  instance = new Singleton();  
              }  
          }  
      }  
      return instance;  
  }

這種方法貌似很完美的解決了上述效率的問題，它或許在併發量很少，安全性不過高的狀況能完美運行，可是，這種方法也有不幸的地方。問題就是出如今這句

    instance = new Singleton();

在JVM編譯的過程當中會出現指令重排的優化過程，這就會致使當 instance實際上還沒初始化，就可能被分配了內存空間，也就是說會出現 instance !=null 可是又沒初始化的狀況，這樣就會致使返回的 instance 不完整（能夠參考：http://www.360doc.com/content/11/0810/12/1542811_139352888.shtml）。

（4）內部類的實現

優勢：延遲加載，線程安全（java中class加載時互斥的），也減小了內存消耗。內部類是一種好的實現方式，能夠推薦使用一下：

public class SingletonInner {   
    private static class SingletonHolder {  
        private static SingletonInner instance = new SingletonInner();  
    }  
  
    /** 
     * 私有的構造函數 
     */  
    private SingletonInner() {  
  
    }  
  
    public static SingletonInner getInstance() {  
        return SingletonHolder.instance;  
    }  
  
    protected void method() {  
        System.out.println("SingletonInner");  
    }  
}

（5）枚舉的方法

這是網上不少人推薦的一種作法，可是貌似使用的不普遍，你們能夠試試，具體代碼以下：

public enum SingletonEnum {  
    /** 
     * 1.從Java1.5開始支持; 
     * 2.無償提供序列化機制; 
     * 3.絕對防止屢次實例化，即便在面對複雜的序列化或者反射攻擊的時候; 
     */  
  
    instance;  
  
    private String others;  
  
    SingletonEnum() {  
  
    }  
  
    public void method() {  
        System.out.println("SingletonEnum");  
    }  
  
    public String getOthers() {  
        return others;  
    }  
  
    public void setOthers(String others) {  
        this.others = others;  
    }  
}

經過單例模式的學習告訴咱們：

一、單例模式理解起來簡單，可是具體實現起來仍是有必定的難度。

二、synchronized關鍵字鎖定的是對象，在用的時候，必定要在恰當的地方使用（注意須要使用鎖的對象和過程，可能有的時候並非整個對象及整個過程都須要鎖）。

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

首先，靜態類不能實現接口。（從類的角度說是能夠的，可是那樣就破壞了靜態了。由於接口中不容許有static修飾的方法，因此即便實現了也是非靜態的）

其次，單例能夠被延遲初始化，靜態類通常在第一次加載是初始化。之因此延遲加載，是由於有些類比較龐大，因此延遲加載有助於提高性能。

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

最後一點，單例類比較靈活，畢竟從實現上只是一個普通的Java類，只要知足單例的基本需求，你能夠在裏面爲所欲爲的實現一些其它功能，可是靜態類不行。從上面這些歸納中，基本能夠看出兩者的區別，可是，從另外一方面講，咱們上面最後實現的那個單例模式，內部就是用一個靜態類來實現的，因此，兩者有很大的關聯，只是咱們考慮問題的層面不一樣罷了。兩種思想的結合，才能造就出完美的解決方案，就像HashMap採用數組+鏈表來實現同樣，其實生活中不少事情都是這樣，單用不一樣的方法來處理問題，老是有優勢也有缺點，最完美的方法是，結合各個方法的優勢，才能最好的解決問題！

關於其餘的模式詳見文章轉載文章於：http://zz563143188.iteye.com/blog/1847029