Java 設計模式核心原則：單一職責原則 (SRP) 深度解析

單一職責原則 (SRP) 定義

單一職責原則：一個類應當只有一個引起它變更的原因。換句話說，一個類、介面或模組只負責一項職責。

為什麼需要 SRP？

如果一個類承擔多重職責（如同時處理業務屬性與業務邏輯），修改某一功能時極易引入 Bug 影響其他功能。遵循 SRP 可實現：

• 降低類的複雜度
• 提高可讀性與可維護性
• 減少修改風險，實現高內聚

常見違反場景：介面職責不清

開發中常見錯誤：將用戶屬性（身高、體重）與用戶行為（吃飯、上網）定義在同一介面 Itutu 中：

public interface Itutu {
    // 業務對象屬性
    void setShengao(double height);
    double getShengao();
    void setTizhong(double weight);
    double getTizhong();
    // 業務邏輯行為
    boolean chiFan(boolean hungry);
    boolean shangWang(boolean silly);
}

此介面職責模糊，既非純粹的數據對象 (BO)，也非純粹的邏輯處理 (BL)，違反 SRP。

重構方案：職責拆分

將介面拆分為兩個單一職責介面：

1. 業務對象介面

public interface ItutuBO {
    void setShengao(double height);
    double getShengao();
    void setTizhong(double weight);
    double getTizhong();
}

2. 業務邏輯介面

public interface ItutuBL {
    boolean chiFan(boolean hungry);
    boolean shangWang(boolean silly);
}

3. 具體實現類

public class TutuBO implements ItutuBO {
    private double height;
    private double weight;
    // 實現屬性 getter/setter...
}

public class TutuBL implements ItutuBL {
    @Override
    public boolean chiFan(boolean hungry) {
        if (hungry) { System.out.println("去吃火鍋..."); return true; }
        return false;
    }
    @Override
    public boolean shangWang(boolean silly) {
        if (silly) { System.out.println("好無聊啊，上會網..."); return true; }
        return false;
    }
}

修改屬性時只動 ItutuBO/TutuBO，修改邏輯時只動 ItutuBL/TutuBL，互不干擾。

實戰中的挑戰與權衡

• 「職責」劃分無絕對標準：過度拆分會導致類數量爆炸，反而增加複雜度。
• 介面必須嚴格遵循 SRP；實現類盡量遵循，但允許適度妥協（如實現多個介面）。
• 歷史包袱重構：已有類違反 SRP 時，應通過重構逐步拆分。

總結

SRP 是設計模式的基石。介面設計務必單一職責，實現類設計儘量單一職責。實際開發中憑經驗判斷變更原因，在「職責清晰」與「類數量可控」間尋找平衡點。