設計模式（一）之建立型模式
概述
設計模式（Design pattern）是一套被反覆使用的、多數人知曉的、經過分類編碼的、程式碼設計經驗的總結。使用設計模式是為了可重用程式碼、讓程式碼更容易被他人理解、保證程式碼可靠性。 毫無疑問，設計模式於己於他人於系統都是多贏的，設計模式使程式碼編寫真正工程化，設計模式是軟體工程的基石，如同大廈的一塊塊磚石一樣。專案中合理的運用設計模式可以完美的解決很多問題，每種模式在現實中都有相應的原理來與之對應，每一個模式描述了一個在我們周圍不斷重複發生的問題，以及該問題的核心解決方案，這也是它能被廣泛應用的原因。
設計模式的分類
總體來說設計模式分為三大類：
- 建立型模式，共五種：工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式。
- 結構型模式，共七種：介面卡模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。
- 行為型模式，共十一種：策略模式、模板方法模式、觀察者模式、迭代子模式、責任鏈模式、命令模式、備忘錄模式、狀態模式、訪問者模式、中介者模式、直譯器模式。
其實還有兩類：併發型模式和執行緒池模式。用一個圖片來整體描述一下：
設計模式的六大原則
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）
原則是儘量使用合成/聚合的方式，而不是使用繼承。
建立型模式
工廠方法模式（Factory Method）
工廠方法模式分為三種：普通工廠模式、多個工廠方法模式、靜態工廠方法模式。
普通工廠模式
就是建立一個工廠類，對實現了同一介面的一些類進行例項的建立。首先看下關係圖：
舉例如下：（我們舉一個傳送郵件和簡訊的例子）
首先，建立二者的共同介面：
public interface Sender {
public void Send();
} 其次，建立實現類：
public class MailSender implements Sender {
@Override
public void Send() {
System.out.println("this is mail sender!");
}
} 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!
多個工廠方法模式
是對普通工廠模式的改進，在普通工廠模式中，如果傳遞的字串出錯，則不能正確建立物件，而多個工廠方法模式是提供多個工廠方法，分別建立物件。關係圖：
將上面的程式碼做下修改，改動下SendFactory類就行，如下：
public class 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 mail sender!
靜態工廠方法模式
將上面的多個工廠方法模式裡的方法置為靜態的，不需要建立例項，直接呼叫即可。
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 mail sender!
總體來說，工廠模式適合：凡是出現了大量的產品需要建立，並且具有共同的介面時，可以通過工廠方法模式進行建立。在以上的三種模式中，第一種如果傳入的字串有誤，不能正確建立物件，第三種相對於第二種，不需要例項化工廠類，所以，大多數情況下，我們會選用第三種——靜態工廠方法模式。
抽象工廠模式（Abstract Factory）
工廠方法模式有一個問題就是，類的建立依賴工廠類，也就是說，如果想要拓展程式，必須對工廠類進行修改，這違背了閉包原則，所以，從設計角度考慮，有一定的問題，如何解決？就用到抽象工廠模式，建立多個工廠類，這樣一旦需要增加新的功能，直接增加新的工廠類就可以了，不需要修改之前的程式碼。因為抽象工廠不太好理解，我們先看看圖，然後再看程式碼，就比較容易理解。
請看例子，建立傳送介面：
public interface Sender {
public void Send();
} 兩個實現類：
public class MailSender implements Sender {
@Override
public void Send() {
System.out.println("this is mail sender!");
}
} public class SmsSender implements Sender {
@Override
public void Send() {
System.out.println("this is sms sender!");
}
} 再提供一個抽象工廠介面：
public interface Provider {
public Sender produce();
} 兩個工廠類：
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 class Test {
public static void main(String[] args) {
Provider provider = new SendMailFactory();
Sender sender = provider.produce();
sender.Send();
}
} 輸出：this is mail sender!
這個模式的好處就是，如果你現在想增加一個功能：傳送語音資訊，則只需做一個實現類，實現Sender介面，同時做一個工廠類，實現Provider介面，就可以了，無需去改動現成的程式碼。這樣做，拓展性較好！
單例模式（Singleton）
單例物件（Singleton）是一種常用的設計模式。在Java應用中，單例物件能保證在一個JVM中，該物件只有一個例項存在。
這個模式有幾個好處：
- 1、某些類建立比較頻繁，對於一些大型的物件，這是一筆很大的系統開銷。
- 2、省去了new操作符，降低了系統記憶體的使用頻率，減輕GC壓力。
- 3、有些類如交易所的核心交易引擎，控制著交易流程，如果該類可以建立多個的話，系統完全亂了。（比如一個軍隊出現了多個司令員同時指揮，肯定會亂成一團），所以只有使用單例模式，才能保證核心交易伺服器獨立控制整個流程。
單例模式有多種寫法，各有利弊，下面我們來看看各種寫法。
1. 餓漢模式
public class Singleton {
private static Singleton instance = new Singleton();
private Singleton (){}
public static Singleton getInstance() {
return instance;
}
} 這種方式在類載入時就完成了初始化，所以類載入較慢，但獲取物件的速度快。 這種方式基於類載入機制避免了多執行緒的同步問題（JVM內部的機制能夠保證當一個類被載入的時候，這個類的載入過程是執行緒互斥的）。但是也不能確定有其他的方式（或者其他的靜態方法）導致類裝載，這時候初始化instance顯然沒有達到懶載入的效果。
2. 懶漢模式（執行緒不安全）
public class Singleton {
private static Singleton instance;
private Singleton (){}
public static Singleton getInstance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}
} 懶漢模式申明瞭一個靜態物件，在使用者第一次呼叫時初始化，雖然節約了資源，但第一次載入時需要例項化，反映稍慢一些，而且在多執行緒不能正常工作。
3. 懶漢模式（執行緒安全）
public class Singleton {
private static Singleton instance;
private Singleton (){}
public static synchronized Singleton getInstance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}
} 這種寫法能夠在多執行緒中很好的工作，但是每次呼叫getInstance方法時都需要進行同步，造成不必要的同步開銷，而且大部分時候我們是用不到同步的（事實上，只有在第一次建立物件的時候需要同步），所以不建議用這種模式。
4. 雙重檢查模式 （DCL）
public class Singleton {
private volatile static Singleton singleton;
private Singleton (){}
public static Singleton getInstance() {
if (instance== null) {
synchronized (Singleton.class) {
if (instance== null) {
instance= new Singleton();
}
}
}
return singleton;
}
} 這種寫法在getSingleton方法中對singleton進行了兩次判空，第一次是為了不必要的同步，第二次是在singleton等於null的情況下才建立例項。在這裡用到了volatile關鍵字，volatile會或多或少的影響效能，但考慮到程式的正確性，犧牲這點效能還是值得的。
DCL優點是資源利用率高，第一次執行getInstance時單例物件才被例項化，效率高。缺點是第一次載入時反應稍慢一些，在高併發環境下也有一定的缺陷，雖然發生的概率很小。看下面的情況：在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例項，卻發現它沒有被初始化，於是錯誤發生了。
5. 靜態內部類單例模式
public class Singleton {
private Singleton(){}
public static Singleton getInstance(){
return SingletonHolder.sInstance;
}
private static class SingletonHolder {
private static final Singleton sInstance = new Singleton();
}
}第一次載入Singleton類時並不會初始化sInstance，只有第一次呼叫getInstance方法時虛擬機器載入SingletonHolder並初始化sInstance ，這樣不僅能確保執行緒安全也能保證Singleton類的唯一性，所以推薦使用靜態內部類單例模式。
6. 列舉單例
public enum Singleton {
INSTANCE;
public void doSomeThing() {
}
} 預設列舉例項的建立是執行緒安全的，並且在任何情況下都是單例。列舉單例的優點就是簡單，但是大部分應用開發很少用列舉，可讀性並不是很高，不建議用。
上述講的幾種單例模式實現中，有一種情況下他們會重新建立物件，那就是反序列化，將一個單例例項物件寫到磁碟再讀回來，從而獲得了一個例項。反序列化操作提供了readResolve方法，這個方法可以讓開發人員控制物件的反序列化。在上述的幾個方法示例中如果要杜絕單例物件被反序列化是重新生成物件，就必須加入如下方法：
/* 如果該物件被用於序列化，可以保證物件在序列化前後保持一致 */
private Object readResolve() throws ObjectStreamException{
return singleton;
}7. 使用容器實現單例模式
public class SingletonManager {
private static Map<String, Object> objMap = new HashMap<String,Object>();
private Singleton() {}
public static void registerService(String key, Object instance) {
if (!objMap.containsKey(key) ) {
objMap.put(key, instance) ;
}
}
public static Object getService(String key) {
return objMap.get(key) ;
}
}用SingletonManager 將多種的單例類統一管理，在使用時根據key獲取物件對應型別的物件。這種方式使得我們可以管理多種型別的單例，並且在使用時可以通過統一的介面進行獲取操作，降低了使用者的使用成本，也對使用者隱藏了具體實現，降低了耦合度。
建造者模式（Builder）
建造者模式（builder）是建立一個複雜物件的建立型模式，將構建複雜物件的過程和它的部件解耦，使得構建過程和部件的表示分離開來。
例如我們要DIY一個桌上型電腦電腦，我們找到DIY商家，我們可以要求這臺電腦的cpu或者主機板或者其他的部件都是什麼牌子的什麼配置的，這些部件是我們可以根據我們的需求來變化的，但是這些部件組裝成電腦的過程是一樣的，我們不需要知道這些部件是怎樣組裝成電腦的，我們只需要提供部件的牌子和配置就可以了。對於這種情況我們就可以採用建造者模式，將部件和組裝過程分離，使得構建過程和部件都可以自由拓展，兩者之間的耦合也降到最低。
- Director: 指揮者類，用於統一組裝流程
- Builder：抽象Builder類，規範產品的組建，一般是由子類實現
- ConcreteBulider: 抽象Builder類的實現類，實現抽象Builder類定義的所有方法，並且返回一個組建好的物件
- Product: 產品類
我們就用DIY組裝電腦的例子來實現一下建造者模式：
（1）建立產品類，我要組裝一臺電腦，電腦被抽象為Computer類，它有三個部件:CPU 、主機板和記憶體。並在裡面提供了三個方法分別用來設定CPU 、主機板和記憶體：
public class Computer {
private String mCpu;
private String mMainboard;
private String mRam;
public void setmCpu(String mCpu) {
this.mCpu = mCpu;
}
public void setmMainboard(String mMainboard) {
this.mMainboard = mMainboard;
}
public void setmRam(String mRam) {
this.mRam = mRam;
}
}（2）建立Builder類，規範產品的組建，商家組裝電腦有一套組裝方法的模版，就是一個抽象的Builder類，裡面提供了安裝CPU、主機板和記憶體的方法，以及組裝成電腦的create方法：
public abstract class Builder {
public abstract void buildCpu(String cpu);
public abstract void buildMainboard(String mainboard);
public abstract void buildRam(String ram);
public abstract Computer create();
}（3）商家實現了抽象的Builder類，MyComputerBuilder類用於組裝電腦：
public class MyComputerBuilder extends Builder {
private Computer mComputer = new Computer();
@Override
public void buildCpu(String cpu) {
mComputer.setmCpu(cpu);
}
@Override
public void buildMainboard(String mainboard) {
mComputer.setmMainboard(mainboard);
}
@Override
public void buildRam(String ram) {
mComputer.setmRam(ram);
}
@Override
public Computer create() {
return mComputer;
}
}（4）用Director指揮者類來統一組裝過程，商家的指揮者類用來規範組裝電腦的流程規範，先安裝主機板，再安裝CPU，最後安裝記憶體並組裝成電腦：
public class Director {
Builder mBuild=null;
public Director(Builder build){
this.mBuild=build;
}
public Computer CreateComputer(String cpu,String mainboard,String ram) {
//規範建造流程
this.mBuild.buildMainboard(mainboard);
this.mBuild.buildCpu(cpu);
this.mBuild.buildRam(ram);
return mBuild.create();
}
}（5）客戶端呼叫指揮者類，最後商家用指揮者類組裝電腦。我們只需要提供我們想要的CPU，主機板和記憶體就可以了，至於商家怎樣組裝的電腦我們無需知道。
public class CreatComputer {
public static void main(String[]args){
Builder mBuilder=new MyComputerBuilder();
Direcror mDirecror=new Direcror(mBuilder);
//組裝電腦
mDirecror.CreateComputer("i7","華擎玩家至尊","三星DDR4");
}
}使用場景：
- 當建立複雜物件的演算法應該獨立於該物件的組成部分以及它們的裝配方式時。
- 相同的方法，不同的執行順序，產生不同的事件結果時。
- 多個部件或零件,都可以裝配到一個物件中，但是產生的執行結果又不相同時。
- 產品類非常複雜，或者產品類中的呼叫順序不同產生了不同的效能。
- 建立一些複雜的物件時，這些物件的內部組成構件間的建造順序是穩定的，但是物件的內部組成構件面臨著複雜的變化。
優缺點：
優點：
- 使用建造者模式可以使客戶端不必知道產品內部組成的細節。
- 具體的建造者類之間是相互獨立的，容易擴充套件。
- 由於具體的建造者是獨立的，因此可以對建造過程逐步細化，而不對其他的模組產生任何影響。
缺點：
- 產生多餘的Build物件以及Director類。
原型模式（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的。在這兒，我將結合物件的淺複製和深複製來說一下，首先需要了解物件深、淺複製的概念：
- 淺複製：將一個物件複製後，基本資料型別的變數都會重新建立，而引用型別，指向的還是原物件所指向的。
- 深複製：將一個物件複製後，不論是基本資料型別還有引用型別，都是重新建立的。
簡單來說，就是深複製進行了完全徹底的複製，而淺複製不徹底。接下來，寫一個深淺複製的例子：
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;
}要實現深複製，需要採用流的形式讀入當前物件的二進位制輸入，再寫出二進位制資料對應的物件。