建站
咨詢
售后
建站咨詢
新聞中心
本文轉(zhuǎn)載自微信公眾號「月伴飛魚」，作者日常加油站。轉(zhuǎn)載本文請聯(lián)系月伴飛魚公眾號。
創(chuàng)新互聯(lián)主要從事成都網(wǎng)站建設(shè)、做網(wǎng)站、網(wǎng)頁設(shè)計、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)亞東,10年網(wǎng)站建設(shè)經(jīng)驗,價格優(yōu)惠、服務(wù)專業(yè),歡迎來電咨詢建站服務(wù):18980820575
代理模式
所謂代理，是指它與被代理對象實現(xiàn)了相同的接口，客戶端必須通過代理才能與被代理的目標類進行交互，而代理一般在交互的過程中(交互前后)，進行某些特定的處理，比如在調(diào)用這個方法前做前置處理，調(diào)用這個方法后做后置處理。
代理又分為靜態(tài)代理和動態(tài)代理兩種方式，Spring的AOP采用的是動態(tài)代理的方式
Spring通過動態(tài)代理對類進行方法級別的切面增強，動態(tài)生成目標對象的代理類，并在代理類的方法中設(shè)置攔截器，通過執(zhí)行攔截器中的邏輯增強了代理方法的功能，從而實現(xiàn)AOP。
策略模式
我們前面講到，Spring AOP是通過動態(tài)代理來實現(xiàn)的。
具體到代碼實現(xiàn)，Spring支持兩種動態(tài)代理實現(xiàn)方式，一種是JDK提供的動態(tài)代理實現(xiàn)方式，另一種是Cglib提供的動態(tài)代理實現(xiàn)方式。
Spring會在運行時動態(tài)地選擇不同的動態(tài)代理實現(xiàn)方式。這個應(yīng)用場景實際上就是策略模式的典型應(yīng)用場景。
我們只需要定義一個策略接口，讓不同的策略類都實現(xiàn)這一個策略接口。對應(yīng)到Spring源碼，AopProxy是策略接口，JdkDynamicAopProxy、CglibAopProxy是兩個實現(xiàn)了AopProxy接口的策略類。
其中，AopProxy接口的定義如下所示：
在策略模式中，策略的創(chuàng)建一般通過工廠方法來實現(xiàn)。對應(yīng)到Spring源碼，AopProxyFactory是一個工廠類接口，DefaultAopProxyFactory是一個默認的工廠類，用來創(chuàng)建AopProxy對象。
源碼如下所示：
策略模式的典型應(yīng)用場景，一般是通過環(huán)境變量、狀態(tài)值、計算結(jié)果等動態(tài)地決定使用哪個策略。
對應(yīng)到Spring源碼中，我們可以參看剛剛給出的DefaultAopProxyFactory類中的createAopProxy()函數(shù)的代碼實現(xiàn)。
其中，第10行代碼是動態(tài)選擇哪種策略的判斷條件。
裝飾器模式
我們知道，緩存一般都是配合數(shù)據(jù)庫來使用的。如果寫緩存成功，但數(shù)據(jù)庫事務(wù)回滾了，那緩存中就會有臟數(shù)據(jù)。
為了解決這個問題，我們需要將緩存的寫操作和數(shù)據(jù)庫的寫操作，放到同一個事務(wù)中，要么都成功，要么都失敗。
實現(xiàn)這樣一個功能，Spring使用到了裝飾器模式。
TransactionAwareCacheDecorator增加了對事務(wù)的支持，在事務(wù)提交、回滾的時候分別對Cache的數(shù)據(jù)進行處理。
TransactionAwareCacheDecorator實現(xiàn)Cache接口，并且將所有的操作都委托給targetCache來實現(xiàn)，對其中的寫操作添加了事務(wù)功能。這是典型的裝飾器模式的應(yīng)用場景和代碼實現(xiàn)。
單例模式
單例模式是指一個類在整個系統(tǒng)運行過程中，只允許產(chǎn)生一個實例
在Spring中，Bean可以被定義為兩種模式：Prototype(多例)和Singleton(單例)，Spring Bean默認是單例模式。
那Spring是如何實現(xiàn)單例模式的呢?
答案是通過單例注冊表的方式，具體來說就是使用了HashMap。簡化代碼如下：
- public class DefaultSingletonBeanRegistry {
- //使用了線程安全容器ConcurrentHashMap，保存各種單實例對象
- private final Map singletonObjects = new ConcurrentHashMap;
- protected Object getSingleton(String beanName) {
- //先到HashMap中拿Object
- Object singletonObject = singletonObjects.get(beanName);
- //如果沒拿到通過反射創(chuàng)建一個對象實例，并添加到HashMap中
- if (singletonObject == null) {
- singletonObjects.put(beanName,
- Class.forName(beanName).newInstance());
- }
- //返回對象實例
- return singletonObjects.get(beanName);
- }
- }
上面的代碼邏輯比較清晰，先到HashMap去拿單實例對象，沒拿到就創(chuàng)建一個添加到HashMap。
簡單工廠模式
有這樣一個場景：
當(dāng)A對象需要調(diào)用B對象的方法時，我們需要在A中new一個B的實例，它的缺點是一旦需求發(fā)生變化，比如需要使用C類來代替B時，就要改寫A類的方法。
假如應(yīng)用中有100個類以的方式耦合了B，那改起來就費勁了。
使用簡單工廠模式：
簡單工廠模式又叫靜態(tài)工廠方法，其實質(zhì)是由一個工廠類根據(jù)傳入的參數(shù)，動態(tài)決定應(yīng)該創(chuàng)建哪一個產(chǎn)品類。
其中Spring中的BeanFactory就是簡單工廠模式的體現(xiàn)，BeanFactory是Spring IOC容器中的一個核心接口，它的定義如下：
我們可以通過它的具體實現(xiàn)類(比如ClassPathXmlApplicationContext)來獲取Bean：
- BeanFactory bf = new ClassPathXmlApplicationContext("spring.xml");
- FlyFish flyFishBean = (FlyFish) bf.getBean("flyfishBean");
從上面代碼可以看到，使用者不需要自己來new對象，而是通過工廠類的方法getBean來獲取對象實例，這是典型的簡單工廠模式，只不過Spring是用反射機制來創(chuàng)建Bean的。
工廠方法模式
在簡單工廠中，由工廠類進行所有的邏輯判斷、實例創(chuàng)建;如果不想在工廠類中進行判斷，可以為不同的產(chǎn)品提供不同的工廠，不同的工廠生產(chǎn)不同的產(chǎn)品，每一個工廠都只對應(yīng)一個相應(yīng)的對象，這就是工廠方法模式。
Spring中的FactoryBean就是這種思想的體現(xiàn)，F(xiàn)actoryBean可以理解為工廠Bean，先來看看它的定義：
我們定義一個類FlyFishFactoryBean來實現(xiàn)FactoryBean接口，主要是在getObject方法里new一個FlyFish對象。這樣我們通過getBean(id) 獲得的是該工廠所產(chǎn)生的FlyFish的實例，而不是FlyFishFactoryBean本身的實例，像下面這樣：
- BeanFactory bf = new ClassPathXmlApplicationContext("spring.xml");
- FlyFish flyFishBean = (FlyFish) bf.getBean("flyfishBean");
觀察者模式
Spring中實現(xiàn)的觀察者模式包含三部分：Event事件(相當(dāng)于消息)、Listener監(jiān)聽者(相當(dāng)于觀察者)、Publisher發(fā)送者(相當(dāng)于被觀察者)
我們通過一個例子來看下Spring提供的觀察者模式是怎么使用的
- // Event事件
- public class DemoEvent extends ApplicationEvent {
- private String message;
- public DemoEvent(Object source, String message) {
- super(source);
- }
- public String getMessage() {
- return this.message;
- }
- }
- // Listener監(jiān)聽者
- @Component
- public class DemoListener implements ApplicationListener {
- @Override
- public void onApplicationEvent(DemoEvent demoEvent) {
- String message = demoEvent.getMessage();
- System.out.println(message);
- }
- }
- // Publisher發(fā)送者
- @Component
- public class DemoPublisher {
- @Autowired
- private ApplicationContext applicationContext;
- public void publishEvent(DemoEvent demoEvent) {
- this.applicationContext.publishEvent(demoEvent);
- }
- }
從代碼中，我們可以看出，主要包含三部分工作：
- 定義一個繼承ApplicationEvent的事件(DemoEvent);
- 定義一個實現(xiàn)了ApplicationListener的監(jiān)聽器(DemoListener);
- 定義一個發(fā)送者(DemoPublisher)，發(fā)送者調(diào)用ApplicationContext來發(fā)送事件消息。
在Spring的實現(xiàn)中，觀察者注冊到了哪里呢?又是如何注冊的呢?
Spring把觀察者注冊到了ApplicationContext對象中。
實際上，具體到源碼來說，ApplicationContext只是一個接口，具體的代碼實現(xiàn)包含在它的實現(xiàn)類AbstractApplicationContext中。我把跟觀察者模式相關(guān)的代碼，如下。你只需要關(guān)注它是如何發(fā)送事件和注冊監(jiān)聽者就好。
從上面的代碼中，我們發(fā)現(xiàn)，真正的消息發(fā)送，實際上是通過ApplicationEventMulticaster這個類來完成的。
下面這個類的源碼我只摘抄了最關(guān)鍵的一部分，也就是multicastEvent()這個消息發(fā)送函數(shù)，它通過線程池，支持異步非阻塞、同步阻塞這兩種類型的觀察者模式。
借助Spring提供的觀察者模式的骨架代碼，如果我們要在Spring下實現(xiàn)某個事件的發(fā)送和監(jiān)聽，只需要做很少的工作，定義事件、定義監(jiān)聽器、往ApplicationContext中發(fā)送事件就可以了，剩下的工作都由Spring框架來完成。
實際上，這也體現(xiàn)了Spring框架的擴展性，也就是在不需要修改任何代碼的情況下，擴展新的事件和監(jiān)聽。
模板模式
我們經(jīng)常在面試中被問到的一個問題：
請你說下Spring Bean的創(chuàng)建過程包含哪些主要的步驟。
這其中就涉及模板模式。它也體現(xiàn)了Spring的擴展性。利用模板模式，Spring能讓用戶定制Bean的創(chuàng)建過程。
下面是Spring Bean的整個生命周期，一張圖，清晰明了：
如果你仔細看過源碼會發(fā)現(xiàn)，實際上，這里的模板模式的實現(xiàn)，并不是標準的抽象類的實現(xiàn)方式，而是有點類似Callback回調(diào)的實現(xiàn)方式，也就是將要執(zhí)行的函數(shù)封裝成對象(比如，初始化方法封裝成InitializingBean對象)，傳遞給模板(BeanFactory)來執(zhí)行。
觀察者模式和模板模式，這兩種模式能夠幫助我們創(chuàng)建擴展點，讓框架的使用者在不修改源碼的情況下，基于擴展點定制化框架功能。
適配器模式
在Spring MVC中，定義一個Controller最常用的方式是，通過@Controller注解來標記某個類是Controller類，通過@RequesMapping注解來標記函數(shù)對應(yīng)的URL
不過，我們還可以通過讓類實現(xiàn)Controller接口或者Servlet接口，來定義一個Controller。
針對這三種定義方式，我寫了三段示例代碼，如下所示：
- // 方法一：通過@Controller、@RequestMapping來定義
- @Controller
- public class DemoController {
- @RequestMapping("/FlyFish")
- public ModelAndView getEmployeeName() {
- ModelAndView model = new ModelAndView("FlyFish");
- model.addObject("message", "FlyFish");
- return model;
- }
- }
- // 方法二：實現(xiàn)Controller接口 + xml配置文件:配置DemoController與URL的對應(yīng)關(guān)系
- public class DemoController implements Controller {
- @Override
- public ModelAndView handleRequest(HttpServletRequest req, HttpServletResponse resp) throws Exception {
- ModelAndView model = new ModelAndView("FlyFish");
- model.addObject("message", "FlyFish");
- return model;
- }
- }
- // 方法三：實現(xiàn)Servlet接口 + xml配置文件:配置DemoController類與URL的對應(yīng)關(guān)系
- public class DemoServlet extends HttpServlet {
- @Override
- protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
- this.doPost(req, resp);
- }
- @Override
- protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
- resp.getWriter().write("Hello World.");
- }
- }
在應(yīng)用啟動的時候，Spring容器會加載這些Controller類，并且解析出URL對應(yīng)的處理函數(shù)，封裝成Handler對象，存儲到HandlerMapping對象中。當(dāng)有請求到來的時候，DispatcherServlet從HanderMapping中，查找請求URL對應(yīng)的Handler，然后調(diào)用執(zhí)行Handler對應(yīng)的函數(shù)代碼，最后將執(zhí)行結(jié)果返回給客戶端。
但是，不同方式定義的Controller，其函數(shù)的定義(函數(shù)名、入?yún)ⅰ⒎祷刂档?是不統(tǒng)一的。
DispatcherServlet調(diào)用的是service()方法，DispatcherServlet需要根據(jù)不同類型的Controller，調(diào)用不同的函數(shù)。
Spring利用適配器模式，我們將不同方式定義的Controller類中的函數(shù)，適配為統(tǒng)一的函數(shù)定義。
我們再具體看下Spring的代碼實現(xiàn)。
Spring定義了統(tǒng)一的接口HandlerAdapter，并且對每種Controller定義了對應(yīng)的適配器類。
這些適配器類包括：AnnotationMethodHandlerAdapter、SimpleControllerHandlerAdapter、SimpleServletHandlerAdapter等。
在DispatcherServlet類中，我們就不需要區(qū)分對待不同的Controller對象了，統(tǒng)一調(diào)用HandlerAdapter的handle()函數(shù)就可以了
網(wǎng)站名稱：來自讀者的面試題：談?wù)凷pring用到了哪些設(shè)計模式？
網(wǎng)頁鏈接：http://www.5511xx.com/article/cdcseoi.html
