ERP 公共代碼庫的過度封裝問題與治理策略

背景

在 ERP 系統開發中，將通用邏輯提取至共享類庫可減少重複、提高復用。但「過度封裝」反而會增加理解成本、降低維護效率。本文通過具體案例探討如何把握封裝度。

案例一：不必要的簡單封裝

public class ConfigHelper
{
    // 判斷路徑合法性，邏輯非簡單，封裝合理
    static public bool IsValidPath(string path)
    {
        Regex r = new Regex(@"^(([a-zA-Z]:)|(\\))(\{1}|((\{1})[^\]([^/:*?<>""|]*))+)$");
        return r.IsMatch(path);
    }

    // 僅一行調用框架方法，封裝屬過度
    public static string GetString(string key)
    {
        return System.Configuration.ConfigurationManager.AppSettings[key];
    }
}

GetString 僅轉調框架 API，無額外邏輯（如異常處理、默認值、緩存）。調用方直接用 ConfigurationManager.AppSettings[key] 更直觀，封裝反而引入間接層，增加認知負擔。

案例二：視場景而定的封裝

public static decimal GetDecimal(string key)
{
    decimal value = default(decimal);
    if (decimal.TryParse(GetString(key), out value))
        return value;
    else
        return 0m;
}

此方法將「讀取配置 → 嘗試轉換 → 失敗返回默認值」封裝為單一操作。若系統大量需要「帶默認值的數值配置讀取」，該封裝消除重複邏輯，屬合理；若僅偶爾使用，則屬過度設計。

判斷標準

1. 邏輯複雜度：封裝體是否包含非平凡的業務/技術邏輯（驗證、轉換、錯誤處理、緩存等）。
2. 復用頻率：同樣邏輯在多處出現的概率。
3. 語義表達：方法名是否比直接調用更清晰表達意圖（如 GetDecimalWithDefault vs TryParse）。
4. 擴展性：未來是否可能擴展（如增加日誌、遠程配置源）。

建議

• 對單行框架調用、無附加價值的傳遞方法，不封裝。
• 對重複出現的「模式化邏輯」（帶默認值讀取、類型轉換、驗證等），封裝為工具方法。
• 定期審查公共庫，清理僵尸/過度封裝代碼，保持庫的精簡與高信噪比。