在軟體工程領域，有一句經典名言：「任何傻瓜都能寫出電腦能理解的代碼，唯有優秀的工程師能寫出人類容易理解的代碼。」

在維護既有專案時，最常見且最讓人頭痛的程式碼壞味道（Code Smell），莫過於為了不斷追加新需求而堆疊出來的**「龐大 if-else 判斷式」或「數十行的 switch-case 地獄」**。這種代碼不僅難以閱讀、單元測試難寫，每次修改新商業邏輯時更極容易改 A 壞 B，嚴重違反物件導向設計原則中的「開放封閉原則（OCP, Open-Closed Principle）」。

今天我們就來示範：如何讓 ChatGPT 扮演資深重構架構師，帶領我們分析壞味道，並運用策略模式（Strategy Pattern）與 Java Enum 將混亂的條件邏輯重構成優雅、好擴展的架構！

一、代碼重構專用提示詞模板（Refactoring Prompting）

當你手上有一段又臭又長、想要動手術的條件邏輯時，請使用以下這套結構化提示詞要求 AI 重構：

【代碼重構提示詞範本】
請扮演資深 Java 架構重構專家。以下是一段處理商業邏輯的代碼，存在過多條件判斷與 Code Smell：

[貼上既有的 If-Else 或 Switch-Case 代碼]

請依序進行重構引導：

1. 壞味道診斷（Smell Analysis）：指出這段代碼違反了哪些軟體工程原則（如 OCP、單一職責 SRP），以及後續維護的潛在風險。
2. 重構策略推薦：從「衛語句（Guard Clauses）」、「策略模式（Strategy Pattern）」或「Enum 多型模式」中挑選最適合的解法，並說明選擇理由。
3. 重構後 Java 代碼：提供使用 Java 17+ 規範的乾淨實作，確保符合高內聚、低耦合。
4. 擴展性驗證：展示未來若追加一個「全新商業規則」時，代碼該如何擴展而不需要修改既有邏輯。

二、實戰案例：電商金流扣款的 If-Else 災難

假設我們有一個支付結算模組，支援信用卡、LinePay、街口支付與銀行轉帳：

[重構前：典型的條件判斷地獄]

public class PaymentService {
    public void processPayment(String paymentType, double amount) {
        if ("CREDIT_CARD".equalsIgnoreCase(paymentType)) {
            System.out.println("呼叫信用卡刷卡閘道，金額: " + amount);
            // 處理信用卡特有手續費與驗證...
        } else if ("LINE_PAY".equalsIgnoreCase(paymentType)) {
            System.out.println("產生 LinePay QR Code，金額: " + amount);
            // 處理 LinePay OAuth 與點數折抵...
        } else if ("JKO_PAY".equalsIgnoreCase(paymentType)) {
            System.out.println("呼叫街口支付 API，金額: " + amount);
            // 處理街口支付驗證...
        } else if ("BANK_TRANSFER".equalsIgnoreCase(paymentType)) {
            System.out.println("產生銀行虛擬帳號，金額: " + amount);
            // 處理轉帳期限與對帳邏輯...
        } else {
            throw new IllegalArgumentException("不支援的支付方式: " + paymentType);
        }
    }
}

三、AI 的診斷與策略模式重構

AI 分析指出：

• 違背 OCP：每新增一種支付方式（例如 Apple Pay），就必須打開此類別修改原始代碼，隨時可能改出 Bug。
• 責任過度集中：所有的支付參數驗證與特定邏輯全部塞在同一個類別，單元測試極難 Mock。

優化方案：策略模式（Strategy Pattern）結合 Spring/Java Map

AI 建議將每種支付邏輯封裝成獨立的策略介面與類別：

[1. 定義支付策略介面]

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

[2. 各自獨立的策略實作類別]

public class CreditCardPayment implements PaymentStrategy {
    @Override
    public String getPaymentType() {
        return "CREDIT_CARD";
    }

    @Override
    public void pay(double amount) {
        System.out.println("【信用卡】呼叫刷卡閘道，金額: " + amount);
    }
}

public class LinePayPayment implements PaymentStrategy {
    @Override
    public String getPaymentType() {
        return "LINE_PAY";
    }

    @Override
    public void pay(double amount) {
        System.out.println("【LinePay】產生專屬扣款 QR Code，金額: " + amount);
    }
}

[3. 策略工廠（消除 If-Else 核心）]

import java.util.HashMap;
import java.util.List;
import java.util.Map;

public class PaymentContext {

    private final Map<String, PaymentStrategy> strategyMap = new HashMap<>();

    // 在初始化時（或利用 Spring 自動注入 List<PaymentStrategy>）註冊所有策略
    public PaymentContext(List<PaymentStrategy> strategies) {
        for (PaymentStrategy strategy : strategies) {
            strategyMap.put(strategy.getPaymentType().toUpperCase(), strategy);
        }
    }

    public void executePayment(String paymentType, double amount) {
        PaymentStrategy strategy = strategyMap.get(paymentType.toUpperCase());
        if (strategy == null) {
            throw new IllegalArgumentException("不支援的支付方式: " + paymentType);
        }
        strategy.pay(amount);
    }
}

四、重構後的工程效益

透過 AI 協同重構完成後，系統體質得到了顯著提升：

1. 完全符合開放封閉原則（OCP）：
   未來若要接入「Apple Pay」，工程師只需新增一個 ApplePayPayment 類別實作介面即可，完全不需要修改任何舊有的 Java 類別，直接從根源杜絕了回歸錯誤（Regression Bug）。
2. 單元測試極其簡單：
   每種支付方式現在都是獨立的類別，測試時可以直接單獨針對 CreditCardPayment 撰寫測試案例，不需要模擬整個龐大的環境。
3. 查表取代遍歷：
   使用 HashMap 取代多重 if-else，尋找支付策略的時間複雜度從 O(n) 降到 O(1)。

今日小結與預告

今天我們示範了如何透過 AI 將充滿壞味道的「巢狀條件判斷式」，重構成清晰易維護的「策略模式」，真正體會到了 Clean Code 與物件導向架構的優雅之處。