一、前言

說起來設計模式，大家應該都耳熟能詳，設計模式代表了軟體設計的最佳實踐，是經過不斷總結提煉出來的程式碼設計經驗的分類總結，這些模式或者可以簡化程式碼，或者可以是程式碼邏輯開起來清晰，或者對功能擴充套件很方便…。

設計模式按照使用場景可以分為三大類：建立型模式（Creational Patterns）、結構型模式（Structural Patterns）、行為型模式（Behavioral Patterns）。

• 建立型模式（Creational Patterns）
  對物件的例項化過程進行抽象，這使得一個系統可以不用關心這些物件是如何建立，組合，呈現的，對於類建立模式來說通過使用繼承改變例項化的類，對於物件建立模式來說通過使用代理來例項化所需要的物件。

• 結構型模式（Structural Patterns）
  通過對多個類和物件進行組合得到複雜結構的類，一般使用繼承繼承或者成員變數引用形式來實現。

• 行為型模式（Behavioral Patterns）
  行為模式不僅表達了物件和類，還表達了他們之間的互動，涉及到了物件和演算法的分配。

下面就帶大家看下開源框架框架中是如何應用這些經典設計模式的。

二、責任鏈設計模式（Chain of Responsibility Pattern）

2.1 介紹

責任鏈模式是把多個物件串聯起來形成一個鏈狀結構，讓每個物件都有機會對事件傳送者的請求進行處理。責任鏈模式是設計模式中的行為模式，設計意圖是為了使事件傳送者和事件接受者之間解耦。通常責任鏈鏈中的每個物件都有下一個物件的引入（例如tomcat 裡面StandardPipeline用來管理valve），或者有個同一個鏈管理工廠裡面使用陣列存放了所有的物件（例如tomcat裡面ApplicationFilterChain用來關係filter）。

2.2 Tomcat中Valve鏈

Tomcat中StandardEngine,StandardHost,StandardContext裡面都有自己StandardPipeline,下面以StandardEngine裡面StandardPipeline為例講解

image.png

從上面類圖可知道每個Valve都要繼承ValveBase類，該類裡面有一個Valve的引用，實際是鏈中下一個節點物件，Valve就是通過每個Valve裡面的next串聯為鏈的。

每個valve的invoke方法裡面呼叫next.invoke啟用鏈中下一個節點,並且StandardEngine,StandardHost,StandardContext都有一個basic valve這個valve在鏈的末尾用來啟用子容器的valve鏈。

2.3 Tomcat中Filter鏈

Tomcat中Filter鏈是使用ApplicationFilterChain來管理的，具體結構如下圖：

可知Filter鏈不是像Valve一樣在內部維護下個節點的引用，而是在ApplicationFilterChain中搞了個數組存放所有的Filter，並通過n統計Filter總個數，pos是當前filter的下標。

ApplicationFilterChain的doFilter程式碼如下：

public void doFilter(ServletRequest request, ServletResponse response)
        throws IOException, ServletException {
        ...
        internalDoFilter(request,response);
        ...
    }

private void internalDoFilter(ServletRequest request, 
                                  ServletResponse response)
        throws IOException, ServletException {

        // Call the next filter if there is one
        if (pos < n) {

            //獲取filter鏈中下標為pos的filter
            ApplicationFilterConfig filterConfig = filters[pos++];
            Filter filter = null;
            try {
                filter = filterConfig.getFilter();
                support.fireInstanceEvent(InstanceEvent.BEFORE_FILTER_EVENT,
                                          filter, request, response);

                if (request.isAsyncSupported() && "false".equalsIgnoreCase(
                        filterConfig.getFilterDef().getAsyncSupported())) {
                    request.setAttribute(Globals.ASYNC_SUPPORTED_ATTR,
                            Boolean.FALSE);
                }

                ...

                //呼叫自定義filter的dofilter方法
                filter.doFilter(request, response, this);

                support.fireInstanceEvent(InstanceEvent.AFTER_FILTER_EVENT,
                                          filter, request, response);
            } 
            ....

    }
   .....
}

注：這兩種方式的區別是啥,就是說那些場景下使用2.2，什麼情況下使用2.3這個目前還沒有搞清楚有
知道的麻煩在本帖留言幫我解惑下^^

2.4 使用場景

• 當一個請求需要
  根據請求引數的不同由不同物件來處理時候。
• 當一個請求需要固定物件順序處理，並且可擴充套件性的在固定順序裡面插入新的物件進行處理時候。

三、工廠模式（Factory Pattern）

3.1 介紹

工廠模式是建立型模式，他封裝了物件的建立過程，呼叫者使用具體的工廠方法根據引數就可以獲取對應的物件。

3.2 Spring框架中BeanFactory

如圖BeanFactory介面提供了getBean方法，在AbstractBeanFactory中實現了該方法，經過層層繼承，實現，最後DefaultListableBeanFactory實現了BeanDefinitionRegistry介面用來儲存bean定義，繼承了AbstractAutowireCapableBeanFactory用來支撐autowired。

一個例子

@Test
public void testBeanFactoy() throws NamingException, SQLException, ParseException, IOException {

    //建立Bean工廠
    DefaultListableBeanFactory bf = new DefaultListableBeanFactory();

    //給bean工廠新增bean定義,解析xml裡面的bean放入bean工廠
    loadBeanDefinitions(bf);

    //根據名字從bean工廠獲取bean
    Hello hello = (Hello) bf.getBean("hello");
    hello.sayHello();

    Hello2 hello2 = (Hello2) bf.getBean("hello2");
    hello2.sayHello();

}

protected void loadBeanDefinitions(DefaultListableBeanFactory beanFactory) throws IOException {
    XmlBeanDefinitionReader beanDefinitionReader = new XmlBeanDefinitionReader(beanFactory);

    String[] configLocations = new String[] { "beans2.xml" };
    if (configLocations != null) {
        beanDefinitionReader.loadBeanDefinitions(configLocations);
    }
}

3.3 使用場景

• 不同條件下建立不同例項，用於統一管理bean
• 不同條件下呼叫不同工廠方法獲取不同場景下的bean

四、單例設計模式（Singleton Pattern）

4.1 介紹

單例模式是一種建立型模式，單例模式提供一個建立物件的介面，但是多次呼叫該介面返回的是同一個例項的引用，目的是為了保證只有一個例項，並且提供一個訪問這個例項的統一介面。

4.2 Spring中單例bean的建立

Spring中預設配置的bean的scope為singleton，也就是單例作用域。那麼看看它是如何做到的。
在AbstractBeanFactory類裡面的doGetBean方法：

protected Object doGetBean(
            final String name, final Class requiredType, final Object[] args, boolean typeCheckOnly) throws BeansException {

    final String beanName = transformedBeanName(name);
    Object bean = null;

    // 解決set迴圈依賴
    Object sharedInstance = getSingleton(beanName);
    if (sharedInstance != null && args == null) {
        ...
    }

    else {
        ...
        // 建立單件bean.
        if (mbd.isSingleton()) {
            sharedInstance = getSingleton(beanName, new ObjectFactory() {
                public Object getObject() throws BeansException {
                    try {
                        return createBean(beanName, mbd, args);
                    }
                    catch (BeansException ex) {
                    ...
                        throw ex;
                    }
                }
            });
            bean = getObjectForBeanInstance(sharedInstance, name, beanName, mbd);
        }
       //建立原型bean
        else if (mbd.isPrototype()) {
            ...
        }
        //建立request作用域bean
        else {
            ...
        }
    }
            ...
    return bean;
}

getSingleton程式碼：

public Object getSingleton(String beanName, ObjectFactory singletonFactory) {
    Assert.notNull(beanName, "'beanName' must not be null");
    synchronized (this.singletonObjects) {
        Object singletonObject = this.singletonObjects.get(beanName);
        if (singletonObject == null) {
            ...
            beforeSingletonCreation(beanName);
            ...
            try {
                singletonObject = singletonFactory.getObject();
            }
            catch (BeanCreationException ex) {
                ...
            }
            finally {
                if (recordSuppressedExceptions) {
                    this.suppressedExceptions = null;
                }
                afterSingletonCreation(beanName);
            }
            addSingleton(beanName, singletonObject);
        }
        return (singletonObject != NULL_OBJECT ? singletonObject : null);
    }
}

protected void addSingleton(String beanName, Object singletonObject) {
    synchronized (this.singletonObjects) {
        this.singletonObjects.put(beanName, (singletonObject != null ? singletonObject : NULL_OBJECT));
        this.singletonFactories.remove(beanName);
        this.earlySingletonObjects.remove(beanName);
        this.registeredSingletons.add(beanName);
    }
}

private final Map singletonObjects = CollectionFactory.createConcurrentMapIfPossible(16);

可知Spring內部四通過一個ConcurrentMap來管理單件bean的。獲取bean時候會先看看singletonObjects中是否有，有則直接返回，沒有則建立後放入。

看個時序圖：

Spring的bean工廠管理的單例模式管理的是多個bean例項的單例，是工廠模式管理所有的bean,而每個bean的建立又使用了單例模式。

4.4 使用場景

• 同一個jvm應用的不同模組需要使用同一個物件例項進行資訊共享。
• 需要同一個例項來生成全域性統一的序列號

五、原型設計模式（Prototype Pattern）

5.1 介紹

相比單例設計模式，原型模式是每次建立一個物件，下面看下spring是如何使用原型模式的

5.2 Spring中原型bean的建立

建立原型bean需要在xml特別說明：

    <bean id="hello" class="com.zlx.demo.Hello" scope="prototype"/>

protected <T> T doGetBean(
        final String name, final Class<T> requiredType, final Object[] args, boolean typeCheckOnly)
        throws BeansException {

    final String beanName = transformedBeanName(name);
    Object bean;

    // Eagerly check singleton cache for manually registered singletons.
    Object sharedInstance = getSingleton(beanName);
    if (sharedInstance != null && args == null) {
     ...
    }

    else {
        ...

        try {
            ...

            // Create bean instance.
            if (mbd.isSingleton()) {
                ...
            }
            //建立原型bean
            else if (mbd.isPrototype()) {
                // It's a prototype -> create a new instance.
                Object prototypeInstance = null;
                try {
                    beforePrototypeCreation(beanName);
                    prototypeInstance = createBean(beanName, mbd, args);
                }
                finally {
                    afterPrototypeCreation(beanName);
                }
                bean = getObjectForBeanInstance(prototypeInstance, name, beanName, mbd);
            }

            else {
                ...
            }
        }
        catch (BeansException ex) {
            cleanupAfterBeanCreationFailure(beanName);
            throw ex;
        }
    }
 ...
    return (T) bean;
}

createBean函式裡面則是根據bean定義建立新bean，感興趣的可以看看。

5.3 使用場景

• 當有業務場景使用某個bean時候需要使用自己的一個拷貝的時候使用。
  特別推薦一個Java架構交流學習群：688583154
  1、具有1-5工作經驗的，面對目前流行的技術不知從何下手，需要突破技術瓶頸的可以加群。
  2、在公司待久了，過得很安逸，但跳槽時面試碰壁。需要在短時間內進修、跳槽拿高薪的可以加群。
  3、如果沒有工作經驗，但基礎非常紮實，對java工作機制，常用設計思想，常用java開發框架掌握熟練的，可以加群。
  4、覺得自己很牛B，一般需求都能搞定。但是所學的知識點沒有系統化，很難在技術領域繼續突破的可以加群。
  5.阿里Java架構師，分享知識，多年工作經驗的梳理和總結，帶著大家全面、科學地建立自己的技術體系和技術認知

六、 策略模式（Strategy Pattern）

6.1 介紹

策略模式屬於行為性模式，它定義一系列的演算法物件,使用時候可以使它們相互替換。

6.2 Spring中bean例項化策略

首先看下類圖：

從圖知道：介面InstantiationStrategy是例項化策略介面類，它定義了三個例項化介面，然後SimpleInstantiationStrategy實現了該策略，它主要做一些簡單的根據建構函式例項號bean的工作，然後CglibSubclassingInstantiationStrategy又繼承了SimpleInstantiationStrategy新增了方法注入方式根據cglib生成代理類例項化方法。

在AbstractAutowireCapableBeanFactory中管理了該策略的一個物件，預設是CglibSubclassingInstantiationStrategy策略，執行時候可以通過setInstantiationStrategy改變例項化策略，如果你自己寫個個策略的話。

6.3 Spring中Aop代理策略

首先看AopProxyFactory介面類提供了createAopProxy介面，這個是策略模式的介面方法。然後DefaultAopProxyFactory實現了該介面作為策略的實現者。然後ProxyCreatorSupport裡面引用了AopProxyFactory，並且提供了get,set方法用來執行時改變策略，這裡Spring只實現了DefaultAopProxyFactory這一個策略，如果需要自己也可以寫個。

DefaultAopProxyFactory裡面的createAopProxy的邏輯如下，可以在執行時根據引數決定用Cglib策略還是JDK動態代理策略生成代理類：

    public AopProxy createAopProxy(AdvisedSupport config) throws AopConfigException {

        //如果XML打開了優化開關，或者設定為了代理目標類，或者目前類沒有介面
        if (config.isOptimize() || config.isProxyTargetClass() || hasNoUserSuppliedProxyInterfaces(config)) {
            Class<?> targetClass = config.getTargetClass();
            if (targetClass == null) {
                throw new AopConfigException("TargetSource cannot determine target class: " +
                        "Either an interface or a target is required for proxy creation.");
            }

            //如果有介面，或者通過Proxy.newProxyInstance生成的，則使用jdk動態代理
            if (targetClass.isInterface() || Proxy.isProxyClass(targetClass)) {
                return new JdkDynamicAopProxy(config);
            }

            //使用cglib
            return new ObjenesisCglibAopProxy(config);
        }
        else {
            //使用jdk動態代理
            return new JdkDynamicAopProxy(config);
        }
    }

另外AopProxy也是一個策略介面類，具體實現的策略為JdkDynamicAopProxy，CglibAopProxy，ObjenesisCglibAopProxy

6.4 Tomcat中Digester解析server.xml

tomcat中的Digester是為了解析server.xml的，其中每個元素都有一個解析規則就是Rule ,類圖如下：
DigestER一開始先指定不同的解析策略（Rule），然後在具體解析Server.xml時候根據節點不同使用不同解析策略來解析節點。

如圖在解析每個節點時候會先找到該節點對應的解析策略，然後迴圈去呼叫所有解析策略的方法去處理。

6.5 使用場景

• 執行時根據條件的不同使用不同的策略處理一個事情，與責任鏈不同在於，責任鏈是一個鏈條，一個事情可以被責任鏈裡面所有節點處理，而 策略模式則是隻有有一個物件來處理。

七、 門面模式（Facade Pattern）

7.1 介紹

門面模式是一種結構性模式，它通過新增一個門面類對外暴露系統提供的一部分功能，或者遮蔽了內部系統的複雜性，對外部僅僅暴露一個簡單的介面，或者通過呼叫不同的服務對外提供統一的介面，讓使用者對這些內部服務透明化。

7.2 模板引擎Velocity中門面模式使用

Velocity裡面的VelocityEngine和Velocity類都是RuntimeInstance類的門面，後者提供了模板渲染的所有功能，前兩者則是內部維護RuntimeInstance的例項，具體工作還是委託給RuntimeInstance來實現。
關於Veloctiy可以參考：https://www.atatech.org/articles/78435

如圖 RuntimeInstance提供了Velocity引擎的所用功能，VelocityEngine內部直接引用了RuntimeInstance的一個例項，VelocityEngine對外暴露的服務都是委託RuntimeInstance實現，並且每次new一個VelocityEngine內部都會有RuntimeInstance的一個例項被建立。而Velocity類呼叫了單例模式類RuntimeSingleton裡面的方法，RuntimeSingleton又是RuntimeInstance的一個單例模式。

7.3 使用場景

• 當需要對外遮蔽一個系統的複雜性時候可以考慮使用門面模式對外提供簡單可讀性高的介面類
• 當需要對外部暴露系統一部分許可權的介面時候可以考慮使用門面模式減少系統許可權。
• 當系統需要呼叫不同服務彙總後在對外提供服務時候可以考慮使用門面模式對外遮蔽細節，之暴露一個介面。

八、裝飾器模式（Decorator Pattern）

8.1 介紹

裝飾器模式是一種結構性模式，它作用是對物件已有功能進行增強，但是不改變原有物件結構。這避免了通過繼承方式進行功能擴充導致的類體系臃腫。

8.2 Spring中BeanDefinitionDecorator

先看下類圖：

如圖ScopedProxyBeanDefinitionDecorator實現了decorate方法用來對scope作用域為request的bean定義進行包裝。
具體時序圖為：

class ScopedProxyBeanDefinitionDecorator implements BeanDefinitionDecorator {

    private static final String PROXY_TARGET_CLASS = "proxy-target-class";

    @Override
    public BeanDefinitionHolder decorate(Node node, BeanDefinitionHolder definition, ParserContext parserContext) {
        boolean proxyTargetClass = true;
        if (node instanceof Element) {
            Element ele = (Element) node;
            if (ele.hasAttribute(PROXY_TARGET_CLASS)) {
                proxyTargetClass = Boolean.valueOf(ele.getAttribute(PROXY_TARGET_CLASS));
            }
        }

        // 建立scoped的代理類，並註冊到容器
        BeanDefinitionHolder holder =
                ScopedProxyUtils.createScopedProxy(definition, parserContext.getRegistry(), proxyTargetClass);
        String targetBeanName = ScopedProxyUtils.getTargetBeanName(definition.getBeanName());
        parserContext.getReaderContext().fireComponentRegistered(
                new BeanComponentDefinition(definition.getBeanDefinition(), targetBeanName));
        return holder;
    }

}

關於ScopedProxyBeanDefinitionDecorator幹啥用的那：

  <bean id="lavaPvgInfo" class="com.alibaba.lava.privilege.PrivilegeInfo"
        scope="request">
        <property name="aesKey" value="666" />
        <aop:scoped-proxy />
    </bean>

其實就是處理<aop:scoped-proxy />
的，具體作用是包裝lavaPvgInfo的bean定義為ScopedProxyFactoryBean，作用是實現request作用域bean.

8.3 commons-collections包中ListUtils

如圖

ListUtils中的四個方法分別依賴list的四種裝飾器類對List功能進行擴充和限制。
其中FixedSizeList類通過禁止add/remove操作保證list的大小固定，但是可以修改元素內容
其中UnmodifiableList類通過禁用add,clear,remove,set,保證list的內容不被修改
其中SynchronizedList類通過使用Lock 來保證add,set,get,remove等的同步安全
其中LazyList類則當呼叫get方法發現list裡面不存在物件時候，自動使用factory建立物件.

8.4 使用場景

• 在不改變原有類結構基礎上，新增或者限制或者改造功能時候。

九、介面卡模式（Adapter Pattern）

9.1 介紹

介面卡模式屬於結構性模式，它為兩個不同介面之間互通提供了一種手段。

9.2 Spring中MethodInterceptor介面卡

在Spring Aop框架中，MethodInterceptor介面被用來攔截指定的方法，對方法進行增強。

大家都知道在Aop中每個advistor 裡面會有一個advice具體做切面動作，Spring提供了AspectJAfterReturningAdvice，AspectJMethodBeforeAdvice，AspectJAroundAdvice，AspectJAfterAdvice這幾個advice,在XML 配置aop時候會指定<aop:after-returning/>,<aop:before/>,<aop:around/>,<aop:after/>,其實內部就是建立上面對應的這些advice。

從圖知道AspectJAfterReturningAdvice和AspectJMethodBeforeAdvice沒有實現MethodInterceptor介面，其他兩者則實現了該介面。而Spring Aop的方法攔截器卻必須是實現了MethodInterceptor的，所以Spring提供了對應的介面卡來適配這個問題,分別是MethodBeforeAdviceAdapter和AfterReturningAdviceAdapter和ThrowsAdviceAdapter。

看下DefaultAdvisorAdapterRegistry的 getInterceptors方法：

public MethodInterceptor[] getInterceptors(Advisor advisor) throws UnknownAdviceTypeException {
    List<MethodInterceptor> interceptors = new ArrayList<MethodInterceptor>(3);

    //從advistor中獲取advice
    Advice advice = advisor.getAdvice();

    //如果實現了MethodInterceptor則直接加入，比如AspectJAroundAdvice，AspectJAfterAdvice
    if (advice instanceof MethodInterceptor) {
        interceptors.add((MethodInterceptor) advice);
    }

    //否者看是否有當前advice的介面卡，首先檢驗是否支援，支援則返回對應的介面卡
    for (AdvisorAdapter adapter : this.adapters) {
        if (adapter.supportsAdvice(advice)) {
            interceptors.add(adapter.getInterceptor(advisor));
        }
    }
    if (interceptors.isEmpty()) {
        throw new UnknownAdviceTypeException(advisor.getAdvice());
    }
    return interceptors.toArray(new MethodInterceptor[interceptors.size()]);
}

以MethodBeforeAdviceAdapter為例子看下：

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);
    }

}

public class MethodBeforeAdviceInterceptor implements MethodInterceptor, Serializable {

    private MethodBeforeAdvice advice;

    /**
     * Create a new MethodBeforeAdviceInterceptor for the given advice.
     * @param advice the MethodBeforeAdvice to wrap
     */
    public MethodBeforeAdviceInterceptor(MethodBeforeAdvice advice) {
        Assert.notNull(advice, "Advice must not be null");
        this.advice = advice;
    }

    public Object invoke(MethodInvocation mi) throws Throwable {
        this.advice.before(mi.getMethod(), mi.getArguments(), mi.getThis() );
        return mi.proceed();
    }

}

可知MethodBeforeAdviceInterceptor繼承了MethodInterceptor作為了一個介面卡內部委託請求給MethodBeforeAdvice。

9.3 使用場景

• 兩個系統互動時候由於介面引數不一樣沒辦法直接對接，則可以搞個介面卡介面做引數轉換。

• 介面卡模式經常是在一個系統或者設計已經定型時候用的，而不是在初始設計時候。一般是因為不影響現在業務情況下，通過適配方式統一介面

十、模板設計模式（Template Pattern）

10.1 前言

模板設計模式是一種行為設計模式，它使用一個抽象類定義了一個模板，這個模板裡面定義了一系列的介面，子類則只需要繼承該抽象類並且根據需要重寫一部分介面。

10.2 ibatis2中AbstractDAOTemplate

如圖AbstractDAOTemplate是抽象模板類，裡面定義了configure方法，configure方法裡面定義了好多protected方法，其中就有些是抽象方法。類SpringDAOTemplate，IbatisDAOTemplate，GenericCIDAOTemplate，GenericSIDAOTemplate則繼承了AbstractDAOTemplate類並重寫了一部分方法。

10.3 Tomcat中Digester裡面的Rule

tomcat中的Digester是為了解析server.xml的，其中每個元素都有一個解析規則就是Rule ,類圖如下：

如圖：Rule是抽象類，對於每個解析的節點來說Rule提供瞭解析所需所有的方法，而他的子類則根據自己的特殊性重寫一部分方法來支援自己的特性。

10.4 Tomcat中Endpoint

如圖AbstractEndpoint是個抽象類，定義了Endpoint的所有介面，然後JIoEndpoint繼承了該類並且重寫了一部分重要的方法實現了BIO方式endpoint,NioEndpoint則重寫了方法實現了NIO的endpoint.

10.5使用場景

• 當多個子類具有共同的操作流程邏輯，並且其中某些流程節點操作需要自己定製化時候。

十一、 建造者模式（Builder Pattern）

11.1 前言

建造者模式是一種建立型模式，將一個複製物件的建立遮蔽到介面內部，使用者使用時候只需要傳遞固定的引數，內部就會執行復雜邏輯後返回會使用者需要的物件，使用者不需要知道建立的細節。

11.2 Mybatis中的SqlSessionFactoryBuilder

如圖mybaits中的SqlSessionFactoryBuilder就是典型的建立者模式，他內部有多個build方法，根據引數的不同創建出SqlSessionFactory物件，使用者只需要傳遞具體引數而不用關係內部是如何創建出需要的物件的。SqlSessionFactoryBean大家應該很熟悉，在xml裡面配置的。

相關推薦