一、Java I/O中的設(shè)計(jì)模式

1、適配器模式

適配器模式就是把一個(gè)類的接口變換成客戶端所能接受的另一種接口，從而使兩個(gè)接口不匹配而無法在一起工作的兩個(gè)類能夠在一起工作。通常被用在一個(gè)項(xiàng)目需要引用一些開源框架來一起工作時(shí)，這些框架的內(nèi)部都有一些關(guān)于環(huán)境信息的接口，需要從外部引入，但是外部的接口不一定能匹配，在這種情況下，就需要適配器模式來轉(zhuǎn)換接口。

Java的I/O類庫中有許多這樣的需求，如將字符串轉(zhuǎn)成字節(jié)數(shù)據(jù)保存到文件中，將字節(jié)數(shù)據(jù)變成數(shù)據(jù)流等。具體來說，InputStreamReader和OutputStreamWriter就是適配器的體現(xiàn)。InputStreamReader實(shí)現(xiàn)了Reader接口，并且持有InputStream的引用，其作用是將InputStream適配到Reader。源角色就是InputStream代表的實(shí)例對象，目標(biāo)角色就是Reader類。OutputStreamWriter也是類似的方式。

后期文章會首發(fā)于本專欄，歡迎關(guān)注

JAVA高級進(jìn)階?zhuanlan.zhihu.com

2、裝飾器模式

裝飾器的作用是使得被裝飾者功能更強(qiáng)大，而且裝飾前后的使用方式不變。Java I/O類庫中有許多不同的功能組合情況，這些不同的功能組合都是使用裝飾器模式實(shí)現(xiàn)的。以FileInputStream為例，其類結(jié)構(gòu)如下：

由于java I/O庫需要很多性能的各種組合，如果這些性能都是用繼承來實(shí)現(xiàn)，那么每一種組合都需要一個(gè)類，這樣就會造成大量行重復(fù)的類出現(xiàn)。如果采用裝飾模式，那么類的數(shù)目就會大大減少，性能的重復(fù)也可以減至最少。因此裝飾模式是java I/O庫基本模式。裝飾模式的引進(jìn)，造成靈活性和復(fù)雜性的提高。因此在使用 java I/O 庫時(shí)，必須理解java I/O庫是由一些基本的原始流處理器和圍繞它們的裝飾流處理器所組成的。

InputStream類是以抽象組件的形式存在，而FileInputStream就是具體組件，它實(shí)現(xiàn)了抽象接口的所有方法，并且持有InputStream對象的引用。FileInputStream就是一個(gè)裝飾類，而BufferInputStream是這個(gè)裝飾類的具體實(shí)現(xiàn)者，它給InputStream加入了新的功能，使得InputStream讀取的數(shù)據(jù)保存在內(nèi)存中，從而提高讀取性能。

3、適配模式和裝飾模式的區(qū)別

適配模式是為了處理兩個(gè)借口不一致，改變現(xiàn)有接口使其匹配。

裝飾模式是在不改變現(xiàn)有接口的前提下，加入新的功能。

二、Javac中的訪問者模式

javac 是java語言編程編譯器。全稱javacompilation。javac工具讀由java語言編寫的類和接口的定義，并將它們編譯成字節(jié)代碼的class文件。javac 可以隱式編譯一些沒有在命令行中提及的源文件。用 -verbose 選項(xiàng)可跟蹤自動編譯。當(dāng)編譯源文件時(shí)，編譯器常常需要它還沒有識別出的類型的有關(guān)信息。對于源文件中使用、擴(kuò)展或?qū)崿F(xiàn)的每個(gè)類或接口，編譯器都需要其類型信息。這包括在源文件中沒有明確提及、但通過繼承提供信息的類和接口。

Javac的編譯過程涉及許多語法分析，所有就有語法分析器、語義分析器和代碼生成器，期間需要多次遍歷語法樹。然而每次遍歷語法樹都會進(jìn)行不同的處理動作，這是如何實(shí)現(xiàn)的呢？就是通過采用訪問者模式設(shè)計(jì)的，每次遍歷都是一次訪問者的執(zhí)行過程。

訪問者模式可以使數(shù)據(jù)結(jié)構(gòu)和對數(shù)據(jù)結(jié)構(gòu)的操作解耦，使得增加對數(shù)據(jù)結(jié)構(gòu)的操作不需要去修改數(shù)據(jù)結(jié)構(gòu)，也不必去修改原有的操作，從而執(zhí)行時(shí)再定義新的Visitor實(shí)現(xiàn)者就行了。在Javac中不同的編譯階段都定義了不同的訪問者模式實(shí)現(xiàn)。

三、Tomcat中的設(shè)計(jì)模式

1、門面模式

Tomcat中門面設(shè)計(jì)模式使用得很多，因?yàn)門omcat中有很多組件，每個(gè)組件要相互交互數(shù)據(jù)，用門面設(shè)計(jì)模式隔離數(shù)據(jù)是個(gè)很好的方法。

可以看到，HttpRequestFacade類封裝了HttpRequest接口，能夠提供數(shù)據(jù)，通過HttpRequestFacade訪問到的數(shù)據(jù)被代理到HttpReauest中、通常被封裝的對象都被設(shè)為Private或者Protectd的，防止在Facade中直接訪問。

2、觀察者模式

Tomcat中觀察者模式也有多處使用，前面講的控制組件生命周期的Lifecycle就是這 種模式的體現(xiàn)，還有對Servlet實(shí)例的創(chuàng)建、Session的管理、Container等都是同樣的原理。 下面主要看一下Lifecycle的具體實(shí)現(xiàn)。

Lifecycle的觀察者模式結(jié)構(gòu)圖如圖所示。

在上面的結(jié)構(gòu)圖中，LifecycleListener代表的是抽象觀察者，它定義一個(gè)lifecycleEvent 方法，這個(gè)方法就是當(dāng)主題變化時(shí)要執(zhí)行的方法。ServerLifecycleListener代表的是具體的 觀察者，它實(shí)現(xiàn)了 LifecycleListener接口的方法，就是這個(gè)具體的觀察者具體的實(shí)現(xiàn)方式。 Lifecycle接口代表的是抽象主題，它定義了管理觀察者的方法和它所要做的其他方法。而 StandardServer代表的是具體主題，它實(shí)現(xiàn)了抽象主題的所有方法。這里Tomcat對觀察者 做了擴(kuò)展，謂加了另外兩個(gè)類：LifecycleSupport和LifecycleEvent，它們作為輔助類擴(kuò)展 了觀察者的功能。LifecycleEvent使得可以定義事件類別，不同的事件可區(qū)別處理，更加靈活。LifecycleSupport類代理了主題對多觀察者的管理，將這個(gè)管理抽出來統(tǒng)一實(shí)現(xiàn)，以 后如采修改只要修改LifecycleSupport類就可以了，不需要去修改所有的具體主題，因?yàn)?所有具體主題對觀察者的操作都被代理給LifecycleSupport類了。這可以認(rèn)為是觀察者模式的改進(jìn)版。

3、命令設(shè)計(jì)模式

Tomcat中命令模式在Connector和Container組件之間有體現(xiàn)，Tomcat作為一個(gè)應(yīng)用 服務(wù)器，無疑會接收到很多請求，如何分配和執(zhí)行這些請求是必須的功能。

下面分析一下Tomcat是如何實(shí)現(xiàn)命令模式的，下圖是Tomcat命令模式的結(jié)構(gòu)圖。

Connector作為抽象請求者，HttpConnector作為具體請求者。HttpProcessor作為命令。 Container作為命令的抽象接受者，ContainerBase作為具體的接受者。客戶端就是應(yīng)用服務(wù)器Server組件了。Server首先創(chuàng)建命令請求者HttpConnector對象，然后創(chuàng)建命令 HttpProcessor對象。再把命令對象交給命令接受者ContainerBase容器來處理，命令最終是被Tomcat的Container執(zhí)行的。命令可以以隊(duì)列的方式進(jìn)來，Container也可以以不同的 方式來處理請求，如HTTP1.0協(xié)議和HTTP1.1的處理方式就不同。

4、責(zé)任鏈模式

Tomcat 中一個(gè)最容易發(fā)現(xiàn)的設(shè)計(jì)模式就是責(zé)任鏈設(shè)計(jì)模式，這個(gè)設(shè)計(jì)模式也是 Tomcat 中 Containe設(shè)計(jì)的基礎(chǔ)，整個(gè)容器就是通過一個(gè)鏈連接在一起的，這個(gè)鏈一直將請求正確地傳遞給最終處理請求的那個(gè) Servlet 。在Tomcat中這種設(shè)計(jì)模式兒乎被完整地使用，Tomcat的容器設(shè)置就是責(zé)任鏈模式，從Engine到Host再到Cortex，一直到Wrapper都通過這個(gè)鏈傳遞請求。

四、Spring中的設(shè)計(jì)模式

1、簡單工廠模式

又叫做靜態(tài)工廠方法（StaticFactory Method）模式，但不屬于23種GOF設(shè)計(jì)模式之一。

簡單工廠模式的實(shí)質(zhì)是由一個(gè)工廠類根據(jù)傳入的參數(shù)，動態(tài)決定應(yīng)該創(chuàng)建哪一個(gè)產(chǎn)品類。

spring中的BeanFactory就是簡單工廠模式的體現(xiàn)，根據(jù)傳入一個(gè)唯一的標(biāo)識來獲得bean對象，但是否是在傳入?yún)?shù)后創(chuàng)建還是傳入?yún)?shù)前創(chuàng)建這個(gè)要根據(jù)具體情況來定。如下配置，就是在 HelloItxxz 類中創(chuàng)建一個(gè) itxxzBean。

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

2、工廠方法模式

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

一般情況下,應(yīng)用程序有自己的工廠對象來創(chuàng)建bean.如果將應(yīng)用程序自己的工廠對象交給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容器來管理,需要通過factory-method指定靜態(tài)方法名稱,createRandom方法必須是static的,才能找到

<bean id="random" class="example.chapter3.StaticFactoryBean" factory-method="createRandom" scope="prototype" />

3、單例模式

保證一個(gè)類僅有一個(gè)實(shí)例，并提供一個(gè)訪問它的全局訪問點(diǎn)。

spring中的單例模式完成了后半句話，即提供了全局的訪問點(diǎn)BeanFactory。但沒有從構(gòu)造器級別去控制單例，這是因?yàn)閟pring管理的是是任意的java對象。 Spring下默認(rèn)的bean均為singleton，可以通過singleton=“true|false” 或者 scope=“？”來指定

4、代理模式

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

5、模板方法模式

定義一個(gè)操作中的算法的骨架，而將一些步驟延遲到子類中。Template Method使得子類可以不改變一個(gè)算法的結(jié)構(gòu)即可重定義該算法的某些特定步驟。

Template Method模式一般是需要繼承的。這里想要探討另一種對Template Method的理解。spring中的JdbcTemplate，在用這個(gè)類時(shí)并不想去繼承這個(gè)類，因?yàn)檫@個(gè)類的方法太多，但是我們還是想用到JdbcTemplate已有的穩(wěn)定的、公用的數(shù)據(jù)庫連接，那么我們怎么辦呢？我們可以把變化的東西抽出來作為一個(gè)參數(shù)傳入JdbcTemplate的方法中。但是變化的東西是一段代碼，而且這段代碼會用到JdbcTemplate中的變量。怎么辦？那我們就用回調(diào)對象吧。在這個(gè)回調(diào)對象中定義一個(gè)操縱JdbcTemplate中變量的方法，我們?nèi)?shí)現(xiàn)這個(gè)方法，就把變化的東西集中到這里了。然后我們再傳入這個(gè)回調(diào)對象到JdbcTemplate，從而完成了調(diào)用。這可能是Template Method不需要繼承的另一種實(shí)現(xiàn)方式吧。

6、策略模式

Spring中的策略模式使用多如牛毛，所謂策略模式就是定義了算法族，分別封裝起來，讓他們之前可以互相轉(zhuǎn)換，此模式然該算法的變化獨(dú)立于使用算法的客戶。Spring的事務(wù)管理機(jī)制就是典型的策略模式，Spring事務(wù)策略是通過PlatformTransactionManager接口實(shí)現(xiàn)的，它是整個(gè)Spring事務(wù)的核心。它是對事務(wù)策略的一個(gè)高度抽象，不依賴于任何具體的事務(wù)策略，而對于底層的具體的事務(wù)策略它相應(yīng)的有不同的實(shí)現(xiàn)類。而對于不同的事務(wù)策略的切換通常由Spring容器來負(fù)責(zé)管理，應(yīng)用程序既無須與具體的事務(wù)API耦合，也無須與特定的實(shí)現(xiàn)類耦合而將應(yīng)用和持久化技術(shù)，事務(wù)API徹底分離開來。

五、SpringMVC中的模板模式

所謂模板模式就是定義一個(gè)操作中的算法的骨架，而將一些步驟延遲到子類中。SpringMVC在保證整個(gè)框架流程穩(wěn)定的情況下，預(yù)留很多口子，而這些口子都是所謂的模板方法，可以自由指定，從而保證了靈活性，接下來的很多使用最佳實(shí)踐都是基于這種設(shè)計(jì)模式才可以實(shí)現(xiàn)。例如，下面的代碼中doResolveException(..)就是一個(gè)口子，子類方法doResolveException(..)可以定義具體如何處理異常。

public ModelAndView resolveException(HttpServletRequest request, HttpServletResponse response, Object handler,Exception ex) {if (shouldApplyTo(request, handler)) {logException(ex, request);prepareResponse(ex, response);return doResolveException(request, response, handler, ex);} else {return null;} }protected abstract ModelAndView doResolveException(HttpServletRequest request, HttpServletResponse response,Object handler, Exception ex);

我這兒整理了比較全面的JAVA相關(guān)的面試資料，

需要領(lǐng)取面試資料的同學(xué)，請加群：473984645

總結(jié)

以上是生活随笔為你收集整理的java 设计模式_Java设计模式的常见应用场景的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。