Spring中常用的9種設(shè)計(jì)模式介紹

這篇文章主要介紹“Spring中常用的9種設(shè)計(jì)模式介紹”，在日常操作中，相信很多人在Spring中常用的9種設(shè)計(jì)模式介紹問(wèn)題上存在疑惑，小編查閱了各式資料，整理出簡(jiǎn)單好用的操作方法，希望對(duì)大家解答”Spring中常用的9種設(shè)計(jì)模式介紹”的疑惑有所幫助！接下來(lái)，請(qǐng)跟著小編一起來(lái)學(xué)習(xí)吧！

第一種：簡(jiǎn)單工廠

又叫做靜態(tài)工廠方法（StaticFactory Method）模式，但不屬于23種GOF設(shè)計(jì)模式之一。
簡(jiǎn)單工廠模式的實(shí)質(zhì)是由一個(gè)工廠類(lèi)根據(jù)傳入的參數(shù)，動(dòng)態(tài)決定應(yīng)該創(chuàng)建哪一個(gè)產(chǎn)品類(lèi)。
spring中的BeanFactory就是簡(jiǎn)單工廠模式的體現(xiàn)，根據(jù)傳入一個(gè)唯一的標(biāo)識(shí)來(lái)獲得bean對(duì)象，但是否是在傳入?yún)?shù)后創(chuàng)建還是傳入?yún)?shù)前創(chuàng)建這個(gè)要根據(jù)具體情況來(lái)定。如下配置，就是在 HelloItxxz 類(lèi)中創(chuàng)建一個(gè) itxxzBean。

<beans>
    <bean id="singletonBean" >
        <constructor-arg>
            <value>Hello! 這是singletonBean!value>
        </constructor-arg>
   </ bean>
    <bean id="itxxzBean"
        singleton="false">
        <constructor-arg>
            <value>Hello! 這是itxxzBean! value>
        </constructor-arg>
    </bean>
</beans>

第二種：工廠方法（Factory Method）

通常由應(yīng)用程序直接使用new創(chuàng)建新的對(duì)象，為了將對(duì)象的創(chuàng)建和使用相分離，采用工廠模式,即應(yīng)用程序?qū)?duì)象的創(chuàng)建及初始化職責(zé)交給工廠對(duì)象。

一般情況下,應(yīng)用程序有自己的工廠對(duì)象來(lái)創(chuàng)建bean.如果將應(yīng)用程序自己的工廠對(duì)象交給Spring管理,那么Spring管理的就不是普通的bean,而是工廠Bean。

螃蟹就以工廠方法中的靜態(tài)方法為例講解一下：

import java.util.Random;
public class StaticFactoryBean {
      public static Integer createRandom() {
           return new Integer(new Random().nextInt());
       }
}

建一個(gè)config.xm配置文件，將其納入Spring容器來(lái)管理,需要通過(guò)factory-method指定靜態(tài)方法名稱(chēng)

<bean id="random"
factory-method="createRandom" //createRandom方法必須是static的,才能找到 scope="prototype"
/>

測(cè)試:

public static void main(String[] args) {
      //調(diào)用getBean()時(shí),返回隨機(jī)數(shù).如果沒(méi)有指定factory-method,會(huì)返回StaticFactoryBean的實(shí)例,即返回工廠Bean的實(shí)例       XmlBeanFactory factory = new XmlBeanFactory(new ClassPathResource("config.xml"));       System.out.println("我是IT學(xué)習(xí)者創(chuàng)建的實(shí)例:"+factory.getBean("random").toString());
}

第三種：?jiǎn)卫Ｊ剑⊿ingleton）

保證一個(gè)類(lèi)僅有一個(gè)實(shí)例，并提供一個(gè)訪問(wèn)它的全局訪問(wèn)點(diǎn)。
spring中的單例模式完成了后半句話，即提供了全局的訪問(wèn)點(diǎn)BeanFactory。但沒(méi)有從構(gòu)造器級(jí)別去控制單例，這是因?yàn)閟pring管理的是是任意的java對(duì)象。
核心提示點(diǎn)：Spring下默認(rèn)的bean均為singleton，可以通過(guò)singleton=“true|false” 或者 scope=“？”來(lái)指定

第四種：適配器（Adapter）

在Spring的Aop中，使用的Advice（通知）來(lái)增強(qiáng)被代理類(lèi)的功能。Spring實(shí)現(xiàn)這一AOP功能的原理就使用代理模式（1、JDK動(dòng)態(tài)代理。2、CGLib字節(jié)碼生成技術(shù)代理。）對(duì)類(lèi)進(jìn)行方法級(jí)別的切面增強(qiáng)，即，生成被代理類(lèi)的代理類(lèi)， 并在代理類(lèi)的方法前，設(shè)置攔截器，通過(guò)執(zhí)行攔截器重的內(nèi)容增強(qiáng)了代理方法的功能，實(shí)現(xiàn)的面向切面編程。

Adapter類(lèi)接口：

public interface AdvisorAdapter {
boolean supportsAdvice(Advice advice);
      MethodInterceptor getInterceptor(Advisor advisor);
} **MethodBeforeAdviceAdapter類(lèi)**，Adapter
class MethodBeforeAdviceAdapter implements AdvisorAdapter, Serializable {
      public boolean supportsAdvice(Advice advice) {
            return (advice instanceof MethodBeforeAdvice);
      }
      public MethodInterceptor getInterceptor(Advisor advisor) {
            MethodBeforeAdvice advice = (MethodBeforeAdvice) advisor.getAdvice();
      return new MethodBeforeAdviceInterceptor(advice);
      }
}

第五種：包裝器（Decorator）

在我們的項(xiàng)目中遇到這樣一個(gè)問(wèn)題：我們的項(xiàng)目需要連接多個(gè)數(shù)據(jù)庫(kù)，而且不同的客戶在每次訪問(wèn)中根據(jù)需要會(huì)去訪問(wèn)不同的數(shù)據(jù)庫(kù)。我們以往在spring和hibernate框架中總是配置一個(gè)數(shù)據(jù)源，因而sessionFactory的dataSource屬性總是指向這個(gè)數(shù)據(jù)源并且恒定不變，所有DAO在使用sessionFactory的時(shí)候都是通過(guò)這個(gè)數(shù)據(jù)源訪問(wèn)數(shù)據(jù)庫(kù)。

但是現(xiàn)在，由于項(xiàng)目的需要，我們的DAO在訪問(wèn)sessionFactory的時(shí)候都不得不在多個(gè)數(shù)據(jù)源中不斷切換，問(wèn)題就出現(xiàn)了：如何讓sessionFactory在執(zhí)行數(shù)據(jù)持久化的時(shí)候，根據(jù)客戶的需求能夠動(dòng)態(tài)切換不同的數(shù)據(jù)源？我們能不能在spring的框架下通過(guò)少量修改得到解決？是否有什么設(shè)計(jì)模式可以利用呢？

首先想到在spring的applicationContext中配置所有的dataSource。這些dataSource可能是各種不同類(lèi)型的，比如不同的數(shù)據(jù)庫(kù)：Oracle、SQL Server、MySQL等，也可能是不同的數(shù)據(jù)源：比如apache 提供的org.apache.commons.dbcp.BasicDataSource、spring提供的org.springframework.jndi.JndiObjectFactoryBean等。然后sessionFactory根據(jù)客戶的每次請(qǐng)求，將dataSource屬性設(shè)置成不同的數(shù)據(jù)源，以到達(dá)切換數(shù)據(jù)源的目的。

spring中用到的包裝器模式在類(lèi)名上有兩種表現(xiàn)：一種是類(lèi)名中含有Wrapper，另一種是類(lèi)名中含有Decorator?；旧隙际莿?dòng)態(tài)地給一個(gè)對(duì)象添加一些額外的職責(zé)。

第六種：代理（Proxy）

為其他對(duì)象提供一種代理以控制對(duì)這個(gè)對(duì)象的訪問(wèn)。  從結(jié)構(gòu)上來(lái)看和Decorator模式類(lèi)似，但Proxy是控制，更像是一種對(duì)功能的限制，而Decorator是增加職責(zé)。
spring的Proxy模式在aop中有體現(xiàn)，比如JdkDynamicAopProxy和Cglib2AopProxy。

第七種：觀察者（Observer）

定義對(duì)象間的一種一對(duì)多的依賴關(guān)系，當(dāng)一個(gè)對(duì)象的狀態(tài)發(fā)生改變時(shí)，所有依賴于它的對(duì)象都得到通知并被自動(dòng)更新。
spring中Observer模式常用的地方是listener的實(shí)現(xiàn)。如ApplicationListener。

第八種：策略（Strategy）

定義一系列的算法，把它們一個(gè)個(gè)封裝起來(lái)，并且使它們可相互替換。本模式使得算法可獨(dú)立于使用它的客戶而變化。
spring中在實(shí)例化對(duì)象的時(shí)候用到Strategy模式
在SimpleInstantiationStrategy中有如下代碼說(shuō)明了策略模式的使用情況：

第九種：模板方法（Template Method）

定義一個(gè)操作中的算法的骨架，而將一些步驟延遲到子類(lèi)中。Template Method使得子類(lèi)可以不改變一個(gè)算法的結(jié)構(gòu)即可重定義該算法的某些特定步驟。
Template Method模式一般是需要繼承的。這里想要探討另一種對(duì)Template Method的理解。

spring中的JdbcTemplate，在用這個(gè)類(lèi)時(shí)并不想去繼承這個(gè)類(lèi)，因?yàn)檫@個(gè)類(lèi)的方法太多，但是我們還是想用到JdbcTemplate已有的穩(wěn)定的、公用的數(shù)據(jù)庫(kù)連接，那么我們?cè)趺崔k呢？我們可以把變化的東西抽出來(lái)作為一個(gè)參數(shù)傳入JdbcTemplate的方法中。但是變化的東西是一段代碼，而且這段代碼會(huì)用到JdbcTemplate中的變量。

怎么辦？那我們就用回調(diào)對(duì)象吧。在這個(gè)回調(diào)對(duì)象中定義一個(gè)操縱JdbcTemplate中變量的方法，我們?nèi)?shí)現(xiàn)這個(gè)方法，就把變化的東西集中到這里了。然后我們?cè)賯魅脒@個(gè)回調(diào)對(duì)象到JdbcTemplate，從而完成了調(diào)用。這可能是Template Method不需要繼承的另一種實(shí)現(xiàn)方式吧。

本系列文章將整理到我在GitHub上的《Java面試指南》倉(cāng)庫(kù)，更多精彩內(nèi)容請(qǐng)到我的倉(cāng)庫(kù)里查看

https://github.com/h3pl/Java-Tutorial

喜歡的話麻煩點(diǎn)下Star、fork哈

文章也將發(fā)表在我的個(gè)人博客，閱讀體驗(yàn)更佳：

www.how2playlife.com

結(jié)構(gòu)型模式

前面創(chuàng)建型模式介紹了創(chuàng)建對(duì)象的一些設(shè)計(jì)模式，這節(jié)介紹的結(jié)構(gòu)型模式旨在通過(guò)改變代碼結(jié)構(gòu)來(lái)達(dá)到解耦的目的，使得我們的代碼容易維護(hù)和擴(kuò)展。

代理模式

第一個(gè)要介紹的代理模式是最常使用的模式之一了，用一個(gè)代理來(lái)隱藏具體實(shí)現(xiàn)類(lèi)的實(shí)現(xiàn)細(xì)節(jié)，通常還用于在真實(shí)的實(shí)現(xiàn)的前后添加一部分邏輯。

既然說(shuō)是代理，那就要對(duì)客戶端隱藏真實(shí)實(shí)現(xiàn)，由代理來(lái)負(fù)責(zé)客戶端的所有請(qǐng)求。當(dāng)然，代理只是個(gè)代理，它不會(huì)完成實(shí)際的業(yè)務(wù)邏輯，而是一層皮而已，但是對(duì)于客戶端來(lái)說(shuō)，它必須表現(xiàn)得就是客戶端需要的真實(shí)實(shí)現(xiàn)。

理解代理這個(gè)詞，這個(gè)模式其實(shí)就簡(jiǎn)單了。

public interface FoodService {
    Food makeChicken();
    Food makeNoodle();
}
public class FoodServiceImpl implements FoodService {
    public Food makeChicken() {
          Food f = new Chicken()
        f.setChicken("1kg");
          f.setSpicy("1g");
          f.setSalt("3g");
        return f;
    }
    public Food makeNoodle() {
        Food f = new Noodle();
        f.setNoodle("500g");
        f.setSalt("5g");
        return f;
    }
}
// 代理要表現(xiàn)得“就像是”真實(shí)實(shí)現(xiàn)類(lèi)，所以需要實(shí)現(xiàn) FoodService
public class FoodServiceProxy implements FoodService {
    // 內(nèi)部一定要有一個(gè)真實(shí)的實(shí)現(xiàn)類(lèi)，當(dāng)然也可以通過(guò)構(gòu)造方法注入
    private FoodService foodService = new FoodServiceImpl();
    public Food makeChicken() {
        System.out.println("我們馬上要開(kāi)始制作雞肉了");
        // 如果我們定義這句為核心代碼的話，那么，核心代碼是真實(shí)實(shí)現(xiàn)類(lèi)做的，
        // 代理只是在核心代碼前后做些“無(wú)足輕重”的事情
        Food food = foodService.makeChicken();
        System.out.println("雞肉制作完成啦，加點(diǎn)胡椒粉"); // 增強(qiáng)
          food.addCondiment("pepper");
        return food;
    }
    public Food makeNoodle() {
        System.out.println("準(zhǔn)備制作拉面~");
        Food food = foodService.makeNoodle();
        System.out.println("制作完成啦")
        return food;
    }
}

客戶端調(diào)用，注意，我們要用代理來(lái)實(shí)例化接口：

// 這里用代理類(lèi)來(lái)實(shí)例化
FoodService foodService = new FoodServiceProxy();
foodService.makeChicken();

我們發(fā)現(xiàn)沒(méi)有，代理模式說(shuō)白了就是做 “方法包裝” 或做 “方法增強(qiáng)”。在面向切面編程中，算了還是不要吹捧這個(gè)名詞了，在 AOP 中，其實(shí)就是動(dòng)態(tài)代理的過(guò)程。比如 Spring 中，我們自己不定義代理類(lèi)，但是 Spring 會(huì)幫我們動(dòng)態(tài)來(lái)定義代理，然后把我們定義在 @Before、 @After、 @Around 中的代碼邏輯動(dòng)態(tài)添加到代理中。

說(shuō)到動(dòng)態(tài)代理，又可以展開(kāi)說(shuō) …… Spring 中實(shí)現(xiàn)動(dòng)態(tài)代理有兩種，一種是如果我們的類(lèi)定義了接口，如 UserService 接口和 UserServiceImpl 實(shí)現(xiàn)，那么采用 JDK 的動(dòng)態(tài)代理，感興趣的讀者可以去看看 java.lang.reflect.Proxy 類(lèi)的源碼；另一種是我們自己沒(méi)有定義接口的，Spring 會(huì)采用 CGLIB 進(jìn)行動(dòng)態(tài)代理，它是一個(gè) jar 包，性能還不錯(cuò)。

適配器模式

說(shuō)完代理模式，說(shuō)適配器模式，是因?yàn)樗鼈兒芟嗨?，這里可以做個(gè)比較。

適配器模式做的就是，有一個(gè)接口需要實(shí)現(xiàn)，但是我們現(xiàn)成的對(duì)象都不滿足，需要加一層適配器來(lái)進(jìn)行適配。

適配器模式總體來(lái)說(shuō)分三種：默認(rèn)適配器模式、對(duì)象適配器模式、類(lèi)適配器模式。先不急著分清楚這幾個(gè)，先看看例子再說(shuō)。

默認(rèn)適配器模式

首先，我們先看看最簡(jiǎn)單的適配器模式默認(rèn)適配器模式(Default Adapter)是怎么樣的。

我們用 Appache commons-io 包中的 FileAlterationListener 做例子，此接口定義了很多的方法，用于對(duì)文件或文件夾進(jìn)行監(jiān)控，一旦發(fā)生了對(duì)應(yīng)的操作，就會(huì)觸發(fā)相應(yīng)的方法。

public interface FileAlterationListener {
    void onStart(final FileAlterationObserver observer);
    void onDirectoryCreate(final File directory);
    void onDirectoryChange(final File directory);
    void onDirectoryDelete(final File directory);
    void onFileCreate(final File file);
    void onFileChange(final File file);
    void onFileDelete(final File file);
    void onStop(final FileAlterationObserver observer);
}

此接口的一大問(wèn)題是抽象方法太多了，如果我們要用這個(gè)接口，意味著我們要實(shí)現(xiàn)每一個(gè)抽象方法，如果我們只是想要監(jiān)控文件夾中的文件創(chuàng)建和文件刪除事件，可是我們還是不得不實(shí)現(xiàn)所有的方法，很明顯，這不是我們想要的。

所以，我們需要下面的一個(gè)適配器，它用于實(shí)現(xiàn)上面的接口，但是所有的方法都是空方法，這樣，我們就可以轉(zhuǎn)而定義自己的類(lèi)來(lái)繼承下面這個(gè)類(lèi)即可。

public class FileAlterationListenerAdaptor implements FileAlterationListener {
    public void onStart(final FileAlterationObserver observer) {
    }
    public void onDirectoryCreate(final File directory) {
    }
    public void onDirectoryChange(final File directory) {
    }
    public void onDirectoryDelete(final File directory) {
    }
    public void onFileCreate(final File file) {
    }
    public void onFileChange(final File file) {
    }
    public void onFileDelete(final File file) {
    }
    public void onStop(final FileAlterationObserver observer) {
    }
}

比如我們可以定義以下類(lèi)，我們僅僅需要實(shí)現(xiàn)我們想實(shí)現(xiàn)的方法就可以了：

public class FileMonitor extends FileAlterationListenerAdaptor {
    public void onFileCreate(final File file) {
        // 文件創(chuàng)建
        doSomething();
    }
    public void onFileDelete(final File file) {
        // 文件刪除
        doSomething();
    }
}

當(dāng)然，上面說(shuō)的只是適配器模式的其中一種，也是最簡(jiǎn)單的一種，無(wú)需多言。下面，再介紹“正統(tǒng)的”適配器模式。

對(duì)象適配器模式

來(lái)看一個(gè)《Head First 設(shè)計(jì)模式》中的一個(gè)例子，我稍微修改了一下，看看怎么將雞適配成鴨，這樣雞也能當(dāng)鴨來(lái)用。因?yàn)椋F(xiàn)在鴨這個(gè)接口，我們沒(méi)有合適的實(shí)現(xiàn)類(lèi)可以用，所以需要適配器。

public interface Duck {
    public void quack(); // 鴨的呱呱叫
      public void fly(); // 飛
}
public interface Cock {
    public void gobble(); // 雞的咕咕叫
      public void fly(); // 飛
}
public class WildCock implements Cock {
    public void gobble() {
        System.out.println("咕咕叫");
    }
      public void fly() {
        System.out.println("雞也會(huì)飛哦");
    }
}

鴨接口有 fly() 和 quare() 兩個(gè)方法，雞 Cock 如果要冒充鴨，fly() 方法是現(xiàn)成的，但是雞不會(huì)鴨的呱呱叫，沒(méi)有 quack() 方法。這個(gè)時(shí)候就需要適配了：

// 毫無(wú)疑問(wèn)，首先，這個(gè)適配器肯定需要 implements Duck，這樣才能當(dāng)做鴨來(lái)用
public class CockAdapter implements Duck {
    Cock cock;
    // 構(gòu)造方法中需要一個(gè)雞的實(shí)例，此類(lèi)就是將這只雞適配成鴨來(lái)用
      public CockAdapter(Cock cock) {
        this.cock = cock;
    }
    // 實(shí)現(xiàn)鴨的呱呱叫方法
      @Override
      public void quack() {
        // 內(nèi)部其實(shí)是一只雞的咕咕叫
        cock.gobble();
    }
      @Override
      public void fly() {
        cock.fly();
    }
}

客戶端調(diào)用很簡(jiǎn)單了：

public static void main(String[] args) {
    // 有一只野雞
      Cock wildCock = new WildCock();
      // 成功將野雞適配成鴨
      Duck duck = new CockAdapter(wildCock);
      ...
}

到這里，大家也就知道了適配器模式是怎么回事了。無(wú)非是我們需要一只鴨，但是我們只有一只雞，這個(gè)時(shí)候就需要定義一個(gè)適配器，由這個(gè)適配器來(lái)充當(dāng)鴨，但是適配器里面的方法還是由雞來(lái)實(shí)現(xiàn)的。

我們用一個(gè)圖來(lái)簡(jiǎn)單說(shuō)明下：

上圖應(yīng)該還是很容易理解的，我就不做更多的解釋了。下面，我們看看類(lèi)適配模式怎么樣的。

類(lèi)適配器模式

廢話少說(shuō)，直接上圖：

看到這個(gè)圖，大家應(yīng)該很容易理解的吧，通過(guò)繼承的方法，適配器自動(dòng)獲得了所需要的大部分方法。這個(gè)時(shí)候，客戶端使用更加簡(jiǎn)單，直接 Target t = new SomeAdapter(); 就可以了。

適配器模式總結(jié)

1. 類(lèi)適配和對(duì)象適配的異同

   一個(gè)采用繼承，一個(gè)采用組合；

   類(lèi)適配屬于靜態(tài)實(shí)現(xiàn)，對(duì)象適配屬于組合的動(dòng)態(tài)實(shí)現(xiàn)，對(duì)象適配需要多實(shí)例化一個(gè)對(duì)象。

   總體來(lái)說(shuō)，對(duì)象適配用得比較多。

2. 適配器模式和代理模式的異同

   比較這兩種模式，其實(shí)是比較對(duì)象適配器模式和代理模式，在代碼結(jié)構(gòu)上，它們很相似，都需要一個(gè)具體的實(shí)現(xiàn)類(lèi)的實(shí)例。但是它們的目的不一樣，代理模式做的是增強(qiáng)原方法的活；適配器做的是適配的活，為的是提供“把雞包裝成鴨，然后當(dāng)做鴨來(lái)使用”，而雞和鴨它們之間原本沒(méi)有繼承關(guān)系。

橋梁模式

理解橋梁模式，其實(shí)就是理解代碼抽象和解耦。

我們首先需要一個(gè)橋梁，它是一個(gè)接口，定義提供的接口方法。

public interface DrawAPI {
   public void draw(int radius, int x, int y);
}

然后是一系列實(shí)現(xiàn)類(lèi)：

public class RedPen implements DrawAPI {
   @Override
   public void draw(int radius, int x, int y) {
      System.out.println("用紅色筆畫(huà)圖，radius:" + radius + ", x:" + x + ", y:" + y);
   }
}
public class GreenPen implements DrawAPI {
   @Override
   public void draw(int radius, int x, int y) {
      System.out.println("用綠色筆畫(huà)圖，radius:" + radius + ", x:" + x + ", y:" + y);
   }
}
public class BluePen implements DrawAPI {
   @Override
   public void draw(int radius, int x, int y) {
      System.out.println("用藍(lán)色筆畫(huà)圖，radius:" + radius + ", x:" + x + ", y:" + y);
   }
}

定義一個(gè)抽象類(lèi)，此類(lèi)的實(shí)現(xiàn)類(lèi)都需要使用 DrawAPI：

public abstract class Shape {
   protected DrawAPI drawAPI;
   protected Shape(DrawAPI drawAPI){
      this.drawAPI = drawAPI;
   }
   public abstract void draw();    
}

定義抽象類(lèi)的子類(lèi)：

// 圓形
public class Circle extends Shape {
   private int radius;
   public Circle(int radius, DrawAPI drawAPI) {
      super(drawAPI);
      this.radius = radius;
   }
   public void draw() {
      drawAPI.draw(radius, 0, 0);
   }
}
// 長(zhǎng)方形
public class Rectangle extends Shape {
    private int x;
      private int y;
      public Rectangle(int x, int y, DrawAPI drawAPI) {
        super(drawAPI);
          this.x = x;
          this.y = y;
    }
      public void draw() {
      drawAPI.draw(0, x, y);
   }
}

最后，我們來(lái)看客戶端演示：

public static void main(String[] args) {
    Shape greenCircle = new Circle(10, new GreenPen());
      Shape redRectangle = new Rectangle(4, 8, new RedPen());
      greenCircle.draw();
      redRectangle.draw();
}

可能大家看上面一步步還不是特別清晰，我把所有的東西整合到一張圖上：

這回大家應(yīng)該就知道抽象在哪里，怎么解耦了吧。橋梁模式的優(yōu)點(diǎn)也是顯而易見(jiàn)的，就是非常容易進(jìn)行擴(kuò)展。

本節(jié)引用了 這里的例子，并對(duì)其進(jìn)行了修改。

裝飾模式

要把裝飾模式說(shuō)清楚明白，不是件容易的事情。也許讀者知道 Java IO 中的幾個(gè)類(lèi)是典型的裝飾模式的應(yīng)用，但是讀者不一定清楚其中的關(guān)系，也許看完就忘了，希望看完這節(jié)后，讀者可以對(duì)其有更深的感悟。

首先，我們先看一個(gè)簡(jiǎn)單的圖，看這個(gè)圖的時(shí)候，了解下層次結(jié)構(gòu)就可以了：

我們來(lái)說(shuō)說(shuō)裝飾模式的出發(fā)點(diǎn)，從圖中可以看到，接口 Component 其實(shí)已經(jīng)有了 ConcreteComponentA 和 ConcreteComponentB 兩個(gè)實(shí)現(xiàn)類(lèi)了，但是，如果我們要增強(qiáng)這兩個(gè)實(shí)現(xiàn)類(lèi)的話，我們就可以采用裝飾模式，用具體的裝飾器來(lái)裝飾實(shí)現(xiàn)類(lèi)，以達(dá)到增強(qiáng)的目的。

從名字來(lái)簡(jiǎn)單解釋下裝飾器。既然說(shuō)是裝飾，那么往往就是添加小功能這種，而且，我們要滿足可以添加多個(gè)小功能。最簡(jiǎn)單的，代理模式就可以實(shí)現(xiàn)功能的增強(qiáng)，但是代理不容易實(shí)現(xiàn)多個(gè)功能的增強(qiáng)，當(dāng)然你可以說(shuō)用代理包裝代理的方式，但是那樣的話代碼就復(fù)雜了。

首先明白一些簡(jiǎn)單的概念，從圖中我們看到，所有的具體裝飾者們 ConcreteDecorator 都可以作為 Component 來(lái)使用，因?yàn)樗鼈兌紝?shí)現(xiàn)了 Component 中的所有接口。它們和 Component 實(shí)現(xiàn)類(lèi) ConcreteComponent 的區(qū)別是，它們只是裝飾者，起裝飾作用，也就是即使它們看上去牛逼轟轟，但是它們都只是在具體的實(shí)現(xiàn)中加了層皮來(lái)裝飾而已。

注意這段話中混雜在各個(gè)名詞中的 Component 和 Decorator，別搞混了。

下面來(lái)看看一個(gè)例子，先把裝飾模式弄清楚，然后再介紹下 java io 中的裝飾模式的應(yīng)用。

最近大街上流行起來(lái)了“快樂(lè)檸檬”，我們把快樂(lè)檸檬的飲料分為三類(lèi)：紅茶、綠茶、咖啡，在這三大類(lèi)的基礎(chǔ)上，又增加了許多的口味，什么金桔檸檬紅茶、金桔檸檬珍珠綠茶、芒果紅茶、芒果綠茶、芒果珍珠紅茶、烤珍珠紅茶、烤珍珠芒果綠茶、椰香胚芽咖啡、焦糖可可咖啡等等，每家店都有很長(zhǎng)的菜單，但是仔細(xì)看下，其實(shí)原料也沒(méi)幾樣，但是可以搭配出很多組合，如果顧客需要，很多沒(méi)出現(xiàn)在菜單中的飲料他們也是可以做的。

在這個(gè)例子中，紅茶、綠茶、咖啡是最基礎(chǔ)的飲料，其他的像金桔檸檬、芒果、珍珠、椰果、焦糖等都屬于裝飾用的。當(dāng)然，在開(kāi)發(fā)中，我們確實(shí)可以像門(mén)店一樣，開(kāi)發(fā)這些類(lèi)：LemonBlackTea、LemonGreenTea、MangoBlackTea、MangoLemonGreenTea……但是，很快我們就發(fā)現(xiàn)，這樣子干肯定是不行的，這會(huì)導(dǎo)致我們需要組合出所有的可能，而且如果客人需要在紅茶中加雙份檸檬怎么辦？三份檸檬怎么辦？萬(wàn)一有個(gè)變態(tài)要四份檸檬，所以這種做法是給自己找加班的。

不說(shuō)廢話了，上代碼。

首先，定義飲料抽象基類(lèi)：

public abstract class Beverage {
      // 返回描述
      public abstract String getDescription();
      // 返回價(jià)格
      public abstract double cost();
}

然后是三個(gè)基礎(chǔ)飲料實(shí)現(xiàn)類(lèi)，紅茶、綠茶和咖啡：

public class BlackTea extends Beverage {
      public String getDescription() {
        return "紅茶";
    }
      public double cost() {
        return 10;
    }
}
public class GreenTea extends Beverage {
    public String getDescription() {
        return "綠茶";
    }
      public double cost() {
        return 11;
    }
}
...// 咖啡省略

定義調(diào)料，也就是裝飾者的基類(lèi)，此類(lèi)必須繼承自 Beverage：

// 調(diào)料
public abstract class Condiment extends Beverage {
}

然后我們來(lái)定義檸檬、芒果等具體的調(diào)料，它們屬于裝飾者，毫無(wú)疑問(wèn)，這些調(diào)料肯定都需要繼承 Condiment 類(lèi)：

public class Lemon extends Condiment {
    private Beverage bevarage;
      // 這里很關(guān)鍵，需要傳入具體的飲料，如需要傳入沒(méi)有被裝飾的紅茶或綠茶，
      // 當(dāng)然也可以傳入已經(jīng)裝飾好的芒果綠茶，這樣可以做芒果檸檬綠茶
      public Lemon(Beverage bevarage) {
        this.bevarage = bevarage;
    }
      public String getDescription() {
        // 裝飾
        return bevarage.getDescription() + ", 加檸檬";
    }
      public double cost() {
          // 裝飾
        return beverage.cost() + 2; // 加檸檬需要 2 元
    }
}
public class Mango extends Condiment {
    private Beverage bevarage;
      public Mango(Beverage bevarage) {
        this.bevarage = bevarage;
    }
      public String getDescription() {
        return bevarage.getDescription() + ", 加芒果";
    }
      public double cost() {
        return beverage.cost() + 3; // 加芒果需要 3 元
    }
}
...// 給每一種調(diào)料都加一個(gè)類(lèi)

看客戶端調(diào)用：

public static void main(String[] args) {
      // 首先，我們需要一個(gè)基礎(chǔ)飲料，紅茶、綠茶或咖啡
    Beverage beverage = new GreenTea();
      // 開(kāi)始裝飾
      beverage = new Lemon(beverage); // 先加一份檸檬
      beverage = new Mongo(beverage); // 再加一份芒果
      System.out.println(beverage.getDescription() + " 價(jià)格：￥" + beverage.cost());
      //"綠茶, 加檸檬, 加芒果 價(jià)格：￥16"
}

如果我們需要芒果珍珠雙份檸檬紅茶：

Beverage beverage = new Mongo(new Pearl(new Lemon(new Lemon(new BlackTea()))));

是不是很變態(tài)？

看看下圖可能會(huì)清晰一些：

到這里，大家應(yīng)該已經(jīng)清楚裝飾模式了吧。

下面，我們?cè)賮?lái)說(shuō)說(shuō) java IO 中的裝飾模式。看下圖 InputStream 派生出來(lái)的部分類(lèi)：

我們知道 InputStream 代表了輸入流，具體的輸入來(lái)源可以是文件（FileInputStream）、管道（PipedInputStream）、數(shù)組（ByteArrayInputStream）等，這些就像前面奶茶的例子中的紅茶、綠茶，屬于基礎(chǔ)輸入流。

FilterInputStream 承接了裝飾模式的關(guān)鍵節(jié)點(diǎn)，其實(shí)現(xiàn)類(lèi)是一系列裝飾器，比如 BufferedInputStream 代表用緩沖來(lái)裝飾，也就使得輸入流具有了緩沖的功能，LineNumberInputStream 代表用行號(hào)來(lái)裝飾，在操作的時(shí)候就可以取得行號(hào)了，DataInputStream 的裝飾，使得我們可以從輸入流轉(zhuǎn)換為 java 中的基本類(lèi)型值。

當(dāng)然，在 java IO 中，如果我們使用裝飾器的話，就不太適合面向接口編程了，如：

InputStream inputStream = new LineNumberInputStream(new BufferedInputStream(new FileInputStream("")));

這樣的結(jié)果是，InputStream 還是不具有讀取行號(hào)的功能，因?yàn)樽x取行號(hào)的方法定義在 LineNumberInputStream 類(lèi)中。

我們應(yīng)該像下面這樣使用：

DataInputStream is = new DataInputStream(
                              new BufferedInputStream(
                                  new FileInputStream("")));

所以說(shuō)嘛，要找到純的嚴(yán)格符合設(shè)計(jì)模式的代碼還是比較難的。

門(mén)面模式

門(mén)面模式（也叫外觀模式，F(xiàn)acade Pattern）在許多源碼中有使用，比如 slf4j 就可以理解為是門(mén)面模式的應(yīng)用。這是一個(gè)簡(jiǎn)單的設(shè)計(jì)模式，我們直接上代碼再說(shuō)吧。

首先，我們定義一個(gè)接口：

public interface Shape {
   void draw();
}

定義幾個(gè)實(shí)現(xiàn)類(lèi)：

public class Circle implements Shape {
   @Override
   public void draw() {
      System.out.println("Circle::draw()");
   }
}
public class Rectangle implements Shape {
   @Override
   public void draw() {
      System.out.println("Rectangle::draw()");
   }
}

客戶端調(diào)用：

public static void main(String[] args) {
    // 畫(huà)一個(gè)圓形
      Shape circle = new Circle();
      circle.draw();
      // 畫(huà)一個(gè)長(zhǎng)方形
      Shape rectangle = new Rectangle();
      rectangle.draw();
}

以上是我們常寫(xiě)的代碼，我們需要畫(huà)圓就要先實(shí)例化圓，畫(huà)長(zhǎng)方形就需要先實(shí)例化一個(gè)長(zhǎng)方形，然后再調(diào)用相應(yīng)的 draw() 方法。

下面，我們看看怎么用門(mén)面模式來(lái)讓客戶端調(diào)用更加友好一些。

我們先定義一個(gè)門(mén)面：

public class ShapeMaker {
   private Shape circle;
   private Shape rectangle;
   private Shape square;
   public ShapeMaker() {
      circle = new Circle();
      rectangle = new Rectangle();
      square = new Square();
   }
  /**
   * 下面定義一堆方法，具體應(yīng)該調(diào)用什么方法，由這個(gè)門(mén)面來(lái)決定
   */
   public void drawCircle(){
      circle.draw();
   }
   public void drawRectangle(){
      rectangle.draw();
   }
   public void drawSquare(){
      square.draw();
   }
}

看看現(xiàn)在客戶端怎么調(diào)用：

public static void main(String[] args) {
  ShapeMaker shapeMaker = new ShapeMaker();
  // 客戶端調(diào)用現(xiàn)在更加清晰了
  shapeMaker.drawCircle();
  shapeMaker.drawRectangle();
  shapeMaker.drawSquare();        
}

門(mén)面模式的優(yōu)點(diǎn)顯而易見(jiàn)，客戶端不再需要關(guān)注實(shí)例化時(shí)應(yīng)該使用哪個(gè)實(shí)現(xiàn)類(lèi)，直接調(diào)用門(mén)面提供的方法就可以了，因?yàn)殚T(mén)面類(lèi)提供的方法的方法名對(duì)于客戶端來(lái)說(shuō)已經(jīng)很友好了。

組合模式

組合模式用于表示具有層次結(jié)構(gòu)的數(shù)據(jù)，使得我們對(duì)單個(gè)對(duì)象和組合對(duì)象的訪問(wèn)具有一致性。

直接看一個(gè)例子吧，每個(gè)員工都有姓名、部門(mén)、薪水這些屬性，同時(shí)還有下屬員工集合（雖然可能集合為空），而下屬員工和自己的結(jié)構(gòu)是一樣的，也有姓名、部門(mén)這些屬性，同時(shí)也有他們的下屬員工集合。

public class Employee {
   private String name;
   private String dept;
   private int salary;
   private List<Employee> subordinates; // 下屬
   public Employee(String name,String dept, int sal) {
      this.name = name;
      this.dept = dept;
      this.salary = sal;
      subordinates = new ArrayList<Employee>();
   }
   public void add(Employee e) {
      subordinates.add(e);
   }
   public void remove(Employee e) {
      subordinates.remove(e);
   }
   public List<Employee> getSubordinates(){
     return subordinates;
   }
   public String toString(){
      return ("Employee :[ Name : " + name + ", dept : " + dept + ", salary :" + salary+" ]");
   }   
}

通常，這種類(lèi)需要定義 add(node)、remove(node)、getChildren() 這些方法。

這說(shuō)的其實(shí)就是組合模式，這種簡(jiǎn)單的模式我就不做過(guò)多介紹了，相信各位讀者也不喜歡看我寫(xiě)廢話。

享元模式

英文是 Flyweight Pattern，不知道是誰(shuí)最先翻譯的這個(gè)詞，感覺(jué)這翻譯真的不好理解，我們?cè)囍鴱?qiáng)行關(guān)聯(lián)起來(lái)吧。Flyweight 是輕量級(jí)的意思，享元分開(kāi)來(lái)說(shuō)就是 共享 元器件，也就是復(fù)用已經(jīng)生成的對(duì)象，這種做法當(dāng)然也就是輕量級(jí)的了。

復(fù)用對(duì)象最簡(jiǎn)單的方式是，用一個(gè) HashMap 來(lái)存放每次新生成的對(duì)象。每次需要一個(gè)對(duì)象的時(shí)候，先到 HashMap 中看看有沒(méi)有，如果沒(méi)有，再生成新的對(duì)象，然后將這個(gè)對(duì)象放入 HashMap 中。

這種簡(jiǎn)單的代碼我就不演示了。

到此，關(guān)于“Spring中常用的9種設(shè)計(jì)模式介紹”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請(qǐng)繼續(xù)關(guān)注億速云網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)?lái)更多實(shí)用的文章！