——可復(fù)用面向?qū)ο筌浖幕A(chǔ)
設(shè)計(jì)模式（Design pattern）是一套被反復(fù)使用、多數(shù)人知曉的、經(jīng)過分類編目的、代碼設(shè)計(jì)經(jīng)驗(yàn)的總結(jié)。使用設(shè)計(jì)模式是為了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。 毫無疑問，設(shè)計(jì)模式于己于他人于系統(tǒng)都是多贏的，設(shè)計(jì)模式使代碼編制真正工程化，設(shè)計(jì)模式是軟件工程的基石，如同大廈的一塊塊磚石一樣。項(xiàng)目中合理的運(yùn)用設(shè)計(jì)模式可以完美的解決很多問題，每種模式在現(xiàn)在中都有相應(yīng)的原理來與之對應(yīng)，每一個(gè)模式描述了一個(gè)在我們周圍不斷重復(fù)發(fā)生的問題，以及該問題的核心解決方案，這也是它能被廣泛應(yīng)用的原因。本章系Java之美[從菜鳥到高手演變]系列之設(shè)計(jì)模式，我們會以理論與實(shí)踐相結(jié)合的方式來進(jìn)行本章的學(xué)習(xí)，希望廣大程序愛好者，學(xué)好設(shè)計(jì)模式，做一個(gè)優(yōu)秀的軟件工程師！
企業(yè)級項(xiàng)目實(shí)戰(zhàn)(帶源碼)地址：http://zz563143188.iteye.com/blog/1825168
23種模式j(luò)ava實(shí)現(xiàn)源碼下載地址 http://pan.baidu.com/share/link?shareid=372668&uk=4076915866#dir/path=%2F%E5%AD%A6%E4%B9%A0%E6%96%87%E4%BB%B6
一、設(shè)計(jì)模式的分類
總體來說設(shè)計(jì)模式分為三大類：
創(chuàng)建型模式，共五種：工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式。
結(jié)構(gòu)型模式，共七種：適配器模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。
行為型模式，共十一種：策略模式、模板方法模式、觀察者模式、迭代子模式、責(zé)任鏈模式、命令模式、備忘錄模式、狀態(tài)模式、訪問者模式、中介者模式、解釋器模式。
其實(shí)還有兩類：并發(fā)型模式和線程池模式。用一個(gè)圖片來整體描述一下：
二、設(shè)計(jì)模式的六大原則
1、開閉原則（Open Close Principle）
開閉原則就是說對擴(kuò)展開放，對修改關(guān)閉。在程序需要進(jìn)行拓展的時(shí)候，不能去修改原有的代碼，實(shí)現(xiàn)一個(gè)熱插拔的效果。所以一句話概括就是：為了使程序的擴(kuò)展性好，易于維護(hù)和升級。想要達(dá)到這樣的效果，我們需要使用接口和抽象類，后面的具體設(shè)計(jì)中我們會提到這點(diǎn)。
2、里氏代換原則（Liskov Substitution Principle）
里氏代換原則(Liskov Substitution Principle LSP)面向?qū)ο笤O(shè)計(jì)的基本原則之一。 里氏代換原則中說，任何基類可以出現(xiàn)的地方，子類一定可以出現(xiàn)。 LSP是繼承復(fù)用的基石，只有當(dāng)衍生類可以替換掉基類，軟件單位的功能不受到影響時(shí)，基類才能真正被復(fù)用，而衍生類也能夠在基類的基礎(chǔ)上增加新的行為。里氏代換原則是對“開-閉”原則的補(bǔ)充。實(shí)現(xiàn)“開-閉”原則的關(guān)鍵步驟就是抽象化。而基類與子類的繼承關(guān)系就是抽象化的具體實(shí)現(xiàn)，所以里氏代換原則是對實(shí)現(xiàn)抽象化的具體步驟的規(guī)范?！?From Baidu 百科
3、依賴倒轉(zhuǎn)原則（Dependence Inversion Principle）
這個(gè)是開閉原則的基礎(chǔ)，具體內(nèi)容：真對接口編程，依賴于抽象而不依賴于具體。
4、接口隔離原則（Interface Segregation Principle）
這個(gè)原則的意思是：使用多個(gè)隔離的接口，比使用單個(gè)接口要好。還是一個(gè)降低類之間的耦合度的意思，從這兒我們看出，其實(shí)設(shè)計(jì)模式就是一個(gè)軟件的設(shè)計(jì)思想，從大型軟件架構(gòu)出發(fā)，為了升級和維護(hù)方便。所以上文中多次出現(xiàn)：降低依賴，降低耦合。
5、迪米特法則（最少知道原則）（Demeter Principle）
為什么叫最少知道原則，就是說：一個(gè)實(shí)體應(yīng)當(dāng)盡量少的與其他實(shí)體之間發(fā)生相互作用，使得系統(tǒng)功能模塊相對獨(dú)立。
6、合成復(fù)用原則（Composite Reuse Principle）
原則是盡量使用合成/聚合的方式，而不是使用繼承。
三、Java的23中設(shè)計(jì)模式
從這一塊開始，我們詳細(xì)介紹Java中23種設(shè)計(jì)模式的概念，應(yīng)用場景等情況，并結(jié)合他們的特點(diǎn)及設(shè)計(jì)模式的原則進(jìn)行分析。
1、工廠方法模式（Factory Method）
工廠方法模式分為三種：
11、普通工廠模式：就是建立一個(gè)工廠類，對實(shí)現(xiàn)了同一接口的一些類進(jìn)行實(shí)例的創(chuàng)建。首先看下關(guān)系圖：
舉例如下：（我們舉一個(gè)發(fā)送郵件和短信的例子）
首先，創(chuàng)建二者的共同接口：
public interface Sender {
public void Send();
}
其次，創(chuàng)建實(shí)現(xiàn)類：
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、多個(gè)工廠方法模式：是對普通工廠方法模式的改進(jìn)，在普通工廠方法模式中，如果傳遞的字符串出錯(cuò)，則不能正確創(chuàng)建對象，而多個(gè)工廠方法模式是提供多個(gè)工廠方法，分別創(chuàng)建對象。關(guān)系圖：
將上面的代碼做下修改，改動下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、靜態(tài)工廠方法模式，將上面的多個(gè)工廠方法模式里的方法置為靜態(tài)的，不需要?jiǎng)?chuàng)建實(shí)例，直接調(diào)用即可。
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!
總體來說，工廠模式適合：凡是出現(xiàn)了大量的產(chǎn)品需要?jiǎng)?chuàng)建，并且具有共同的接口時(shí)，可以通過工廠方法模式進(jìn)行創(chuàng)建。在以上的三種模式中，第一種如果傳入的字符串有誤，不能正確創(chuàng)建對象，第三種相對于第二種，不需要實(shí)例化工廠類，所以，大多數(shù)情況下，我們會選用第三種——靜態(tài)工廠方法模式。
2、抽象工廠模式（Abstract Factory）
工廠方法模式有一個(gè)問題就是，類的創(chuàng)建依賴工廠類，也就是說，如果想要拓展程序，必須對工廠類進(jìn)行修改，這違背了閉包原則，所以，從設(shè)計(jì)角度考慮，有一定的問題，如何解決？就用到抽象工廠模式，創(chuàng)建多個(gè)工廠類，這樣一旦需要增加新的功能，直接增加新的工廠類就可以了，不需要修改之前的代碼。因?yàn)槌橄蠊S不太好理解，我們先看看圖，然后就和代碼，就比較容易理解。
請看例子：
public interface Sender {
public void Send();
}兩個(gè)實(shí)現(xiàn)類：
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!");
}
}
兩個(gè)工廠類：
public class SendMailFactory implements Provider {
@Override
public Sender produce(){
return new MailSender();
}
}
public class SendSmsFactory implements Provider{
@Override
public Sender produce() {
return new SmsSender();
}
}
在提供一個(gè)接口：
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();
}
}
其實(shí)這個(gè)模式的好處就是，如果你現(xiàn)在想增加一個(gè)功能：發(fā)及時(shí)信息，則只需做一個(gè)實(shí)現(xiàn)類，實(shí)現(xiàn)Sender接口，同時(shí)做一個(gè)工廠類，實(shí)現(xiàn)Provider接口，就OK了，無需去改動現(xiàn)成的代碼。這樣做，拓展性較好！
3、單例模式（Singleton）
單例對象（Singleton）是一種常用的設(shè)計(jì)模式。在Java應(yīng)用中，單例對象能保證在一個(gè)JVM中，該對象只有一個(gè)實(shí)例存在。這樣的模式有幾個(gè)好處：
1、某些類創(chuàng)建比較頻繁，對于一些大型的對象，這是一筆很大的系統(tǒng)開銷。
2、省去了new操作符，降低了系統(tǒng)內(nèi)存的使用頻率，減輕GC壓力。
3、有些類如交易所的核心交易引擎，控制著交易流程，如果該類可以創(chuàng)建多個(gè)的話，系統(tǒng)完全亂了。（比如一個(gè)軍隊(duì)出現(xiàn)了多個(gè)司令員同時(shí)指揮，肯定會亂成一團(tuán)），所以只有使用單例模式，才能保證核心交易服務(wù)器獨(dú)立控制整個(gè)流程。
首先我們寫一個(gè)簡單的單例類：
public class Singleton {
/* 持有私有靜態(tài)實(shí)例，防止被引用，此處賦值為null，目的是實(shí)現(xiàn)延遲加載 */
private static Singleton instance = null;
/* 私有構(gòu)造方法，防止被實(shí)例化 */
private Singleton() {
}
/* 靜態(tài)工程方法，創(chuàng)建實(shí)例 */
public static Singleton getInstance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}
/* 如果該對象被用于序列化，可以保證對象在序列化前后保持一致 */
public Object readResolve() {
return instance;
}
}
這個(gè)類可以滿足基本要求，但是，像這樣毫無線程安全保護(hù)的類，如果我們把它放入多線程的環(huán)境下，肯定就會出現(xiàn)問題了，如何解決？我們首先會想到對getInstance方法加synchronized關(guān)鍵字，如下：
public static synchronized Singleton getInstance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}
但是，synchronized關(guān)鍵字鎖住的是這個(gè)對象，這樣的用法，在性能上會有所下降，因?yàn)槊看握{(diào)用getInstance()，都要對對象上鎖，事實(shí)上，只有在第一次創(chuàng)建對象的時(shí)候需要加鎖，之后就不需要了，所以，這個(gè)地方需要改進(jìn)。我們改成下面這個(gè)：
public static Singleton getInstance() {
if (instance == null) {
synchronized (instance) {
if (instance == null) {
instance = new Singleton();
}
}
}
return instance;
}
似乎解決了之前提到的問題，將synchronized關(guān)鍵字加在了內(nèi)部，也就是說當(dāng)調(diào)用的時(shí)候是不需要加鎖的，只有在instance為null，并創(chuàng)建對象的時(shí)候才需要加鎖，性能有一定的提升。但是，這樣的情況，還是有可能有問題的，看下面的情況：在Java指令中創(chuàng)建對象和賦值操作是分開進(jìn)行的，也就是說instance = new Singleton();語句是分兩步執(zhí)行的。但是JVM并不保證這兩個(gè)操作的先后順序，也就是說有可能JVM會為新的Singleton實(shí)例分配空間，然后直接賦值給instance成員，然后再去初始化這個(gè)Singleton實(shí)例。這樣就可能出錯(cuò)了，我們以A、B兩個(gè)線程為例：
a>A、B線程同時(shí)進(jìn)入了第一個(gè)if判斷
b>A首先進(jìn)入synchronized塊，由于instance為null，所以它執(zhí)行instance = new Singleton();
c>由于JVM內(nèi)部的優(yōu)化機(jī)制，JVM先畫出了一些分配給Singleton實(shí)例的空白內(nèi)存，并賦值給instance成員（注意此時(shí)JVM沒有開始初始化這個(gè)實(shí)例），然后A離開了synchronized塊。
d>B進(jìn)入synchronized塊，由于instance此時(shí)不是null，因此它馬上離開了synchronized塊并將結(jié)果返回給調(diào)用該方法的程序。
e>此時(shí)B線程打算使用Singleton實(shí)例，卻發(fā)現(xiàn)它沒有被初始化，于是錯(cuò)誤發(fā)生了。
所以程序還是有可能發(fā)生錯(cuò)誤，其實(shí)程序在運(yùn)行過程是很復(fù)雜的，從這點(diǎn)我們就可以看出，尤其是在寫多線程環(huán)境下的程序更有難度，有挑戰(zhàn)性。我們對該程序做進(jìn)一步優(yōu)化：
private static class SingletonFactory{
private static Singleton instance = new Singleton();
}
public static Singleton getInstance(){
return SingletonFactory.instance;
}實(shí)際情況是，單例模式使用內(nèi)部類來維護(hù)單例的實(shí)現(xiàn)，JVM內(nèi)部的機(jī)制能夠保證當(dāng)一個(gè)類被加載的時(shí)候，這個(gè)類的加載過程是線程互斥的。這樣當(dāng)我們第一次調(diào)用getInstance的時(shí)候，JVM能夠幫我們保證instance只被創(chuàng)建一次，并且會保證把賦值給instance的內(nèi)存初始化完畢，這樣我們就不用擔(dān)心上面的問題。同時(shí)該方法也只會在第一次調(diào)用的時(shí)候使用互斥機(jī)制，這樣就解決了低性能問題。這樣我們暫時(shí)總結(jié)一個(gè)完美的單例模式：
public class Singleton {
/* 私有構(gòu)造方法，防止被實(shí)例化 */
private Singleton() {
}
/* 此處使用一個(gè)內(nèi)部類來維護(hù)單例 */
private static class SingletonFactory {
private static Singleton instance = new Singleton();
}
/* 獲取實(shí)例 */
public static Singleton getInstance() {
return SingletonFactory.instance;
}
/* 如果該對象被用于序列化，可以保證對象在序列化前后保持一致 */
public Object readResolve() {
return getInstance();
}
}
其實(shí)說它完美，也不一定，如果在構(gòu)造函數(shù)中拋出異常，實(shí)例將永遠(yuǎn)得不到創(chuàng)建，也會出錯(cuò)。所以說，十分完美的東西是沒有的，我們只能根據(jù)實(shí)際情況，選擇最適合自己應(yīng)用場景的實(shí)現(xiàn)方法。也有人這樣實(shí)現(xiàn)：因?yàn)槲覀冎恍枰趧?chuàng)建類的時(shí)候進(jìn)行同步，所以只要將創(chuàng)建和getInstance()分開，單獨(dú)為創(chuàng)建加synchronized關(guān)鍵字，也是可以的：
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;
}
}
考慮性能的話，整個(gè)程序只需創(chuàng)建一次實(shí)例，所以性能也不會有什么影響。
補(bǔ)充：采用"影子實(shí)例"的辦法為單例對象的屬性同步更新
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();
}資源：http://download.csdn.net/detail/zhangerqing/4835830
延伸閱讀
- 珊珊老師——北京IT機(jī)構(gòu)十年一線教學(xué)經(jīng)驗(yàn) 2024-08-28
- 向著Java前進(jìn) 2023-04-15
- 2021年Java程序員的就業(yè)前景如何？ 2022-02-17
- 感謝萬碼，我認(rèn)識到了java的魅力 2021-05-23
- 今天我成為了Java工程師 2021-05-23
- 我的JAVA生涯 ——解*泉 2020-01-15
- 以java為劍，仗劍走江湖—尚*權(quán) 2019-12-22
- 開啟我的java征途——鄭*亮 2019-11-06
- 我想這就是Java工程師的工作——?jiǎng)?聰 2019-07-05
- 向Java工程師靠近——程*賞 2018-01-25
珊珊老師——北京IT機(jī)構(gòu)十年一線教學(xué)經(jīng)驗(yàn)