溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
設計模式（Design pattern）是一套被反復使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結。使用設計模式是為了可重用代碼、讓代碼更容易被他人理解、保證代 碼可靠性。 毫無疑問，設計模式于己于他人于系統都是多贏的，設計模式使代碼編制真正工程化，設計模式是軟件工程的基石，如同大廈的一塊塊磚石一樣。項目中合理的運用 設計模式可以完美的解決很多問題，每種模式在現在中都有相應的原理來與之對應，每一個模式描述了一個在我們周圍不斷重復發生的問題，以及該問題的核心解決 方案，這也是它能被廣泛應用的原因。
一、設計模式的分類
總體來說設計模式分為三大類：
創建型模式，共五種：工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式。
結構型模式，共七種：適配器模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。
行為型模式，共十一種：策略模式、模板方法模式、觀察者模式、迭代子模式、責任鏈模式、命令模式、備忘錄模式、狀態模式、訪問者模式、中介者模式、解釋器模式。
其實還有兩類：并發型模式和線程池模式。用一個圖片來整體描述一下：
二、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、多個工廠方法模式，是對普通工廠方法模式的改進，在普通工廠方法模式中，如果傳遞的字符串出錯，則不能正確創建對象，而多個工廠方法模式是提供多個工廠方法，分別創建對象。關系圖：
::__IHACKLOG_REMOTE_IMAGE_AUTODOWN_BLOCK__::2
將上面的代碼做下修改，改動下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 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塊。經典框架中的設計模式JAVA 23種設計模式入門到精通經典框架中的設計模式JAVA 23種設計模式入門到精通經典框架中的設計模式JAVA 23種設計模式入門到精通經典框架中的設計模式JAVA 23種設計模式入門到精通經典框架中的設計模式JAVA 23種設計模式入門到精通
d>B進入synchronized塊，由于instance此時不是null，因此它馬上離開了synchronized塊并將結果返回給調用該方法的程序。
e>此時B線程打算使用Singleton實例，卻發現它沒有被初始化，于是錯誤發生了。
所以程序還是有可能發生錯誤，其實程序在運行過程是很復雜的，從這點我們就可以看出，尤其是在寫多線程環境下的程序更有難度，有挑戰性。我們對該程序做進一步優化：
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
