🔥 程式的 If 地獄

📚 故事：新手程式員的困境

阿明是一位新手程式員，他要撰寫一個會員系統。起初只需判斷會員是否付費：

if (isPaidMember) {
    Console.WriteLine("歡迎進入會員專區");
} else {
    Console.WriteLine("請先付款");
}

if (isPaidMember) {
    Console.WriteLine("歡迎進入會員專區");
} else {
    Console.WriteLine("請先付款");
}

簡單直接。然而隨着需求增加，他需要判斷會員等級、優惠、地區限制、黑名單、生日優惠……

if (isPaidMember) {
    if (isVIP) {
        if (isBirthday) {
            Console.WriteLine("VIP 生日快樂，送你優惠券！");
        } else {
            Console.WriteLine("VIP 專屬優惠");
        }
    } else {
        if (isBlacklisted) {
            Console.WriteLine("帳號受限，請聯絡客服");
        } else {
            Console.WriteLine("普通會員功能");
        }
    }
} else {
    Console.WriteLine("請先付款");
}

if (isPaidMember) {
    if (isVIP) {
        if (isBirthday) {
            Console.WriteLine("VIP 生日快樂，送你優惠券！");
        } else {
            Console.WriteLine("VIP 專屬優惠");
        }
    } else {
        if (isBlacklisted) {
            Console.WriteLine("帳號受限，請聯絡客服");
        } else {
            Console.WriteLine("普通會員功能");
        }
    }
} else {
    Console.WriteLine("請先付款");
}

程式愈寫愈長，巢狀 if 一層包一層，猶如迷宮。阿明開始覺得自己陷入「If 地獄」。

⚠️ 為何稱為「If 地獄」？

可讀性差：巢狀過深，其他人難以理解邏輯。
維護困難：需求一旦改動，新增條件極易引發錯誤。
測試繁瑣：每個分支皆需測試，組合數量龐大。

🛠️ 如何走出 If 地獄？

1. 抽象邏輯至函數

將重複判斷抽出成獨立函數：

bool IsVIPBirthday(Member m) {
    return m.IsVIP && m.IsBirthday;
}

bool IsVIPBirthday(Member m) {
    return m.IsVIP && m.IsBirthday;
}

2. 策略模式 (Strategy Pattern)

利用設計模式，將不同邏輯封裝成策略類別：

interface IMemberStrategy {
    void ShowMessage();
}
class VIPBirthdayStrategy : IMemberStrategy {
    public void ShowMessage() => Console.WriteLine("VIP 生日快樂，送你優惠券！");
}

interface IMemberStrategy {
    void ShowMessage();
}
class VIPBirthdayStrategy : IMemberStrategy {
    public void ShowMessage() => Console.WriteLine("VIP 生日快樂，送你優惠券！");
}

3. 多型 (Polymorphism)

透過繼承與多型，將不同會員類型的行為分開，避免集中於一堆 if。

4. 早期返回 (Early Return)

避免巢狀，遇到不符合條件時立即返回：

if (!isPaidMember) {
    Console.WriteLine("請先付款");
    return;
}

if (!isPaidMember) {
    Console.WriteLine("請先付款");
    return;
}

🏠 生活比喻：餐廳點餐的混亂

想像你走進一家餐廳，服務員要判斷：

你是否會員？
是否 VIP？
是否生日？
是否黑名單？
是否有優惠券？

如果服務員逐一檢查，層層判斷，流程會變得冗長，顧客要等很久。這就是「If 地獄」的生活版。

相反，若餐廳設計好流程：

先檢查是否黑名單，若是立即拒絕。
再依會員等級分配不同服務。
最後再看是否生日或有優惠券。

這樣流程清晰，顧客體驗良好。程式設計亦然，避免巢狀判斷，邏輯更易維護。

📌 實際例子

電商系統：優惠券、會員等級、黑名單、地區限制，全部用 if 判斷會爆炸。
遊戲程式：角色狀態、技能冷卻、裝備效果，全部用 if，維護困難。

✅ 結論

「If 地獄」是程式設計常見陷阱。雖然 if 簡單易用，但當邏輯複雜時，巢狀判斷會令程式失控。要走出 If 地獄，程式員需學會抽象邏輯、使用設計模式、多型、早期返回等技巧。

程式設計不僅是「能跑就好」，更要「易讀、易維護」。避免 If 地獄，正是邁向專業程式設計的重要一步。

Contents