[[335627]]

上次有小伙伴建議，源碼分析太枯燥了，要是能夠結(jié)合設(shè)計(jì)模式一起來(lái)，這樣更有助于大家理解 Spring Security 源碼，同時(shí)還能復(fù)習(xí)一波設(shè)計(jì)模式。

因此松哥今天就試著整一篇，和大家來(lái)聊一聊 Spring Security 中涉及到的設(shè)計(jì)模式，不過(guò) Spring Security 中涉及到的設(shè)計(jì)模式還是非常多的，松哥這里講幾個(gè)，剩下的歡迎小伙伴們留言補(bǔ)充。

1.模板方法模式

Template Pattern(模板方法模式)是一個(gè)抽象類(lèi)公開(kāi)定義了執(zhí)行它的方法的模板。它的子類(lèi)可以按需要重寫(xiě)方法實(shí)現(xiàn)，但調(diào)用將以抽象類(lèi)中定義的方式進(jìn)行，這是一種行為型模式。

模板方法方式優(yōu)點(diǎn)如下：

• 在父類(lèi)中提取了公共的部分代碼，便于代碼復(fù)用和擴(kuò)展。
• 部分方法是由子類(lèi)實(shí)現(xiàn)的，子類(lèi)可以通過(guò)擴(kuò)展方式增加相應(yīng)的功能，符合開(kāi)閉原則。

缺點(diǎn)如下：

• 對(duì)每個(gè)不同的實(shí)現(xiàn)都需要定義一個(gè)子類(lèi)，導(dǎo)致類(lèi)的個(gè)數(shù)增加，系統(tǒng)更加復(fù)雜，設(shè)計(jì)也更加抽象。
• 父類(lèi)中的抽象方法由子類(lèi)實(shí)現(xiàn)，子類(lèi)執(zhí)行的結(jié)果會(huì)影響父類(lèi)的結(jié)果，增加了代碼理解難度。

介紹完模板方法模式，大家可能大概猜到了 Spring Security 中哪些地方用到模板方法模式了。

我舉幾個(gè)簡(jiǎn)單的例子。

第一個(gè)例子是 AbstractUserDetailsAuthenticationProvider 類(lèi)的設(shè)計(jì)。大家都知道這個(gè)類(lèi)是用來(lái)做驗(yàn)證的，認(rèn)證的邏輯在這個(gè)方法中都定義好了，但是該類(lèi)卻定義了兩個(gè)抽象方法：

• retrieveUser 該方法用戶(hù)從數(shù)據(jù)源中獲取用戶(hù)對(duì)象。
• additionalAuthenticationChecks 該方法用來(lái)做額外的校驗(yàn)(登錄憑證的校驗(yàn))

這兩個(gè)抽象方法是在 DaoAuthenticationProvider 中實(shí)現(xiàn)的。DaoAuthenticationProvider 的實(shí)現(xiàn)就是從數(shù)據(jù)庫(kù)中加載用戶(hù)，默認(rèn)檢驗(yàn)登錄憑證也都是驗(yàn)證密碼。

如果你的數(shù)據(jù)源來(lái)自其他地方，或者登錄憑證不是密碼，那么自定義類(lèi)繼承自 AbstractUserDetailsAuthenticationProvider 并重寫(xiě)它里邊的這兩個(gè)方法即可。

2.責(zé)任鏈模式

Chain of Responsibility Pattern(責(zé)任鏈模式) ，在這種模式中，通常每個(gè)接收者都包含對(duì)另一個(gè)接收者的引用，如果一個(gè)對(duì)象不能處理該請(qǐng)求，那么它會(huì)把相同的請(qǐng)求傳給下一個(gè)接收者，依此類(lèi)推。在這個(gè)過(guò)程中，客戶(hù)只需要將請(qǐng)求發(fā)送到責(zé)任鏈上即可，無(wú)須關(guān)心請(qǐng)求的處理細(xì)節(jié)和請(qǐng)求的傳遞過(guò)程，所以責(zé)任鏈將請(qǐng)求的發(fā)送者和請(qǐng)求的處理者解耦了。

責(zé)任鏈模式優(yōu)點(diǎn)如下：

• 降低對(duì)象之間的耦合度。
• 增強(qiáng)了系統(tǒng)的可擴(kuò)展性。
• 當(dāng)工作流程發(fā)生變化，可以動(dòng)態(tài)地改變鏈內(nèi)的成員或者調(diào)動(dòng)它們的次序。
• 簡(jiǎn)化了對(duì)象之間的連接，每個(gè)對(duì)象只需保持一個(gè)指向其后繼者的引用，不需保持其他所有處理者的引用。
• 責(zé)任分擔(dān)，每個(gè)類(lèi)只需要處理自己該處理的工作，符合類(lèi)的單一職責(zé)原則。

缺點(diǎn)如下：

• 對(duì)比較長(zhǎng)的職責(zé)鏈，請(qǐng)求的處理可能涉及多個(gè)處理對(duì)象，系統(tǒng)性能將受到一定影響。
• 職責(zé)鏈建立的合理性要靠客戶(hù)端來(lái)保證，增加了客戶(hù)端的復(fù)雜性。

很明顯，Spring Security 中的過(guò)濾器鏈就是一種責(zé)任鏈模式。一個(gè)請(qǐng)求到達(dá)后，被過(guò)濾器鏈中的過(guò)濾器逐個(gè)進(jìn)行處理，過(guò)濾器鏈中的過(guò)濾器每個(gè)都具有不同的職能并且互不相擾，我們還可以通過(guò) HttpSecurity 來(lái)動(dòng)態(tài)配置過(guò)濾器鏈中的過(guò)濾器(即添加/刪除過(guò)濾器鏈中的過(guò)濾器)。

具體的代碼在 FilterChainProxy$VirtualFilterChain 中，如下：

那么接下來(lái)我們就來(lái)看看 VirtualFilterChain：

private static class VirtualFilterChain implements FilterChain { 
 private final FilterChain originalChain; 
 private final List<Filter> additionalFilters; 
 private final FirewalledRequest firewalledRequest; 
 private final int size; 
 private int currentPosition = 0; 
 private VirtualFilterChain(FirewalledRequest firewalledRequest, 
   FilterChain chain, List<Filter> additionalFilters) { 
  this.originalChain = chain; 
  this.additionalFilters = additionalFilters; 
  this.size = additionalFilters.size(); 
  this.firewalledRequest = firewalledRequest; 
 } 
 @Override 
 public void doFilter(ServletRequest request, ServletResponse response) 
   throws IOException, ServletException { 
  if (currentPosition == size) { 
   if (logger.isDebugEnabled()) { 
    logger.debug(UrlUtils.buildRequestUrl(firewalledRequest) 
      + " reached end of additional filter chain; proceeding with original chain"); 
   } 
   // Deactivate path stripping as we exit the security filter chain 
   this.firewalledRequest.reset(); 
   originalChain.doFilter(request, response); 
  } 
  else { 
   currentPosition++; 
   Filter nextFilter = additionalFilters.get(currentPosition - 1); 
   if (logger.isDebugEnabled()) { 
    logger.debug(UrlUtils.buildRequestUrl(firewalledRequest) 
      + " at position " + currentPosition + " of " + size 
      + " in additional filter chain; firing Filter: '" 
      + nextFilter.getClass().getSimpleName() + "'"); 
   } 
   nextFilter.doFilter(request, response, this); 
  } 
 } 
} 

VirtualFilterChain 類(lèi)中首先聲明了 5 個(gè)全局屬性，originalChain 表示原生的過(guò)濾器鏈，也就是 Web Filter;additionalFilters 表示 Spring Security 中的過(guò)濾器鏈;firewalledRequest 表示當(dāng)前請(qǐng)求;size 表示過(guò)濾器鏈中過(guò)濾器的個(gè)數(shù);currentPosition 則是過(guò)濾器鏈遍歷時(shí)候的下標(biāo)。

doFilter 方法就是 Spring Security 中過(guò)濾器挨個(gè)執(zhí)行的過(guò)程，如果 currentPosition == size，表示過(guò)濾器鏈已經(jīng)執(zhí)行完畢，此時(shí)通過(guò)調(diào)用 originalChain.doFilter 進(jìn)入到原生過(guò)濾鏈方法中，同時(shí)也退出了 Spring Security 過(guò)濾器鏈。否則就從 additionalFilters 取出 Spring Security 過(guò)濾器鏈中的一個(gè)個(gè)過(guò)濾器，挨個(gè)調(diào)用 doFilter 方法。nextFilter.doFilter 就是過(guò)濾器鏈挨個(gè)往下走。

3.策略模式

Strategy Pattern(策略模式)，它定義了一系列算法，將每一個(gè)算法封裝起來(lái)，并讓它們可以相互替換。策略模式讓算法獨(dú)立于使用它的客戶(hù)而變化，也稱(chēng)為政策模式(Policy)。

策略模式的優(yōu)點(diǎn)：

• 策略模式提供了對(duì)“開(kāi)閉原則”的完美支持，用戶(hù)可以在不修改原有系統(tǒng)的基礎(chǔ)上選擇具體的策略，也可以靈活地?cái)U(kuò)展新的策略。
• 策略模式提供了管理相關(guān)的策略的方式。
• 策略模式提供了可以替換繼承關(guān)系的辦法。
• 使用策略模式可以避免使用多重條件轉(zhuǎn)移語(yǔ)句。

策略模式的缺點(diǎn)：

• 客戶(hù)端必須知道所有的策略類(lèi)，并自行決定使用哪一個(gè)策略類(lèi)。
• 策略模式將造成產(chǎn)生很多策略類(lèi)(可以通過(guò)使用享元模式在一定程度上減少對(duì)象的數(shù)量)。

Spring Security 中使用策略模式的地方也有好幾個(gè)。

第一個(gè)就是用戶(hù)登錄信息存儲(chǔ)。

public class SecurityContextHolder { 
 // ~ Static fields/initializers 
 // ===================================================================================== 
 
 public static final String MODE_THREADLOCAL = "MODE_THREADLOCAL"; 
 public static final String MODE_INHERITABLETHREADLOCAL = "MODE_INHERITABLETHREADLOCAL"; 
 public static final String MODE_GLOBAL = "MODE_GLOBAL"; 
 public static final String SYSTEM_PROPERTY = "spring.security.strategy"; 
 private static String strategyName = System.getProperty(SYSTEM_PROPERTY); 
 private static SecurityContextHolderStrategy strategy; 
} 

用戶(hù)可以自行選擇使用哪一種策略!

還有一個(gè)就是 session 并發(fā)管理。

在 AbstractAuthenticationProcessingFilter#doFilter 方法中，有如下代碼：

public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) 
  throws IOException, ServletException { 
 //省略 
  sessionStrategy.onAuthentication(authResult, request, response); 
 //省略 
} 

這就是一種策略模式。

當(dāng)然，這樣的例子還有很多，我就不一一列舉了。

4.代理模式

Proxy Pattern(代理模式) ：給某一個(gè)對(duì)象提供一個(gè)代理，并由代理對(duì)象控制對(duì)原對(duì)象的引用，它是一種對(duì)象結(jié)構(gòu)型模式。

代理模式的優(yōu)點(diǎn)：

• 一定程度上降低了系統(tǒng)的耦合度。
• 代理對(duì)象可以擴(kuò)展目標(biāo)對(duì)象的功能。
• 代理對(duì)象可以保護(hù)目標(biāo)對(duì)象。

缺點(diǎn)：

• 在客戶(hù)端和真實(shí)對(duì)象之間增加了代理，可能會(huì)導(dǎo)致請(qǐng)求的處理速度變慢。
• 增加了系統(tǒng)復(fù)雜度。

代理模式在 Spring Security 中最重要的應(yīng)用就是 Spring Security 過(guò)濾器鏈接入 Web Filter 的過(guò)程，使用了 Spring 提供的 DelegatingFilterProxy，這就是一個(gè)典型的代理模式：

public class DelegatingFilterProxy extends GenericFilterBean { 
 @Override 
 public void doFilter(ServletRequest request, ServletResponse response, FilterChain filterChain) 
   throws ServletException, IOException { 
 
  // Lazily initialize the delegate if necessary. 
  Filter delegateToUse = this.delegate; 
  if (delegateToUse == null) { 
   synchronized (this.delegateMonitor) { 
    delegateToUse = this.delegate; 
    if (delegateToUse == null) { 
     WebApplicationContext wac = findWebApplicationContext(); 
     if (wac == null) { 
      throw new IllegalStateException("No WebApplicationContext found: " + 
        "no ContextLoaderListener or DispatcherServlet registered?"); 
     } 
     delegateToUse = initDelegate(wac); 
    } 
    this.delegate = delegateToUse; 
   } 
  } 
 
  // Let the delegate perform the actual doFilter operation. 
  invokeDelegate(delegateToUse, request, response, filterChain); 
 } 
} 

當(dāng)然還有其他很多地方也用到代理模式，我就不一一列舉了，歡迎小伙伴們留言補(bǔ)充。

5.適配器模式

Adapter Pattern(適配器模式)，大家平時(shí)用的手機(jī)充電器學(xué)名叫做電源適配器，它的作用是把 220V 的電壓轉(zhuǎn)為手機(jī)可用的 5V 電壓。所以適配器模式其實(shí)也是類(lèi)似作用，將一個(gè)接口轉(zhuǎn)換成客戶(hù)希望的另一個(gè)接口，適配器模式使接口不兼容的類(lèi)可以一起工作。適配器模式又分為類(lèi)適配器模式、對(duì)象適配器模式以及接口適配器模式。

適配器模式的優(yōu)點(diǎn)：

• 解耦，通過(guò)引入一個(gè)適配器類(lèi)來(lái)重用現(xiàn)有的適配者類(lèi)，而無(wú)須修改原有代碼。
• 增加了類(lèi)的透明性和復(fù)用性。
• 具有較好的靈活性和擴(kuò)展性都。

缺點(diǎn)：

• 由于 Java 不支持多重繼承，一次最多只能適配一個(gè)適配者類(lèi)，而且目標(biāo)抽象類(lèi)只能為抽象類(lèi)，不能為具體類(lèi)，其使用有一定的局限性。

Spring Security 中的適配器模式也是非常多的，例如我們最為常見(jiàn)的 WebSecurityConfigurerAdapter，該類(lèi)讓兩個(gè)原本不相關(guān)的 WebSecurity 和 HttpSecurity 能夠在一起工作。

具體參見(jiàn)：深入理解 WebSecurityConfigurerAdapter【源碼篇】

6.建造者模式

Builder Pattern(建造者模式)是將一個(gè)復(fù)雜對(duì)象的構(gòu)建與它的表示分離，使得同樣的構(gòu)建過(guò)程可以創(chuàng)建不同的對(duì)象出來(lái)，用戶(hù)只需要指定復(fù)雜對(duì)象的類(lèi)型和內(nèi)容就可以構(gòu)建對(duì)象，而不需要知道內(nèi)部的具體構(gòu)建細(xì)節(jié)。

建造者模式優(yōu)點(diǎn)：

• 將產(chǎn)品本身與產(chǎn)品的創(chuàng)建過(guò)程解耦，使得相同的創(chuàng)建過(guò)程可以創(chuàng)建不同的產(chǎn)品對(duì)象，而客戶(hù)端不需要知道產(chǎn)品內(nèi)部細(xì)節(jié)。
• 每一個(gè)產(chǎn)品對(duì)應(yīng)一個(gè)建造者，用戶(hù)使用不同的建造者可以創(chuàng)建不同的產(chǎn)品，建造者本身可以輕松修改或者添加。
• 可以更加精細(xì)地控制產(chǎn)品的創(chuàng)建過(guò)程。

缺點(diǎn)：

• 創(chuàng)建的產(chǎn)品需要有一定的相似性，如果差異過(guò)大，則不適合建造者模式。
• 產(chǎn)品本身的復(fù)雜度會(huì)提高建造者的復(fù)雜度。

Spring Security 中對(duì)于建造者模式的使用也是非常多，例如典型的 AuthenticationManagerBuilder，它想要建造的對(duì)象是 AuthenticationManager，對(duì)應(yīng)的建造方法則是 build。一般建造者模式中建造者類(lèi)命名以 builder 結(jié)尾，而建造方法命名為 build()。

關(guān)于 AuthenticationManagerBuilder，參見(jiàn)：深入理解 AuthenticationManagerBuilder 【源碼篇】 一文。

7.觀察者模式

Observer(觀察者模式)指多個(gè)對(duì)象間存在一對(duì)多的依賴(lài)關(guān)系，當(dāng)一個(gè)對(duì)象的狀態(tài)發(fā)生改變時(shí)，所有依賴(lài)于它的對(duì)象都得到通知并自動(dòng)更新，觀察者模式也稱(chēng)為發(fā)布-訂閱模式、模型-視圖模式，它是對(duì)象行為型模式。

觀察者模式優(yōu)點(diǎn)：

• 降低了目標(biāo)與觀察者之間的耦合關(guān)系，兩者之間是抽象耦合關(guān)系。

缺點(diǎn)：

• 目標(biāo)與觀察者之間的依賴(lài)關(guān)系并沒(méi)有完全解除，而且有可能出現(xiàn)循環(huán)引用。
• 當(dāng)觀察者對(duì)象很多時(shí)，程序執(zhí)行效率降低。

在 Spring 框架中，觀察者模式用于實(shí)現(xiàn) ApplicationContext 的事件處理功能。Spring 為我們提供了 ApplicationEvent 類(lèi)和 ApplicationListener 接口來(lái)啟用事件處理。Spring 應(yīng)用程序中的任何 Bean 實(shí)現(xiàn) ApplicationListener 接口，都會(huì)接收到 ApplicationEvent 作為事件發(fā)布者推送的消息。在這里，事件發(fā)布者是主題(Subject) 和實(shí)現(xiàn) ApplicationListener 的 Bean 的觀察者(Observer)。

具體到 Spring Security 中，如登錄成功事件發(fā)布，session 銷(xiāo)毀事件等等，都算是觀察者模式。

例如 AbstractAuthenticationProcessingFilter#successfulAuthentication 方法：

protected void successfulAuthentication(HttpServletRequest request, 
  HttpServletResponse response, FilterChain chain, Authentication authResult) 
  throws IOException, ServletException { 
 if (logger.isDebugEnabled()) { 
  logger.debug("Authentication success. Updating SecurityContextHolder to contain: " 
    + authResult); 
 } 
 SecurityContextHolder.getContext().setAuthentication(authResult); 
 rememberMeServices.loginSuccess(request, response, authResult); 
 // Fire event 
 if (this.eventPublisher != null) { 
  eventPublisher.publishEvent(new InteractiveAuthenticationSuccessEvent( 
    authResult, this.getClass())); 
 } 
 successHandler.onAuthenticationSuccess(request, response, authResult); 
} 

8.裝飾模式

Decorator(裝飾模式)是指在不改變現(xiàn)有對(duì)象結(jié)構(gòu)的情況下，動(dòng)態(tài)地給該對(duì)象增加一些額外功能的模式。

裝飾模式的優(yōu)點(diǎn)：

• 可以靈活的擴(kuò)展一個(gè)類(lèi)的功能。

缺點(diǎn)：

• 增加了許多子類(lèi)，使程序變得很復(fù)雜。

Spring Security 中對(duì)于裝飾模式也有許多應(yīng)用。最典型的就是一個(gè)請(qǐng)求在通過(guò)過(guò)濾器鏈的時(shí)候會(huì)不停的變，會(huì)不停的調(diào)整它的功能，通過(guò)裝飾模式設(shè)計(jì)出了請(qǐng)求的許多類(lèi)，例如：

• HeaderWriterRequest
• FirewalledRequest
• StrictHttpFirewall
• SaveToSessionRequestWrapper
• ...

等等，類(lèi)似的很多，我就不一一贅述了。

本文轉(zhuǎn)載自微信公眾號(hào)「江南一點(diǎn)雨」，可以通過(guò)以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系江南一點(diǎn)雨公眾號(hào)。