聊聊 Spring 框架用到的設計模式
Spring框架不乏優秀的代碼設計，本文將深入源碼層級來聊聊Spring中那些經典的設計模式的落地，希望對你有幫助。
一、設計模式的七大原則
整體來說有七大原則：
- 開閉原則：對擴展開放，對修改關閉。
- 里氏轉換：子類繼承父類時，除添加新的方法完成新增功能外，盡量不要重寫父類的方法。
- 依賴倒置：高層類應該依賴于底層類的抽象而不是具體。
- 合成復用：盡量使用對象組合/聚合，而不是繼承關系達到軟件復用的目的。
- 單一職責：不要多于一個導致類變更的原因。
- 接口原則：用多個接口確定類的行為，而不是一個總接口定義所有行為。
- 迪米特法則：最少知道原則，一個類應該盡可能減少對其他類的了解，避免類之間過度耦合。(其他類應該封裝一個方法提供的該類使用)
二、設計模式分類概覽
1. 創建型模式
創建型模式主要用于創建對象，對應的設計模式有：
- 單例模式：確保類有且只有一個對象被創建，全局單例。
- 抽象工廠模式：允許客戶創建對象的宗族，而無需指定他們的具體類。
- 建造者模式：將一個復雜對象的構建與它的表示分離，讓同樣的構建過程而已創建不同的表示。
- 工廠方法模式:由類決定要創建的具體類是哪一個。
- 原型模式：用原型實例指定創建對象的種類，并且通過拷貝這個原型來創建新的對象。
2. 結構型模式
結構型模式主要用于處理不同類之間的組合與依賴關系,對應的設計模式有：
- 適配器模式：封裝對象，并提供不同的接口。
- 橋接模式：將抽象部分和實現部分分離，讓他們獨立的變化。
- 裝飾模式：包裝一個對象，提供新的行為。
- 組合模式：客戶用一致的方式處理對象集合和單個對象。
- 外觀模式：簡化一群類的接口。
- 享元模式：運用共享技術有效的支持大量細粒度的對象。
- 代理模式：包裝對象，以控制對此對象的訪問。
3. 行為型模式
行為型模式主要用于描述對類或對象怎樣交互和怎樣分配職責，對應的設計模式有：
- 模板方法模式：定義一個操作算法的總體架構，將一些步驟的實現放在子類中。
- 命令模式：封裝請求成為對象。
- 迭代器模式：在對象的集合之中游走，而不是暴露集合的實現。
- 觀察者模式：讓對象能夠在狀態改變時被通知。
- 中介者模式：用一個中介對象來封裝一系列的對象交互。中介者使各個對象不需要顯示的相互引用，從而使其耦合松散，而且可以獨立地改變他們之間的交互。
- 備忘錄模式：在不破壞封裝性的前提下，捕獲一個對象的內部狀態，并在該對象之外保存這個狀態。 以后就可以將該對象恢復到保存狀態。
- 解釋器模式：介紹給定一個語言，定義它的文法的一種表示，并定義一個解釋器, 該解釋器使用該表示來解釋語言中的句子。
- 狀態模式：封裝了基于狀態的行為，并使用委托在行為之間的切換。
- 策略模式：封裝可以互換的行為，并使用委托來決定要使用哪一個。
- 責任鏈模式：為了解除請求的發送者和接收者之間的耦合，使多個對象都有機會處理這個請求。將這些處理對象連成一個鏈，并沿著這個鏈傳遞該請求，直到一個對象處理它。
- 訪問者模式：一個作用于某對象結構中的各元素的操作。它使你可以在不改變各元素的類的前提下定義作用于這些元素的新操作。
三、詳解Spring幾種經典的設計模式
1. Spring源碼中的簡單工廠模式
簡單工廠模式的思想就是對外屏蔽創建對象的細節，將對象的獲取統一內聚到一個工廠類中，這一點在Spring中的ApplicationContext 發揮的淋漓盡致。 我們都知道Spring將所有java bean統一交由三級緩存進行管理，使用時我們可以通過上下文或者需要的java bean，用戶只需按需要傳遞給工廠對應的bean名稱即可得到自己需要的對象即可：
對應的我們也給出使用示例：
@Autowired
private ApplicationContext applicationContext;
public Object getBean(String beanName) {
//基于應用上下文獲取java bean
Object bean = applicationContext.getBean(beanName);
return bean;
}2. Spring中的工廠方法模式
工廠方法模式適用于想讓工廠專注創建一個對象的場景，相較于簡單工廠模式，工廠方法模式思想是提供一個工廠的接口，開發者根據這個規范創建不同的工廠，然后按需使用不同的工廠創建不同的類即可。這種做法確保了工廠類也遵循開閉原則。
Spring中的FactoryBean就是工廠方法模式的典型實現，如果我們希望容器中能夠提供一個可以創造指定類的工廠，那么我們就可以通過FactoryBean實現。 例如我們希望有一個工廠可以創建經理，另一個工廠可以創建主管。那么我們就可以通過FactoryBean實現。 實現步驟如下，由于經理和主管都是雇員類，所以我們創建一個雇員類：
//雇員類
public class EmployeeDTO {
private Integer id;
private String firstName;
private String lastName;
private String designation;
//Setters and Getters are hidden behind this comment.
public Integer getId() {
return id;
}
public void setId(Integer id) {
this.id = id;
}
public String getFirstName() {
return firstName;
}
public void setFirstName(String firstName) {
this.firstName = firstName;
}
public String getLastName() {
return lastName;
}
public void setLastName(String lastName) {
this.lastName = lastName;
}
public String getDesignation() {
return designation;
}
public void setDesignation(String designation) {
this.designation = designation;
}
@Override
public String toString() {
return "Employee [id=" + id + ", firstName=" + firstName
+ ", lastName=" + lastName + ", type=" + designation + "]";
}
}然后我們繼承FactoryBean接口實現一個工廠方法類，如下所示，可以看到如果我們可以根據傳入的designation決定創建的雇員類型。
public class EmployeeFactoryBean extends AbstractFactoryBean<Object> {
// 根據這個值決定創建主管還是經理
private String designation;
public String getDesignation() {
return designation;
}
public void setDesignation(String designation) {
this.designation = designation;
}
//This method will be called by container to create new instances
@Override
protected Object createInstance() throws Exception {
EmployeeDTO employee = new EmployeeDTO();
employee.setId(-1);
employee.setFirstName("dummy");
employee.setLastName("dummy");
//Set designation here
employee.setDesignation(designation);
return employee;
}
//This method is required for autowiring to work correctly
@Override
public Class<EmployeeDTO> getObjectType() {
return EmployeeDTO.class;
}
}兩種雇員的配置如下所示：
<!--factoryBean使用示例-->
<!--經理工廠-->
<bean id="manager" class="com.study.service.EmployeeFactoryBean">
<property name="designation" value="Manager" />
</bean>
<!--主管工廠-->
<bean id="director" class="com.study.service.EmployeeFactoryBean">
<property name="designation" value="Director" />
</bean>如果我們想創建director（主管）的工廠，那么我們的代碼就可以這樣使用，注意我們獲取bean時必須使用&，否則獲得的就不是EmployeeFactoryBean，則是EmployeeDTO
ApplicationContext context = new ClassPathXmlApplicationContext("spring-config.xml");
Object factory = context.getBean("&director");
System.out.println(factory);
//工廠方法模式，通過單一職責的工廠獲取專門的類
System.out.println(((EmployeeFactoryBean) factory).getObject());當然，如果想直接獲取高管或者經理，獲取bean時不加&即可代碼如下所示即可:
ApplicationContext context = new ClassPathXmlApplicationContext("spring-config.xml");
EmployeeDTO manager = (EmployeeDTO) context.getBean("manager");
System.out.println(manager);
Object director = context.getBean("director");
System.out.println(director);3. Spring的中線程安全的單例模式(Double-Checked Locking)的實現
Spring中獲取對象實例的方法即DefaultSingletonBeanRegistry中的getSingleton就是典型的Double-Checked Locking單例模式代碼：
@Nullable
protected Object getSingleton(String beanName, boolean allowEarlyReference) {
// Quick check for existing instance without full singleton lock
Object singletonObject = this.singletonObjects.get(beanName);
//一級緩存沒有需要的bean，進入該邏輯
if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
singletonObject = this.earlySingletonObjects.get(beanName);
if (singletonObject == null && allowEarlyReference) {
//二級對象也沒有，上鎖進入創建邏輯
synchronized (this.singletonObjects) {
// 再次檢查一級緩存也沒有，避免重復創建問題
singletonObject = this.singletonObjects.get(beanName);
if (singletonObject == null) {
//......
//創建對象存入二級緩存中
}
}
}
}
}
return singletonObject;
}4. Spring中的代理模式
代理模式解耦了調用者和被調用者的關系，同時通過對原生類型的代理進行增強易于拓展和維護，Spring AOP就是通過代理模式實現增強切入，我們就以JDK代理為例查看Spring中的實現：
public Object getProxy(@Nullable ClassLoader classLoader) {
// ......
Class<?>[] proxiedInterfaces = AopProxyUtils.completeProxiedInterfaces(this.advised, true);
findDefinedEqualsAndHashCodeMethods(proxiedInterfaces);
//通過被代理的類的接口以及增強邏輯創建一個增強的用戶所需要的類
return Proxy.newProxyInstance(classLoader, proxiedInterfaces, this);
}查看newProxyInstance的實現即可看到jdk代理的傳統創建細節即拿到被代理的類類型和需要增強后的方法實現InvocationHandler 通過反射完成代理類創建：
@CallerSensitive
public static Object newProxyInstance(ClassLoader loader,
Class<?>[] interfaces,
InvocationHandler h)
throws IllegalArgumentException
{
//......
//獲取接口類類型
Class<?> cl = getProxyClass0(loader, intfs);
//......
//從緩存中獲取代理類的構造方法
final Constructor<?> cons = cl.getConstructor(constructorParams);
final InvocationHandler ih = h;
//......
//基于InvocationHandler 和構造方法完成代理類創建
return cons.newInstance(new Object[]{h});
} catch (IllegalAccessException|InstantiationException e) {
//......
} catch (InvocationTargetException e) {
//......
} catch (NoSuchMethodException e) {
throw new InternalError(e.toString(), e);
}
}5. Spring中的模板方法模式
模板方法模式即固定一個算法骨架，抽象出某些可變的方法交給子類實現，Spring的AbstractApplicationContext的refresh方法就是典型模板方法模式，
@Override
public void refresh() throws BeansException, IllegalStateException {
// 給容器refresh加鎖，避免容器處在refresh階段時，容器進行了初始化或者銷毀的操作
synchronized (this.startupShutdownMonitor) {
// .........
try {
// .........
//定義了相關接口給用戶實現，該方法會通過回調的方式調用這些方法,已經實現好的細節
invokeBeanFactoryPostProcessors(beanFactory);
// 注冊攔截bean創建過程的BeanPostProcessor，已經實現好的細節
registerBeanPostProcessors(beanFactory);
//模板方法的體現，用戶可自定義重寫該方法
onRefresh();
//.......
}
// .......
}
}6. Spring中的觀察者模式
觀察者模式是一種行為型模式。 它表示的是一種主題與訂閱者之間具有依賴關系，當訂閱者訂閱的主題狀態發生改變，會發送通知給響應訂閱者，觸發訂閱者的響應操作。
Spring 事件驅動模型就是觀察者模式很經典的一個應用。Spring 事件驅動模型非常有用，在很多場景都可以解耦我們的代碼。比如我們每次發布一個通知就需要某個用戶做出收到的響應，這個時候就可以利用觀察者模式來解決這個問題。
首先我們需要定義一個事件類：
public class DemoEvent extends ApplicationEvent {
private String msg;
public DemoEvent(Object source, String msg) {
super(source);
this.msg = msg;
}
public String getMsg() {
return msg;
}
public void setMsg(String msg) {
this.msg = msg;
}
}然后創建一個監聽器集成Spring框架的ApplicationListener,對DemoEvent進行監聽：
@Component
public class DemoListener implements ApplicationListener<DemoEvent> {
private static Logger logger = LoggerFactory.getLogger(DemoListener.class);
@Override
public void onApplicationEvent(DemoEvent event) {
logger.info("收到消息，消息內容:{}", event.getMsg());
}
}這樣我們發布事件后，監聽器就接受并處理返回結果了：
@Autowired
private ApplicationContext applicationContext;
@Test
public void sendMsg() {
DemoEvent event = new DemoEvent(this, "你好");
applicationContext.publishEvent(event);
}對應輸出結果如下所示：
2022-11-22 13:03:15.814 INFO 15600 --- [ main] com.example.demo.DemoListener : 收到消息，消息內容:你好7. Spring中用到的適配器模式
適配器模式有用在在DisposableBeanAdapter適配統一處理bean銷毀上，因為我們bean銷毀方法可以通過：
- xml配置指定對應的bean以及方法名
- 繼承DisposableBean接口實現
所以這兩種不同的方法在銷毀時處理方式可能不一樣，所以Spring基于聲明了DisposableBeanAdapter這個適配器，使用時只需將DisposableBean的元信息以組合關系的方式作為適配器的成員變量，適配器就會根據這些信息從接口或者配置中拿到DisposableBean并完成調用：
對應的我們給出DisposableBeanAdapter這個適配器的構造方法，可以看到它會基于我們傳入的DisposableBean的類型判斷是走接口調用還是從配置獲取bean的調用：
public DisposableBeanAdapter(
Object bean, List<DestructionAwareBeanPostProcessor> postProcessors, AccessControlContext acc) {
//......
//根據傳入的bean的類型決定走接口還是走配置獲取bean的調用
this.invokeDisposableBean = (this.bean instanceof DisposableBean);
//......
}基于上述信息將DisposableBean封裝為DisposableBeanAdapter，調用destroy時適配器就可以靈活根據invokeDisposableBean 決定銷毀邏輯的實現：
@Override
public void destroy() {
//......
//如果是接口實現則執行該類實現的destroy方法
if (this.invokeDisposableBean) {
//......
try {
if (System.getSecurityManager() != null) {
//......
}
else {
//
((DisposableBean) this.bean).destroy();
}
}
catch (Throwable ex) {
//......
}
}
//如果有注解或者xml配置的方法，則走invokeCustomDestroyMethod進行調用
if (this.destroyMethod != null) {
invokeCustomDestroyMethod(this.destroyMethod);
}
else if (this.destroyMethodName != null) {
Method methodToInvoke = determineDestroyMethod(this.destroyMethodName);
if (methodToInvoke != null) {
invokeCustomDestroyMethod(ClassUtils.getInterfaceMethodIfPossible(methodToInvoke));
}
}
}8. Spring中的裝飾者模式
裝飾者模式即通過組合的方式對原有類的行為進行一些擴展操作即在開閉原則下的一種結構型設計模式，就以Spring中的TransactionAwareCacheDecorator為例，它就是實現緩存支持事務的功能，繼承緩存接口，并將目標緩存類組合進來，保證原有類不被修改的情況下實現功能的擴展：
//繼承Cache 類
public class TransactionAwareCacheDecorator implements Cache {
//行為需要擴展的目標類
private final Cache targetCache;
// 從接口那里獲得的put方法，通過對targetCache的put進行進一步封裝實現功能的包裝
@Override
public void put(final Object key, @Nullable final Object value) {
if (TransactionSynchronizationManager.isSynchronizationActive()) {
TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronizationAdapter() {
@Override
public void afterCommit() {
TransactionAwareCacheDecorator.this.targetCache.put(key, value);
}
});
}
else {
this.targetCache.put(key, value);
}
}
}四、關于設計模式的一些常見問題
1. 為什么說Spring框架中的IOC是解耦的
從代碼層面來說，Spring通過控制反轉將對象之類依賴關系交由容器管理，如下所示我們的AService 依賴BService ，BService 可能還會依賴于CService 層層遞進，如果是傳統編碼，我們可能需要通過硬編碼的方式完成AService 的構建。 而Spring通過IOC思想，在初始化階段將所有對象都交由三級緩存管理，將所有java bean初始化責任的實現細節轉移給Spring，使用時也只需指明接口類型，接口實現也無需關心，只需在配置層面中指定，而非通過硬編碼完成依賴管理：
所以我們使用時只需幾個簡單的配置和注解即可完成各種復雜的bean的依賴管理，這也就是開發層面對象依賴關系管理的解耦：
@Service("aService")
@Slf4j
public class AService {
@Autowired
private BService bService;
//......
}從使用層面來說，Spring中的IOC也用到類似于門面模式的思想，將工具類的使用和創建剝離，整個工具類的創建過程對使用者來說是透明解耦的。
例如我們需要使用日志框架，在spring中我們只需給出簡單的配置，框架即在運行時基于給定配置完成對應的日志工具的注入(可以是log4j可以是slf4j或者其他日志框架)，程序啟動后即可直接使用功能，無需關心創建和實現：
2. 什么是策略模式
策略模式是一種行為模式，它的作用主要是用于封裝那些動作一致，但是具體實現不一致的場景。例如我們現在有一個審核的動作，不同的人審核的方式不同。而且審核的行為會隨著時間推移不斷增加，單純使用if else去維護會使得代碼變得非常凌亂。 這時候使用策略模式定義一下相同的行為，讓子類去實現不同的策略，這樣的方式是最利于拓展的。
3. 策略模式在Spring中如何使用
使用策略模式前，我們先需要使用接口固定一下策略的定義，例如我們現在要創建一個生成對象的策略createObj：
public interface CreateObjStrategy {
Object createObj();
}對應我們分別寫一個創建字符串對象和json對象的策略代碼：
@Component("createObj_str")
public class CreateStrObjStrategy implements CreateObjStrategy {
@Override
public Object createObj() {
Map<String, Object> map = new HashMap<>();
map.put("name", "xiaoming");
return JSONUtil.toJsonStr(map);
}
}
@Component("createObj_json")
public class CreateJsonObjStrategy implements CreateObjStrategy {
@Override
public Object createObj() {
JSONObject obj = new JSONObject();
obj.put("name", "zhangsan");
return obj;
}
}到此為止，我們已經完成了所有的策略的封裝，按照原生的策略模式的做法它會通過一個上下文來配置當前策略，就像下面這張設計圖：
對應我們給出封裝的代碼示例：
public class CreateJsonObjContext {
private CreateObjStrategy createObjStrategy;
public CreateJsonObjContext(CreateObjStrategy strategy) {
this.createObjStrategy = strategy;
}
public Object createObj() {
return createObjStrategy.createObj();
}
}實際上有了Spring我們無需進行顯示聲明創建了，我們可以通過配置、注解等方式指明本地程序需要注入的CreateObjStrategy 實現，加載上下文的時候通過ApplicationContextAware這樣的擴展點把bean取出來設置到CreateJsonObjContext 中：
@Component
public class CreateJsonObjContext implements ApplicationContextAware {
private CreateObjStrategy createObjStrategy;
@Override
public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
//從容器中拿到由我們配置后容器中所設置的CreateObjStrategy設置到Context中
CreateObjStrategy bean = applicationContext.getBean(CreateObjStrategy.class);
createObjStrategy = bean;
}
public Object createObj() {
return createObjStrategy.createObj();
}
}4. Spring中那里用到的策略模式的運用
最典型的就時InstantiationStrategy，Spring為其實現了兩種不同的策略，分別是CglibSubclassingInstantiationStrategy和SimpleInstantiationStrategy，在Spring通過實例化java bean的時候其內部就會通過getInstantiationStrategy從上下文中獲取初始化策略instantiationStrategy，然后調用instantiationStrategy的instantiate完成bean的創建：
對應的我們也給出AbstractAutowireCapableBeanFactory中instantiate實例化bean的實現印證這一說法：
private Object instantiate(String beanName, RootBeanDefinition mbd,
@Nullable Object factoryBean, Method factoryMethod, Object[] args) {
try {
else {
//通過getInstantiationStrategy獲取上下文中對應的創建策略完成bean的創建
return this.beanFactory.getInstantiationStrategy().instantiate(
mbd, beanName, this.beanFactory, factoryBean, factoryMethod, args);
}
}
catch (Throwable ex) {
//......
}
}5. 工廠方法模式相較于簡單工廠模式的優缺點
工廠方法模式的優點：
- 符合開閉原則，相較于上面說到的簡單工廠模式來說，我們無需因為增加一個類型而去修改工廠代碼，我們完全可以通過實現一個新的工廠實現。
- 更符合單一職責的原則，對于單個類型創建的工廠邏輯更加易于維護。
缺點：
- 針對特定類型都需要創建特定工廠，創建的類會增加，導致項目變得臃腫。
- 因為工廠方法的模式結構，維護的成本相對于簡單工廠模式會更高一些。
6. 單例模式的在java中的使用優勢
節省沒必要的創建對象的時間，由于是單例的對象，所以創建一次后就可以一直使用了，所以我們無需為了一個重量級對象的創建而耗費大量的資源。
由于重量級對象的創建次數少了，所以我們就避免了沒必要的GC。從而降低GC壓力，避免沒必要的STW(Stop the World)導致的GC停頓。
7. 模板方法模式的優劣勢
優勢很明顯:
- 算法骨架由父類定義，封裝不變，擴展可變。
- 子類只需按需實現抽象類即可，易于擴展維護。
- 提取了公共代碼，避免編寫重復代碼。
缺點:
- 可讀性下降
- 可能會導致子類泛濫問題。
五、小結
本文直接從底層源碼設計和實現的角度，詳盡分析了Spring中涉及的設計模式，希望對你有幫助。
