趣談設計模式

所謂 "解耦"，就是代碼和代碼說分手。

背景

  談起設計模式，你一定會問？這玩意到底有啥用？我好像沒用過也不影響做一個碼農。也可能項目中實際用了，但是你不自知。雖然 Java 設計模式有 23 種，但是工作中常用的可能並沒有那麼多。就像新華字典有多少字，你沒必要都學一樣。本章我們只談常用的幾種設計模式，通過設計模式的理念、規約、到應用，理解實戰中如何正確使用設計模式，不論對面試還是實際工作中都有益處。

文章提綱

設計理念

最爲 Java 開發者，程序員基本修養名言絕句：

• 該露露，該藏藏

• 該封裝的要封裝

• 萬事萬物兼對象

• 程序代碼要健壯

我們簡單歸納爲 2 個核心詞：高內聚、低耦合。

  很小的時候看過動畫片，封神演義中哪吒：三頭八臂顯威力，千徵百戰鬥魔法。（串臺了。。。）

我們根據這首歌詞抽象一下，哪吒：三頭八臂是靜態特徵，千徵百戰是動態技能。把這些特徵歸納映射一下：類 = 屬性 + 方法如下圖：

以上是高內聚的概念，什麼是低耦合？

如果可能，我寫一本神話《封神演戲》，說哪吒有：三頭九臂。你肯定和我吵吵，要給它再配一把兵器。雖然還沒想好是啥，但是有個總則：絕對不影響先前這八臂的演技。這就是低耦合！！！所謂程序健壯、拓展性強，也是這個道理。我們真誠地希望：

上述例子不是特別恰當，但是對於設計模式，我們終級的理念是：封裝變化的內容，保留不變的宗旨。

設計原則

設計原則可以歸納爲 2 大類：

• 開閉原則（李氏替換，組合複用，依賴倒置）

規定：軟件中的對象（類、模塊、函數等等）應該對於擴展是開放的，但是對於修改是封閉的。換句話說，一個實體是允許在不改變它的源代碼的前提下變更它的行爲。

• 單一職責（接口隔離，迪米特法則）

規定：一個類只應該有一個職責，只有一個改變它的原因

Spring 中的設計模式

在 Spring 框架中，各種設計模式被廣泛應用以支持其強大的功能和靈活性。下面我將結合 Spring 的源碼，鑑賞下 Spring 中常見的幾種設計模式。

1. 單例模式

  Spring 框架中的Bean默認就是單例的。Spring IoC 容器負責創建對象實例，並確保在整個應用中，針對同一個 Bean 的 ID，只實例化一次對象。DefaultSingletonBeanRegistry類是 Spring 管理單例 Bean 的核心類。

// DefaultSingletonBeanRegistry類中的部分源碼
public class DefaultSingletonBeanRegistry extends SimpleAliasRegistry implements SingletonBeanRegistry {
    // ...
    private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256);
    // ...
    @Override
    public Object getSingleton(String beanName) {
        return getSingleton(beanName, true);
    }
    
    protected Object getSingleton(String beanName, boolean allowEarlyReference) {
        // ... 省略部分代碼
        Object singletonObject = this.singletonObjects.get(beanName);
        if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
            synchronized (this.singletonObjects) {
                singletonObject = this.earlySingletonObjects.get(beanName);
                if (singletonObject == null && allowEarlyReference) {
                    ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
                    if (singletonFactory != null) {
                        singletonObject = singletonFactory.getObject();
                        this.earlySingletonObjects.put(beanName, singletonObject);
                        this.singletonFactories.remove(beanName);
                    }
                }
            }
        }
        return (singletonObject != NULL_OBJECT ? singletonObject : null);
    }
    // ...
}

2. 工廠模式

Spring 使用工廠模式通過BeanFactory、ApplicationContext等接口創建和管理 Bean 對象。DefaultListableBeanFactory是 Spring 中 Bean 工廠的實現類。

// DefaultListableBeanFactory類中的部分源碼
public class DefaultListableBeanFactory extends AbstractAutowireCapableBeanFactory
        implements ConfigurableListableBeanFactory, BeanDefinitionRegistry, Serializable {
    // ...
    @Override
    public <T> T getBean(String name, Class<T> requiredType) throws BeansException {
        return doGetBean(name, requiredType, null, false);
    }

    @Override
    public <T> T getBean(Class<T> requiredType) throws BeansException {
        return doGetBean(null, requiredType, null, false);
    }
    
    // ... 省略部分代碼
}

3. 代理模式

Spring AOP（面向切面編程）的實現就是基於代理模式。Spring 創建目標對象的代理對象，並在代理對象中織入切面邏輯。JdkDynamicAopProxy和CglibAopProxy是 Spring AOP 中創建代理的兩個核心類。

// JdkDynamicAopProxy類中的部分源碼
public class JdkDynamicAopProxy implements AopProxy, InvocationHandler, Serializable {
    // ...
    @Override
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        // ... 省略部分代碼
        // 獲取AdvisedSupport對象，包含了切面等AOP相關信息
        final AdvisedSupport advised = this.advised;
        // ... 省略部分代碼
        // 獲取攔截器鏈（切面鏈）
        List<Object> chain = advised.getInterceptorsAndDynamicInterceptionAdvice(method, targetClass);
        // ... 省略部分代碼
        // 執行鏈式調用
        return invokeJoinpointUsingReflection(target, method, args, targetClass, chain);
    }
    // ...
}

4. 觀察者模式（監聽模式）

在 Spring 中，事件處理機制就是基於觀察者模式實現的。當事件發生時，所有註冊的觀察者都會收到通知並作出響應。ApplicationEventMulticaster接口和SimpleApplicationEventMulticaster類是 Spring 事件處理機制的核心。

// SimpleApplicationEventMulticaster類中的部分源碼
public class SimpleApplicationEventMulticaster extends AbstractApplicationEventMulticaster {
    // ...
    @Override
    public void multicastEvent(final ApplicationEvent event, @Nullable ResolvableType eventType) {
        ResolvableType type = (eventType != null ? eventType : resolveDefaultEventType(event));
        for (ApplicationListener<?> listener : getApplicationListeners(event, type)) {```java
            // 調用監聽器的方法處理事件
            invokeListener(listener, event);
        }
    }

    private void invokeListener(ApplicationListener<?> listener, ApplicationEvent event) {
        ErrorHandler errorHandler = getErrorHandler();
        if (errorHandler != null) {
            try {
                doInvokeListener(listener, event);
            } catch (Throwable err) {
                errorHandler.handleError(err);
            }
        } else {
            doInvokeListener(listener, event);
        }
    }

    private void doInvokeListener(ApplicationListener<?> listener, ApplicationEvent event) {
        try {
            // 調用監聽器的onApplicationEvent方法
            listener.onApplicationEvent(event);
        } catch (ClassCastException ex) {
            // ... 省略部分代碼，處理類型不匹配異常
        }
    }
    // ...
}

5. 責任鏈模式

在 Spring 中，HandlerInterceptor和HandlerInterceptorAdapter等類在處理請求攔截時，採用的就是責任鏈模式。一個請求會按照定義的攔截器順序，逐個被處理，直到找到對應的處理器或者遍歷完所有的攔截器。

// HandlerInterceptor接口定義
public interface HandlerInterceptor {
    boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler)
            throws Exception;

    void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler,
            ModelAndView modelAndView) throws Exception;

    void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex)
            throws Exception;
}

// 實現HandlerInterceptor接口的自定義攔截器
public class CustomInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler)
            throws Exception {
        // 在這裏執行前置處理邏輯
        return true; // 返回true表示繼續向下執行，返回false表示中斷請求
    }

    // ... 其他方法實現
}

6. 模版模式

Spring 中的JdbcTemplate、HibernateTemplate等類就是模版模式的典型應用。它們定義了一個操作數據庫或 Hibernate 的骨架方法，允許子類在不改變算法結構的情況下重定義某些步驟的具體內容。

// JdbcTemplate部分源碼
public class JdbcTemplate extends JdbcAccessor implements JdbcOperations, BeanFactoryAware {
    // ...
    public <T> T query(String sql, RowMapper<T> rowMapper) {
        return query(sql, new Object[0], rowMapper);
    }

    public <T> T query(String sql, Object[] args, RowMapper<T> rowMapper) {
        return query(sql, args, rowMapper, true);
    }

    // ... 省略部分代碼，這裏是模版方法的實現
    // 真正的SQL執行和結果集處理邏輯在這裏，但是允許子類通過RowMapper來定製結果集的處理方式
    // ...
}

// 自定義RowMapper實現
public class CustomRowMapper implements RowMapper<MyObject> {
    @Override
    public MyObject mapRow(ResultSet rs, int rowNum) throws SQLException {
        // 在這裏定製如何從ResultSet中映射到MyObject對象
        return new MyObject(/* 映射邏輯 */);
    }
}

這些設計模式在 Spring 框架中被廣泛應用，能夠靈活地應對各種複雜場景，提供強大且可擴展的功能。

實戰應用

假設有這樣一個需求：

1. 業務登錄商城用戶鑑權

2. 購買產品下訂單

3. 校驗訂單填寫是否合法

4. 記錄接口中的參數

5. 訂單確認後給買家發短信通知

根據業務場景，我們大致可拆分爲：用戶流程、訂單流程

用戶登錄流程

在用戶登錄流程中，可能用到攔截器做鑑權校驗，日誌記錄接口參數等，使用了一些常見的設計模式。

場景一、用戶鑑權校驗

責任鏈模式

攔截器通常按照定義的順序執行，每個攔截器檢查特定的條件或執行特定的任務。

// 攔截器接口
public interface Interceptor {
    boolean intercept(AuthenticationContext context);
}

// 用戶校驗攔截器
public class UserValidationInterceptor implements Interceptor {
    @Override
    public boolean intercept(AuthenticationContext context) {
        // 用戶校驗邏輯
        if (isValidUser(context.getUser())) {
            return true;
        }
        return false;
    }

    private boolean isValidUser(User user) {
        // 校驗用戶是否有效
        return true; // 示例，實際中應有具體校驗邏輯
    }
}

// 鑑權校驗攔截器
public class AuthorizationInterceptor implements Interceptor {
    @Override
    public boolean intercept(AuthenticationContext context) {
        // 鑑權校驗邏輯
        if (isAuthorized(context.getUser(), context.getCredentials())) {
            return true;
        }
        return false;
    }

    private boolean isAuthorized(User user, Credentials credentials) {
        // 校驗用戶是否有權限
        return true; // 示例，實際中應有具體校驗邏輯
    }
}

// 攔截器鏈
public class InterceptorChain {
    private List<Interceptor> interceptors = new ArrayList<>();

    public void addInterceptor(Interceptor interceptor) {
        interceptors.add(interceptor);
    }

    public boolean execute(AuthenticationContext context) {
        for (Interceptor interceptor : interceptors) {
            if (!interceptor.intercept(context)) {
                // 如果攔截器返回false，則中斷鏈的執行
                return false;
            }
        }
        return true;
    }
}

場景二、記錄用戶登錄信息

單例模式

日誌記錄器通常設計爲單例，確保全局只有一個實例。

Logger logger = LoggerFactory.getLoggerFactoryInstance().getLogger();  
logger.log("This is a user log message");

在這行代碼中，體現了單例模式的核心思想，確保了無論多少次調用LoggerFactory.getLoggerFactoryInstance()，都只會返回一個LoggerFactory實例。事實上，我們從源碼中也可以看到。

訂單流程

根據業務場景，核心訂單流程如下：

場景三、訂單校驗

工廠模式

使用工廠模式實現的CheckOrderFactory，它用於創建不同類型的訂單校驗服務實例。

同時，我們定義一個校驗接口ICheckOrderService，並創建了兩個實現類: 購買數量校驗：CountCheckOrder和訂單參數校驗：ParamCheckOrder。

public interface ICheckOrderService {
    boolean checkOrder(Object order);
    String getErrorMessage();
}

購買數量校驗的實現類CountCheckOrder：

public class CountCheckOrder implements ICheckOrderService {
    @Override
    public boolean checkOrder(Object order) {
        // 假設order是一個包含購買數量的對象
        int quantity = ((Order) order).getQuantity();
        return quantity > 0; // 只允許購買數量大於0
    }

    @Override
    public String getErrorMessage() {
        return "購買數量必須大於0。";
    }
}

訂單參數校驗的實現類ParamCheckOrder：

public class ParamCheckOrder implements ICheckOrderService {
    @Override
    public boolean checkOrder(Object order) {
        // 假設order是一個包含各種訂單參數的對象
        // 這裏可以添加具體的訂單參數校驗邏輯
        return true; // 示例代碼，默認返回true
    }

    @Override
    public String getErrorMessage() {
        return "訂單參數校驗失敗。";
    }
}

工廠類CheckOrderFactory，用於創建不同類型的校驗服務實例：

public class CheckOrderFactory {
    public static ICheckOrderService createCheckOrderService(String type) {
        switch (type) {
            case "count":
                return new CountCheckOrder();
            case "param":
                return new ParamCheckOrder();
            default:
                throw new IllegalArgumentException("不支持的校驗類型: " + type);
        }
    }
}

使用工廠模式有利於業務類的實現和拓展，但是有時候也存在過度設計，導致寫了很多的業務類。

場景四、短信通知

觀察者模式（監聽模式）

在 Spring 框架中，我們可以使用ApplicationEvent和ApplicationListener來實現事件發佈和監聽的功能。

假設我們要下發一個購買成功的短信提醒，那麼就可以發佈一個自定義的PurchaseSuccessEvent事件。

import org.springframework.context.ApplicationEvent;

public class PurchaseSuccessEvent extends ApplicationEvent {
    private final String buyerPhoneNumber;
    private final String orderId;

    public PurchaseSuccessEvent(Object source, String buyerPhoneNumber, String orderId) {
        super(source);
        this.buyerPhoneNumber = buyerPhoneNumber;
        this.orderId = orderId;
    }

    public String getBuyerPhoneNumber() {
        return buyerPhoneNumber;
    }

    public String getOrderId() {
        return orderId;
    }
}

接着定義一個SmsNotificationListener類，它實現了ApplicationListener接口，用於監聽PurchaseSuccessEvent事件：

import org.springframework.context.ApplicationListener;
import org.springframework.stereotype.Component;

@Component
public class SmsNotificationListener implements ApplicationListener<PurchaseSuccessEvent> {
    
    @Override
    public void onApplicationEvent(PurchaseSuccessEvent event) {
        String message = "親愛的買家，您的訂單 " + event.getOrderId() + " 購買成功！";
        sendSms(event.getBuyerPhoneNumber(), message);
    }

    private void sendSms(String phoneNumber, String message) {
        // 在這裏實現發送短信的邏輯
        System.out.println("Sending SMS to " + phoneNumber + ": " + message);
    }
}

然後，在 Spring 的配置中啓用事件發佈功能。配置一個ApplicationEventPublisher的 bean：

import org.springframework.context.ApplicationEventPublisher;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.support.GenericApplicationContext;

@Configuration
public class AppConfig {
    
    @Bean
    public ApplicationEventPublisher applicationEventPublisher() {
        return new GenericApplicationContext();
    }
}

最後，在業務邏輯中發佈PurchaseSuccessEvent事件。

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.ApplicationEventPublisher;
import org.springframework.stereotype.Service;

@Service
public class PurchaseService {

    private final ApplicationEventPublisher applicationEventPublisher;

    @Autowired
    public PurchaseService(ApplicationEventPublisher applicationEventPublisher) {
        this.applicationEventPublisher = applicationEventPublisher;
    }

    public void completePurchase(String buyerPhoneNumber, String orderId) {
        // 模擬購買完成的業務邏輯
        // ...

        // 發佈購買成功事件
        applicationEventPublisher.publishEvent(new PurchaseSuccessEvent(this, buyerPhoneNumber, orderId));
    }
}

總結

• 使用設計模式的宗旨：封裝變化的部分，維護不變的宗旨

• 好處：提高代碼拓展性，程序更優雅更健壯

• 對開源框架設計模式的使用，要提高鑑賞能力

• 考慮可讀性，不可爲了設計模式而過度設計

• 採石之人，應有建設大教堂的願景

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/d85I6n0qbbEWI9H6JmlXlg