JAVA設計模式

#1、面向對象OOP 面向對象設計的任務是對面向對象分析的結果做進一步的規範化整理，以便可以被面向對象編程直接接受。
面向對象設計是一種軟件設計方法，是一種工程化規範。
歸納地說，面向對象設計就是「根據需求決定所需的類、類的操做，以及類之間關聯的過程」。

面向對象設計的主要工做包括：

• 肯定須要的類；
• 給每一個類提供一組完整的操做；
• 明確地使用繼承來表現共同點。

主要原則：

• 模塊化，對象就是模塊；把數據結構和操做這些數據的方法緊密地結合在一塊兒所構成的模塊。
• 抽象，面向對象方法不只支持過程抽象，並且支持數據抽象。
• 信息隱藏，在面向對象方法中，信息隱藏經過對象的封裝性來實現。
• 低耦合，耦合主要指不一樣對象之間相互關聯的緊密程度。低耦合使得系統中某一部分的變化對其餘部分的影響降到最低程度。

#2、設計原則

1. 單一職責原則 (Single Responsibility Principle, SRP) 一個類只負責一個功能領域中的相應職責；
2. 開閉原則 (Open-Closed Principle, OCP) 軟件實體應對擴展開放，而對修改關閉；
3. 里氏代換原則 (Liskov Substitution Principle, LSP)全部引用基類對象的地方可以透明地使用其子類的對象；
4. 依賴倒轉原則 (Dependence Inversion Principle, DIP) 抽象不該該依賴於細節，細節應該依賴於 抽象；
5. 接口隔離原則 (Interface Segregation Principle, ISP) 使用多個專門的接口，而不使用單一的總接 口 ；
6. 合成複用原則 (Composite Reuse Principle, CRP) 儘可能使用對象組合，而不是繼承來達到複用的 目的；
7. 迪米特法則 (Law of Demeter, LoD) 一個軟件實體應當儘量少地與其餘實體發生相互做用。

#3、設計模式

##建立型模式 ###1. 簡單工廠模式

定義一個工廠類，它能夠根據參數的不一樣返回不一樣類的實例，被建立的實例一般都具備共同的父類。由於在簡單工廠模式中用於建立實例的方法是靜態(static)方法，所以簡單工廠模式又被稱爲靜態工廠方法(Static Factory Method)模式。

簡單工廠模式的要點在於：當你須要什麼，只須要傳入一個正確的參數，就能夠獲取你所須要的對象，而無須知道其建立細節。簡單工廠模式結構比較簡單，其核心是工廠類的設計。

主要角色： Factory（工廠角色） - Product（抽象產品角色）- ConcreteProduct（具體產品角色）

###2. 工廠方法模式

定義一個用於建立對象的接口，讓子類決定將哪個類實例化。工廠方法模式讓一個類的實例化延遲到其子類。工廠方法模式又簡稱爲工廠模式(Factory Pattern)，又可稱做虛擬構造器模式(Virtual Constructor Pattern)或多態工廠模式(Polymorphic Factory Pattern)。

工廠方法模式提供一個抽象工廠接口來聲明抽象工廠方法，而由其子類來具體實現工廠方法，建立具體的產品對象。

主要角色： Factory（抽象工廠） - ConcreteFactory（具體工廠） - Product（抽象產品） - ConcreteProduct（具體產品）

###3. 抽象工廠模式

提供一個建立一系列相關或相互依賴對象的接口，而無須指定它們具體的類。抽象工廠模式又稱爲Kit模式。在抽象工廠模式中，每個具體工廠都提供了多個工廠方法用於產生多種不一樣類型的產品，這些產品構成了一個產品族。

主要角色：AbstractFactory（抽象工廠） - ConcreteFactory（具體工廠）- AbstractProduct（抽象產品）- ConcreteProduct（具體產品）

###4. 單例模式

確保某一個類只有一個實例，並且自行實例化並向整個系統提供這個實例，這個類稱爲單例類，它提供全局訪問的方法。

單例模式有三個要點：一是某個類只能有一個實例；二是它必須自行建立這個實例；三是它必須自行向整個系統提供這個實例。

主要角色：Singleton（單例）：在單例類的內部實現只生成一個實例，同時它提供一個靜態getInstance()工廠方法，讓客戶能夠訪問它的惟一實例；爲了防止在外部對其實例化，將其構造函數設計爲私有；在單例類內部定義了一個Singleton類型的靜態對象，做爲外部共享的惟一實例。

• 餓漢式

class EagerSingleton {
    private static final EagerSingleton instance = new EagerSingleton();
    private EagerSingleton() { }
    public static EagerSingleton getInstance() {
        return instance;
    }
}

• 懶漢式

class LazySingleton {
    private volatile static LazySingleton instance = null;
    private LazySingleton() { }
    public static LazySingleton getInstance() {
        //第一重判斷
        if (instance == null) {
            //鎖定代碼塊
            synchronized (LazySingleton.class) {
                //第二重判斷
                if (instance == null) {
                        instance = new LazySingleton(); //建立單例實例
                }
            }
        }
    return instance;
    }
}

• Initialization Demand Holder (IoDH)：在單例類中增長一個靜態(static)內部類，在該內部類中建立單例對象，再將該單例對象經過getInstance()方法返回給外部使用。

class Singleton {
    private Singleton() {
    }
    private static class HolderClass {
        private final static Singleton instance = new Singleton();
    }
    public static Singleton getInstance() {
        return HolderClass.instance;
    }
    public static void main(String args[]) {
        Singleton s1, s2;
        s1 = Singleton.getInstance();
        s2 = Singleton.getInstance();
        System.out.println(s1==s2);
    }
}

餓漢式單例類在類被加載時就將本身實例化，它的優勢在於無須考慮多線程訪問問題，能夠確保實例的惟一性；從調用速度和反應時間角度來說，因爲單例對象一開始就得以建立，所以要優於懶漢式單例。可是不管系統在運行時是否須要使用該單例對象，因爲在類加載時該對象就須要建立，所以從資源利用效率角度來，餓漢式單例不及懶漢式單例，並且在系統加載時因爲須要建立餓漢式單例對象，加載時間可能會比較長。

懶漢式單例類在第一次使用時建立，無須一直佔用系統資源，實現了延遲加載，可是必須處理好多個線程同時訪問的問題，特別是當單例類做爲資源控制器，在實例化時必然涉及資源初始化，而資源初始化頗有可能耗費大量時間，這意味着出現多線程同時首次引用此類的機率變得較大，須要經過雙重檢查鎖定等機制進行控制，這將致使系統性能受到必定影響。

餓漢式單例類不能實現延遲加載，無論未來用不用始終佔據內存；懶漢式單例類線程安全控 制煩瑣，並且性能受影響。經過使用IoDH，咱們既能夠實現延遲加載，又能夠保證線程安全，不影響系統性能，不失爲一種最好的Java語言單例模式實現方式（其缺點是與編程語言自己的特性相關，不少面向對象 語言不支持IoDH）。

###5. 原型模式

使用原型實例指定建立對象的種類，而且經過拷貝這些原型建立新的對象。

工做機制：將一個原型對象傳給那個要發動建立的對象，這個要發動建立的對象經過請求原型對象拷貝本身來實現建立過程。因爲在軟件系統中咱們常常會遇到須要建立多個相同或者類似對象的狀況，所以原型模式在真實開發中的使用頻率仍是很是高的。原型模式是一種「另類」的建立型模式，建立克隆對象的工廠就是原型類自身，工廠方法由克隆方法來實現。

須要注意的是經過克隆方法所建立的對象是全新的對象，它們在內存中擁有新的地址，一般對克隆所產生的對象進行修改對原型對象不會形成任何影響，每個克隆對象都是相互獨立的。經過不一樣的方式修改能夠獲得一系列類似但不徹底相同的對象。

主要角色： Prototype（抽象原型類） - ConcretePrototype（具體原型類） - Client（客戶類）

克隆方法：淺克隆(ShallowClone)和深克隆(DeepClone)。在Java語言中，數據類型分爲值類型（基本數據類型）和引用類型，值類型包括int、double、byte、boolean、char等簡單數據類型，引用類型包括類、接口、數組等複雜類型。淺克隆和深克隆的主要區別在因而否支持引用類型的成員變量的複製。

• 淺克隆(ShallowClone) （implements Cloneable） 當對象被複制時只複製它自己和其中包含的值類型的成員變量，而引用類型的成員對象並無複製；

• 深克隆(DeepClone) （implements Serializable ） 除了對象自己被複制外，對象所包含的全部成員變量也將複製。
  

###6. 建造者模式

將一個複雜對象的構建與它的表示分離，使得一樣的構建過程能夠建立不一樣的表示。建造者模式是一種對象建立型模式。

建造者模式一步一步建立一個複雜的對象，它容許用戶只經過指定複雜對象的類型和內容就能夠構建它們，用戶不須要知道內部的具體構建細節。

主要角色：Builder（抽象建造者） - ConcreteBuilder（具體建造者） - Product（產品角色） - Director（指揮者）

##結構型模式 ###1. 適配器模式

將一個接口轉換成客戶但願的另外一個接口，使接口不兼容的那些類能夠一塊兒工做，其別名爲包裝器(Wrapper)。適配器模式既能夠做爲類結構型模式，也能夠做爲對象結構型模式。

將一個類的接口和另外一個類的接口匹配起來，而無須修改原來的適配者接口和抽象目標類接口。

• 對象適配器
  適配器與適配者之間是關聯關係
  主要角色：
  Target（目標抽象類） ：目標抽象類定義客戶所需接口，能夠是一個抽象類或接口，也能夠是具體類。
  Adapter（適配器類）：適配器能夠調用另外一個接口，做爲一個轉換器，對Adaptee和Target進行適配，適配器類是適配器模式的核心，在對象適配器中，它經過繼承Target並關聯一個Adaptee對象使兩者產生聯繫。
  Adaptee（適配者類）：適配者即被適配的角色，它定義了一個已經存在的接口，這個接口須要適配，適配者類通常是一個具體類，包含了客戶但願使用的業務方法，在某些狀況下可能沒有適配者類的源代碼。
  
• 類適配器
  適配器與適配者之間是繼承（或實現）關係
  適配器類實現了抽象目標類接口Target，並繼承了適配者類，在適配器類的request()方法中調用所繼承的適配者類的specificRequest()方法，實現了適配。
  

優勢：
1）將目標類和適配者類解耦，經過引入一個適配器類來重用現有的適配者類，無須修改原有結構。
2）增長了類的透明性和複用性
3）靈活性和擴展性都很是好，經過使用配置文件，能夠很方便地更換適配器，也能夠在不修改原有代碼的基礎上增長新的適配器類，徹底符合「開閉原則」。

• 雙向適配器
• 缺省適配器

###2. 代理模式

給某一個對象提供一個代理或佔位符，並由代理對象來控制對原對象的訪問。

代理模式是一種對象結構型模式。在代理模式中引入了一個新的代理對象，代理對象在客戶端對象和目標對象之間起到中介的做用，它去掉客戶不能看到的內容和服務或者增添客戶須要的額外的新服務。

主要角色：
1）Subject（抽象主題角色）：它聲明瞭真實主題和代理主題的共同接口，這樣一來在任何使用真實主題的地方均可以使用代理主題，客戶端一般須要針對抽象主題角色進行編程。
2） Proxy（代理主題角色）：它包含了對真實主題的引用，從而能夠在任什麼時候候操做真實主題對象；在代理主題角色中提供一個與真實主題角色相同的接口，以便在任什麼時候候均可以替代真實主題；代理主題角色還能夠控制對真實主題的使用，負責在須要的時候建立和刪除真實主題對象，並對真實主題對象的使用加以約束。一般，在代理主題角色中，客戶端在調用所引用的真實主題操做以前或以後還須要執行其餘操做，而不只僅是單純調用真實主題對象中。 3） RealSubject（真實主題角色）：它定義了代理角色所表明的真實對象，在真實主題角色中實現了真實的業務操做，客戶端能夠經過代理主題角色間接調用真實主題角色中定義的操做。
優勢：
1）可以協調調用者和被調用者，在必定程度上下降了系統的耦合度； 2）客戶端能夠針對抽象主題角色進行編程，增長和更換代理類無須修改源代碼，符合開閉原則，系統具備較好的靈活性和可擴展性。
缺點：
1）因爲在客戶端和真實主題之間增長了代理對象，所以有些類型的代理模式可能會形成請求的處理速度變慢，例如保護代理。
2）實現代理模式須要額外的工做，並且有些代理模式的實現過程較爲複雜，例如遠程代理。

###3. 橋接模式

將抽象部分與它的實現部分分離，使它們均可以獨立地變化。它是一種對象結構型模式，又稱爲柄體(Handle and Body)模式或接口(Interface)模式。

橋接模式用一種巧妙的方式處理多層繼承存在的問題，用抽象關聯取代了傳統的多層繼承，將類之間的靜態繼承關係轉換爲動態的對象組合關係，使得系統更加靈活，並易於擴展，同時有效控制了系統中類的個數。

###4. 外觀模式

爲子系統中的一組接口提供一個統一的入口。外觀模式定義了一個高層接口，這個接口使得這一子系統更加容易使用。

外觀模式又稱爲門面模式，它是一種對象結構型模式。外觀模式是迪米特法則的一種具體實現，經過引入一個新的外觀角色能夠下降原有系統的複雜度，同時下降客戶類與子系統的耦合度。

###5. 組合模式

組合多個對象造成樹形結構以表示具備「總體—部分」關係的層次結構。組合模式對單個對象（即葉子對象）和組合對象（即容器對象）的使用具備一致性，組合模式又能夠稱爲「總體—部分」(Part-Whole)模式，它是一種對象結構型模式。

###6. 裝飾模式

動態地給一個對象增長一些額外的職責，就增長對象功能來講，裝飾模式比生成子類實現更爲靈活。裝飾模式是一種對象結構型模式。

在裝飾模式中，爲了讓系統具備更好的靈活性和可擴展性，咱們一般會定義一個抽象裝飾類，而將具體的裝飾類做爲它的子類。

###7. 享元模式

運用共享技術有效地支持大量細粒度對象的複用。系統只使用少許的對象，而這些對象都很類似，狀態變化很小，能夠實現對象的屢次複用。因爲享元模式要求可以共享的對象必須是細粒度對象，所以它又稱爲輕量級模式，它是一種對象結構型模式。

##行爲型模式

1. 觀察者模式
2. 訪問者模式
3. 中介者模式
4. 模版方法模式
5. 策略模式
6. 狀態模式
7. 備忘錄模式
8. 迭代器模式
9. 解釋器模式
10. 命令模式
11. 職責鏈模式