如何在Spring Boot中使用設計模式 – 通過代碼示例解釋

隨著軟體專案的成長，保持程式碼有組織、易維護和可擴展性變得越來越重要。這就是設計模式發揮作用的地方。設計模式提供了經過驗證的、可重複使用的解決方案來應對常見的軟體設計挑戰，讓您的程式碼更高效且更易管理。

在本指南中，我們將深入探討一些最受歡迎的設計模式，並向您展示如何在Spring Boot中實施它們。最終，您將不僅在概念上理解這些模式，還能自信地應用它們在您自己的專案中。

目錄

• 設計模式簡介

• 如何設定您的Spring Boot專案

• 單例模式是什麼？

• 工廠模式是什麼？

• 什麼是策略模式？

• 什麼是觀察者模式？

• 如何使用Spring Boot的依賴注入

• 最佳實踐和優化技巧

• 結論和要點

設計模式介紹

設計模式是對常見軟體設計問題的可重複使用解決方案。將它們視為融入模板的最佳實踐，可以應用於解決程式碼中特定挑戰。它們不特定於任何語言，但由於Java具有物件導向的特性，它們在Java中特別強大。

在本指南中，我們將涵蓋：

• 單例模式：確保類別僅具有一個實例。

• 工廠模式：在不指定確切類別的情況下創建物件。

• 策略模式：允許在執行時選擇演算法。

• 觀察者模式：建立發布-訂閱關係。

我們將不僅涵蓋這些模式的運作方式，還將探討它們如何應用於Spring Boot中的實際應用程式。

如何設置您的Spring Boot專案

在深入探討這些模式之前，讓我們設置一個Spring Boot專案：

先決條件

確保您擁有：

• Java 11+

• Maven

• Spring Boot CLI（可選）

• Postman或curl（用於測試）

項目初始化

您可以使用Spring Initializr快速創建Spring Boot項目：

curl https://start.spring.io/starter.zip \
-d dependencies=web \
-d name=DesignPatternsDemo \
-d javaVersion=11 -o design-patterns-demo.zip
unzip design-patterns-demo.zip
cd design-patterns-demo

單例模式是什麼？

單例模式確保類只有一個實例並提供全局訪問點。這種模式通常用於日誌記錄、配置管理或數據庫連接等服務。

如何在Spring Boot中實現單例模式

Spring Boot beans默認是單例的，這意味著Spring自動管理這些beans的生命週期，以確保只存在一個實例。然而，重要的是要了解單例模式在底層是如何工作的，特別是當您不使用Spring管理的beans或需要更多對實例管理的控制時。

讓我們通過手動實現單例模式來演示如何控制應用程序中單個實例的創建。

步驟1：創建一個LoggerService類

在這個例子中，我們將使用單例模式創建一個簡單的日誌記錄服務。目標是確保應用程序的所有部分使用相同的日誌記錄實例。

public class LoggerService {
    // 用於保存單個實例的靜態變數
    private static LoggerService instance;

    // 私有構造函數，防止外部實例化
    private LoggerService() {
        // 此構造函數故意為空，以防止其他類創建實例
    }

    // 公共方法，提供訪問單個實例
    public static synchronized LoggerService getInstance() {
        if (instance == null) {
            instance = new LoggerService();
        }
        return instance;
    }

    // 示例日誌方法
    public void log(String message) {
        System.out.println("[LOG] " + message);
    }
}

• 靜態變數（instance）：這個變數保存了LoggerService的單個實例。

• 私有構造函數：將構造函數標記為私有，以防止其他類直接創建新實例。

• 同步 getInstance() 方法：此方法同步，確保它是線程安全的，即使多個線程同時訪問，也只創建一個實例。

• 延遲初始化：只有在第一次被要求時才創建實例（延遲初始化），這對於內存使用效率很高。

現實世界中的用途：這種模式通常用於共享資源，例如日誌記錄、配置設置或管理數據庫連接，您希望控制訪問並確保整個應用程序中只使用一個實例。

步驟2：在Spring Boot控制器中使用單例

現在，讓我們看看如何在Spring Boot控制器中使用我們的LoggerService單例。該控制器將公開一個端點，每次訪問時都會記錄一條消息。

import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class LogController {

    @GetMapping("/log")
    public ResponseEntity<String> logMessage() {
        // 訪問LoggerService的單例實例
        LoggerService logger = LoggerService.getInstance();
        logger.log("This is a log message!");
        return ResponseEntity.ok("Message logged successfully");
    }
}

• GET端點：我們已創建一個/log端點，當訪問時，將使用LoggerService記錄一條消息。

• 單例使用：我們不是創建LoggerService的新實例，而是調用getInstance()來確保每次使用的是同一個實例。

• 響應: 記錄後，端點返回一個表示成功的響應。

步驟3: 測試單例模式

現在，讓我們使用 Postman 或您的瀏覽器來測試這個端點：

GET http://localhost:8080/log

預期輸出:

• 控制台日誌: [LOG] 這是一條日誌消息！

• HTTP 響應: 消息成功記錄

您可以多次調用該端點，您將看到一致的日誌輸出表明使用的是同一個 LoggerService 實例。

單例模式的現實應用案例

以下是您可能希望在現實應用中使用單例模式的情況：

1. 配置管理: 確保應用程序使用一致的配置設置集，特別是當這些設置從文件或數據庫中加載時。

2. 資料庫連接池：控制對有限數量的資料庫連接的訪問，確保相同的連接池在應用程序中共享。

3. 快取：維護單個快取實例，以避免數據不一致。

4. 記錄服務：如本示例所示，使用單個記錄服務來集中應用程序的不同模塊中的日誌輸出。

關鍵要點

• 單例模式是確保只創建一個類實例的簡單方法。

• 如果多個線程訪問單例很重要，這就是為什麼我們在示例中使用了synchronized。

• Spring Boot beans默認已經是單例，但了解如何手動實現有助於在需要時獲得更多控制。

這涵蓋了單例模式的實現和使用。接下來，我們將探討工廠模式，看看它如何幫助流暢地創建對象。

什麼是工廠模式？

工廠模式允許您創建對象而無需指定確切的類。當您有不同類型的對象需要基於某些輸入實例化時，這種模式很有用。

在Spring Boot中如何實現工廠模式

當您需要基於某些標準創建對象但希望將對象創建過程與主應用程序邏輯解耦時，工廠模式非常有用。

在本部分中，我們將逐步構建一個NotificationFactory來通過電子郵件或短信發送通知。如果您預計將來添加更多通知類型，例如推送通知或應用內警報，而不更改現有代碼，這將非常有用。

第1步：創建Notification接口

第一步是定義所有通知類型將實現的共同接口。這確保每種類型的通知（電子郵件、短信等）都將具有一致的send()方法。

public interface Notification {
    void send(String message);
}

• 目的： Notification接口定義了發送通知的合同。實現此接口的任何類必須為send()方法提供實現。

• 可擴展性: 通過使用介面，您可以在不修改現有代碼的情況下輕鬆擴展應用程序以包括其他類型的通知。

步驟2: 實現EmailNotification和SMSNotification

現在，讓我們實現兩個具體類，一個用於發送電子郵件，另一個用於發送短信消息。

public class EmailNotification implements Notification {
    @Override
    public void send(String message) {
        System.out.println("Sending Email: " + message);
    }
}

public class SMSNotification implements Notification {
    @Override
    public void send(String message) {
        System.out.println("Sending SMS: " + message);
    }
}

步驟3: 創建NotificationFactory

NotificationFactory類負責根據指定的類型創建Notification的實例。這種設計確保NotificationController不需要知道物件創建的詳細信息。

public class NotificationFactory {
    public static Notification createNotification(String type) {
        switch (type.toUpperCase()) {
            case "EMAIL":
                return new EmailNotification();
            case "SMS":
                return new SMSNotification();
            default:
                throw new IllegalArgumentException("Unknown notification type: " + type);
        }
    }
}

工廠方法 (createNotification()):

• 工廠方法接受一個字符串（type）作為輸入，並返回相應通知類的實例。

• Switch語句: switch語句根據輸入選擇適當的通知類型。

• 錯誤處理：如果提供的類型未被識別，則會拋出IllegalArgumentException。這確保無效類型被及早捕獲。

為什麼使用工廠模式？

• 解耦：工廠模式將對象創建與業務邏輯解耦。這使得代碼更加模塊化且易於維護。

• 可擴展性：如果要添加新的通知類型，只需更新工廠而無需更改控制器邏輯。

第四步：在Spring Boot控制器中使用工廠

現在，讓我們通過創建一個Spring Boot控制器來將所有內容整合在一起，該控制器使用NotificationFactory根據用戶請求發送通知。

import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class NotificationController {

    @GetMapping("/notify")
    public ResponseEntity<String> notify(@RequestParam String type, @RequestParam String message) {
        try {
            // 使用工廠創建適當的通知對象
            Notification notification = NotificationFactory.createNotification(type);
            notification.send(message);
            return ResponseEntity.ok("Notification sent successfully!");
        } catch (IllegalArgumentException e) {
            return ResponseEntity.badRequest().body(e.getMessage());
        }
    }
}

GET端點（/notify）：

• 該控制器公開一個接受兩個查詢參數的/notify端點：type（可以是”EMAIL”或”SMS”）和message。

• 它使用NotificationFactory來創建適當的通知類型並發送消息。

• 錯誤處理：如果提供了無效的通知類型，控制器會捕獲IllegalArgumentException並返回400 Bad Request響應。

步驟5：測試工廠模式

讓我們使用Postman或瀏覽器測試端點：

1. 發送電子郵件通知：

    GET http://localhost:8080/notify?type=email&message=Hello%20Email
   

   輸出：

    發送郵件：Hello Email
   

2. 發送短訊通知:

    GET http://localhost:8080/notify?type=sms&message=Hello%20SMS
   

   輸出:

    發送短訊: Hello SMS
   

3. 使用無效類型進行測試:

    GET http://localhost:8080/notify?type=unknown&message=Test
   

   輸出:

    不良請求: 未知的通知類型: unknown
   

工廠模式的實際應用案例

工廠模式在以下情況特別有用:

1. 動態對象創建: 當您需要根據用戶輸入創建對象時，例如發送不同類型的通知、生成不同格式的報告或處理不同的支付方式時。

2. 解耦對象創建: 通過使用工廠，您可以將主要業務邏輯與對象創建分開，使代碼更易於維護。

3. 可擴展性: 輕鬆擴展應用程序以支持新類型的通知，而無需修改現有代碼。只需添加一個實現通知接口的新類，並更新工廠。

策略模式是什麼？

當您需要在多個算法或行為之間動態切換時，策略模式非常適用。它允許您定義一組算法，將每個算法封裝在單獨的類中，並使它們在運行時輕鬆交換。這對於根據特定條件選擇算法特別有用，使您的代碼保持乾淨、模塊化和靈活。

真實應用案例：想像一個需要支援多種付款方式（如信用卡、PayPal 或銀行轉帳）的電子商務系統。通過使用策略模式，您可以輕鬆添加或修改付款方式，而無需修改現有代碼。這種方法確保您的應用程序在引入新功能或更新現有功能時保持可擴展性和可維護性。

我們將通過一個Spring Boot示例來演示這種模式，該示例使用信用卡或PayPal策略來處理付款。

第1步：定義一個PaymentStrategy介面

我們首先創建一個所有付款策略都會實現的共同接口：

public interface PaymentStrategy {
    void pay(double amount);
}

該接口為所有付款方法定義了一個契約，確保實現的一致性。

第2步：實現付款策略

創建信用卡和PayPal付款的具體類別。

public class CreditCardPayment implements PaymentStrategy {
    @Override
    public void pay(double amount) {
        System.out.println("Paid $" + amount + " with Credit Card");
    }
}

public class PayPalPayment implements PaymentStrategy {
    @Override
    public void pay(double amount) {
        System.out.println("Paid $" + amount + " via PayPal");
    }
}

每個類別都使用其特定行為來實現pay()方法。

第3步：在控制器中使用策略

創建一個控制器，根據用戶輸入動態選擇付款策略：

import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class PaymentController {

    @GetMapping("/pay")
    public ResponseEntity<String> processPayment(@RequestParam String method, @RequestParam double amount) {
        PaymentStrategy strategy = selectPaymentStrategy(method);
        if (strategy == null) {
            return ResponseEntity.badRequest().body("Invalid payment method");
        }
        strategy.pay(amount);
        return ResponseEntity.ok("Payment processed successfully!");
    }

    private PaymentStrategy selectPaymentStrategy(String method) {
        switch (method.toUpperCase()) {
            case "CREDIT": return new CreditCardPayment();
            case "PAYPAL": return new PayPalPayment();
            default: return null;
        }
    }
}

該端點接受method和amount作為查詢參數，並使用適當的策略處理付款。

第4步：測試端點

1. 信用卡付款:

    GET http://localhost:8080/pay?method=credit&amount=100
   

   輸出: 使用信用卡支付 $100.0

2. PayPal 付款:

    GET http://localhost:8080/pay?method=paypal&amount=50
   

   輸出: 透過 PayPal 支付 $50.0

3. 無效方法:

    GET http://localhost:8080/pay?method=bitcoin&amount=25
   

   輸出: 無效的支付方式

策略模式的使用案例

• 支付處理：動態切換不同的支付網關。

• 排序算法：根據數據大小選擇最佳排序方法。

• 文件導出：以各種格式（PDF、Excel、CSV）導出報告。

要點

• 策略模式使代碼保持模塊化，遵循開放/封閉原則。

• 添加新策略很容易——只需創建實現PaymentStrategy接口的新類。

• 它非常適合需要在運行時靈活選擇算法的情況。

接下來，我們將探討觀察者模式，非常適用於處理事件驅動架構。

觀察者模式是什麼？

觀察者模式在您有一個對象（主題）需要通知多個其他對象（觀察者）其狀態變化時是理想的。這在事件驅動系統中非常適用，其中需要將更新推送給各種組件，而不會在它們之間創建緊密耦合。這種模式讓您能夠保持清晰的架構，尤其是當系統的不同部分需要獨立地對變化做出反應時。

現實世界的使用案例：此模式通常用於發送通知或警報的系統，例如聊天應用程序或股價追踪器，在這些系統中，更新需要即時推送給用戶。通過使用觀察者模式，您可以輕鬆地添加或刪除通知類型，而無需改變核心邏輯。

我們將演示如何在Spring Boot中實現此模式，構建一個簡單的通知系統，在該系統中，每當用戶註冊時都會發送電子郵件和短信通知。

步驟1：創建一個Observer介面

我們首先定義所有觀察者都將實現的共同介面：

public interface Observer {
    void update(String event);
}

該介面確立了一個契約，即所有觀察者都必須實現update()方法，該方法將在主題更改時觸發。

步驟2：實現EmailObserver和SMSObserver

接下來，我們創建兩個Observer介面的具體實現，以處理電子郵件和短信通知。

EmailObserver類

public class EmailObserver implements Observer {
    @Override
    public void update(String event) {
        System.out.println("Email sent for event: " + event);
    }
}

EmailObserver處理在事件發生時發送電子郵件通知。

SMSObserver 類

public class SMSObserver implements Observer {
    @Override
    public void update(String event) {
        System.out.println("SMS sent for event: " + event);
    }
}

SMSObserver 處理當接收通知時發送短信通知。

步驟 3： 創建一個 UserService 類（主題）

現在我們將創建一個 UserService 類，作為主題，當用戶註冊時通知其註冊的觀察者。

import org.springframework.stereotype.Service;
import java.util.ArrayList;
import java.util.List;

@Service
public class UserService {
    private List<Observer> observers = new ArrayList<>();

    // 方法用於註冊觀察者
    public void registerObserver(Observer observer) {
        observers.add(observer);
    }

    // 方法用於通知所有註冊的觀察者事件
    public void notifyObservers(String event) {
        for (Observer observer : observers) {
            observer.update(event);
        }
    }

    // 方法用於註冊新用戶並通知觀察者
    public void registerUser(String username) {
        System.out.println("User registered: " + username);
        notifyObservers("User Registration");
    }
}

• 觀察者列表：保存所有註冊的觀察者。

• registerObserver() 方法：將新的觀察者添加到列表中。

• notifyObservers() 方法：當事件發生時通知所有註冊的觀察者。

• registerUser() 方法：註冊新用戶並觸發通知給所有觀察者。

步驟 4： 在控制器中使用觀察者模式

最後，我們將創建一個Spring Boot控制器來公開用戶註冊的端點。 這個控制器將使用EmailObserver和SMSObserver來註冊UserService。

import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.*;

@RestController
@RequestMapping("/api")
public class UserController {
    private final UserService userService;

    public UserController() {
        this.userService = new UserService();
        // 註冊觀察者
        userService.registerObserver(new EmailObserver());
        userService.registerObserver(new SMSObserver());
    }

    @PostMapping("/register")
    public ResponseEntity<String> registerUser(@RequestParam String username) {
        userService.registerUser(username);
        return ResponseEntity.ok("User registered and notifications sent!");
    }
}

• 端點（/register）：接受一個username參數並註冊用戶，觸發通知給所有觀察者。

• 觀察者：EmailObserver和SMSObserver都註冊到UserService，所以當用戶註冊時它們將收到通知。

測試觀察者模式

現在，讓我們使用Postman或瀏覽器來測試我們的實現：

POST http://localhost:8080/api/register?username=JohnDoe

預期在控制台中輸出：

User registered: JohnDoe
Email sent for event: User Registration
SMS sent for event: User Registration

系統註冊用戶並通知Email和SMS觀察者，展示觀察者模式的靈活性。

觀察者模式的實際應用

1. 通知系統：在某些事件發生時通過不同渠道（電子郵件、短信、推送通知）向用戶發送更新。

2. 事件驅動架構：在特定操作發生時，例如用戶活動或系統警報，通知多個子系統。

3. 數據流：即時向各種消費者廣播數據變化（例如，即時股票價格或社交媒體資訊）。

如何使用Spring Boot的依賴注入

到目前為止，我們一直在手動創建對象來演示設計模式。然而，在真實世界的Spring Boot應用程序中，依賴注入（DI）是管理對象創建的首選方式。DI允許Spring自動處理類的實例化和連接，使您的代碼更具模塊化、可測試性和可維護性。

讓我們重構我們的策略模式示例，以充分利用Spring Boot強大的DI功能。這將使我們能夠動態切換支付策略，使用Spring的註解來管理依賴關係。

使用Spring Boot的DI更新的策略模式

在我們重構的示例中，我們將利用Spring的註釋，如@Component、@Service和@Autowired，來簡化注入依賴項的過程。

步驟1：使用@Component為支付策略進行註釋

首先，我們將使用@Component註釋來標記我們的策略實現，這樣Spring就可以自動檢測和管理它們。

@Component("creditCardPayment")
public class CreditCardPayment implements PaymentStrategy {
    @Override
    public void pay(double amount) {
        System.out.println("Paid $" + amount + " with Credit Card");
    }
}

@Component("payPalPayment")
public class PayPalPayment implements PaymentStrategy {
    @Override
    public void pay(double amount) {
        System.out.println("Paid $" + amount + " using PayPal");
    }
}

• @Component註釋：通過添加@Component，我們告訴Spring將這些類別視為Spring管理的bean。字符串值（"creditCardPayment"和"payPalPayment"）充當bean識別符。

• 靈活性：此設置允許我們通過使用適當的bean識別符在不同策略之間切換。

步驟2：重構PaymentService以使用依賴注入

接下來，讓我們修改PaymentService以使用@Autowired和@Qualifier來注入特定的支付策略。

@Service
public class PaymentService {
    private final PaymentStrategy paymentStrategy;

    @Autowired
    public PaymentService(@Qualifier("payPalPayment") PaymentStrategy paymentStrategy) {
        this.paymentStrategy = paymentStrategy;
    }

    public void processPayment(double amount) {
        paymentStrategy.pay(amount);
    }
}

• @Service註釋：將PaymentService標記為Spring管理的服務bean。

• @Autowired：Spring 自動注入所需的依賴項。

• @Qualifier：指定要注入的 PaymentStrategy 實現。在此示例中，我們使用的是 "payPalPayment"。

• 配置便利性：通過簡單更改 @Qualifier 的值，您可以在不改變任何業務邏輯的情況下切換支付策略。

步驟 3：在控制器中使用重構後的服務

為了看到此重構的好處，讓我們更新控制器以使用我們的 PaymentService：

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.*;

@RestController
@RequestMapping("/api")
public class PaymentController {
    private final PaymentService paymentService;

    @Autowired
    public PaymentController(PaymentService paymentService) {
        this.paymentService = paymentService;
    }

    @GetMapping("/pay")
    public String makePayment(@RequestParam double amount) {
        paymentService.processPayment(amount);
        return "Payment processed using the current strategy!";
    }
}

• @Autowired：控制器自動接收注入的支付策略的 PaymentService。

• GET 端點（/pay）：當訪問時，使用當前配置的策略（此示例中為 PayPal）處理付款。

使用 DI 重新設計的策略模式進行測試

現在，讓我們使用 Postman 或瀏覽器來測試新的實現：

GET http://localhost:8080/api/pay?amount=100

期望輸出:

Paid $100.0 using PayPal

如果您將 PaymentService 中的限定詞更改為 "creditCardPayment"，則輸出將相應更改：

Paid $100.0 with Credit Card

使用依賴注入的好處

• 鬆散耦合: 服務和控制器無需知道付款是如何處理的細節。它們只需依賴 Spring 注入正確的實現。

• 模組化: 您可以通過創建新的帶有 @Component 註釋的類 (例如，BankTransferPayment、CryptoPayment)，並調整 @Qualifier ，來輕鬆添加新的付款方法。

• 可配置性: 通過利用 Spring Profiles，您可以基於環境 (例如，開發與生產) 切換策略。

範例: 您可以使用 @Profile 根據啟用的配置檔自動注入不同的策略：

@Component
@Profile("dev")
public class DevPaymentStrategy implements PaymentStrategy { /* ... */ }

@Component
@Profile("prod")
public class ProdPaymentStrategy implements PaymentStrategy { /* ... */ }

重點

• 通過使用 Spring Boot 的 DI，您可以簡化對象創建並改善代碼的靈活性。

• 結合 DI 的策略模式使您能夠輕鬆在不更改核心業務邏輯的情況下切換不同策略。

• 使用 @Qualifier 和 Spring Profiles 讓您能夠根據不同環境或需求配置應用程式的靈活性。

這種方法不僅使您的代碼更清潔，還為將來進行更高級的配置和擴展做好準備。在下一節中，我們將探討將您的 Spring Boot 應用程式提升到更高水平的最佳實踐和優化提示。

最佳實踐和優化提示

一般最佳实践

• 不要过度使用设计模式：只在必要时使用。过度设计会使您的代码更难维护。

• 优先使用组合而非继承：策略模式和观察者模式是这一原则的很好示例。

• 保持设计模式的灵活性：利用接口使您的代码解耦。

性能考虑

• 单例模式：使用synchronized或Bill Pugh单例设计来确保线程安全。

• 工厂模式：如果创建对象的成本较高，可对其进行缓存。

• 观察者模式：如果有许多观察者，请使用异步处理以防止阻塞。

高级主题

• 使用反射结合工厂模式进行动态类加载。

• 利用Spring配置文件根据环境切换策略。

• 为您的API端点添加Swagger文档。

结论和关键要点

在本教程中，我们探讨了一些最强大的设计模式—单例模式、工厂模式、策略模式和观察者模式—并演示了如何在Spring Boot中实现它们。让我们简要总结每个模式并强调其最适合的用途：

单例模式:

• 摘要: 确保类只有一个实例，并提供一个全局访问点。

• 最适用于: 管理共享资源，如配置设置、数据库连接或日志服务。当您希望在整个应用程序中控制对共享实例的访问时，它是理想选择。

工廠模式:

• 摘要: 提供了一種在不需要指定要實例化的確切類別的情況下創建物件的方法。這種模式將物件的創建與業務邏輯解耦。

• 最適用於: 需要根據輸入條件創建不同類型物件的情況，例如通過電子郵件、簡訊或推送通知發送通知。這有助於使代碼更具模塊化和可擴展性。

策略模式:

• 摘要: 允許您定義一組算法家族，封裝每個算法並使它們可以互換。這種模式可以幫助您在運行時選擇算法。

• 最適用於: 當您需要動態地在不同行為或算法之間切換時，例如在電子商務應用程序中處理各種付款方式。這可以使您的代碼保持靈活性並符合開放/封閉原則。

觀察者模式:

• 摘要: 定義對象之間的一對多依賴關係，因此當一個對象變化時，所有依賴它的對象都會自動收到通知。

• 最適用於: 像通知服務、聊天應用中的即時更新或需要對數據變化做出反應的事件驅動系統。它非常適合解耦組件並使系統更具可擴展性。

接下來做什麼?

現在您已經學會了這些基本設計模式，請嘗試將它們整合到您現有的項目中，看看它們如何改善您的代碼結構和可擴展性。以下是進一步探索的一些建議:

• 實驗: 嘗試實現其他設計模式，如裝飾者、代理和建造者，來擴展您的工具包。

• 練習：使用這些模式重構現有項目，提高其可維護性。

• 分享：如果您有任何問題或想分享您的經驗，請隨時聯繫！

希望這個指南幫助您了解如何在Java中有效使用設計模式。繼續實驗，開心編碼！