接下來我們要進到SOLID的實戰，這堂課我們將專注於最基礎、但也最重要的第一條原則：SRP (單一職責原則)，並探討它與 高內聚 (High Cohesion) 的緊密關係。

核心觀念定義

關於單一職責原則

"A class should have one, and only one, reason to change." — Robert C. Martin (Uncle Bob)

「一個類別應該只有一個『改變的理由』。」

很多人誤以為 SRP 意思是「一個類別只做一件事 (Do one thing)」，這其實不完全精確。更準確的說法是：一個類別應該只負責「一類」業務邏輯，並且只對「一種」角色負責。

• 如果會計部門要求修改薪資計算邏輯，你不應該動到負責「資料庫存取」的程式碼。

• 如果 DBA 要求更換資料庫欄位，你不應該動到負責「生成報表」的程式碼。

SRP 的核心不是「功能數量」，而是「變更來源是否單一」。

關於高內聚

內聚是指模組內的元素（屬性、方法）彼此之間的關聯程度。

• 高內聚： 類別內的程式碼都是為了完成同一個目的而緊密協作的。

• 低內聚： 類別像是一個大雜燴，裡面放了毫不相關的功能（例如：一個類別同時負責算數學、寄 Email 和連線資料庫）。

SRP 與高內聚的關係

遵守 SRP 的類別，自然會傾向於高內聚；因為你把不相關的東西拆出去了，剩下的都是高度相關的。

反面範例 - 上帝物件

讓我們看一個後端常見的「壞味道」範例。這是一個負責處理訂單的 Service，但它管得太寬了。

class OrderService
{
    public function placeOrder($orderData)
    {
        // 1. 驗證邏輯 (責任：資料正確性)
        if (empty($orderData['items'])) {
            throw new Exception("Order must have items.");
        }

        // 2. 計算邏輯 (責任：業務規則)
        $total = 0;
        foreach ($orderData['items'] as $item) {
            $total += $item['price'] * $item['qty'];
        }
        if ($total > 1000) { // 滿千送百邏輯
            $total -= 100;
        }

        // 3. 資料庫邏輯
        $db = new Database();
        $db->query("INSERT INTO orders ...");

        // 4. 通知邏輯 
        $mailer = new Mailer();
        $mailer->send($orderData['email'], "Order Placed!");

        // 5. 格式化邏輯
        return json_encode(['status' => 'success', 'total' => $total]);
    }
}

為什麼這樣不好？

這個 OrderService 有 5 個改變的理由：

1. 行銷部門想改「滿千送百」規則 ➡️ 要改這個 Class。

2. IT 部門想換資料庫 ORM ➡️ 要改這個 Class。

3. 營運部門想改 Email 標題 ➡️ 要改這個 Class。

4. 前端要求 API 格式改變 ➡️ 要改這個 Class。

5. 驗證規則變嚴格 ➡️ 要改這個 Class。

這導致了「低內聚」與「高耦合」。改 A 壞 B 的風險極高。

這種寫法在功能「第一次完成時」通常最快，但在需求開始變動後，維護成本會呈指數成長。

重構實戰：職責分離

我們將上述的「大雜燴」拆解成數個專職的類別。

步驟一：拆分職責 (Extract Class)

1. Validator: 負責檢查資料。

2. PriceCalculator: 負責商業邏輯（計算金額、折扣）。

3. OrderRepository: 負責與資料庫溝通。

4. NotificationService: 負責寄信。

此時的 OrderService 仍然「有一個職責」：協調訂單建立的流程。 SRP 並不要求「沒有邏輯」，而是要求「邏輯的角色單一」。

步驟二：重組 OrderService

現在的 OrderService 不再親自做所有事情，而是變成一個 指揮官。

namespace App\Services;

use App\Validators\OrderValidator;
use App\Calculators\PriceCalculator;
use App\Repositories\OrderRepository;
use App\Services\NotificationService;

class OrderService
{

    public function __construct(
        private readonly OrderValidator $validator,
        private readonly PriceCalculator $calculator,
        private readonly OrderRepository $repository,
        private readonly NotificationService $notifier
    ) {

    }

    public function placeOrder(array $orderData)
    {
        // 1. 驗證
        $this->validator->validate($orderData);

        // 2. 計算
        $order = $this->calculator->calculateTotal($orderData);

        // 3. 儲存
        $savedOrder = $this->repository->save($order);

        // 4. 通知
        $this->notifier->sendOrderConfirmation($savedOrder);

        return $savedOrder;
    }
}

常見誤區：SRP 不等於「碎屍萬段」

在學習 SRP 時，最容易犯的錯誤就是 「拆分過細」 (Over-engineering)。

• 錯誤觀念： 每個 Function 只能寫一行程式碼，或者每個 Class 只能有一個 Function。

• 正確觀念： 內聚性是關鍵。如果兩個功能總是「一起被使用」且「一起被修改」，它們就應該在一起。

判斷標準： 問自己：「這個類別是否負責了不同的角色 (Actors) 的需求？」 如果一個類別同時包含了「會計需要的邏輯」和「DBA 需要的邏輯」，那就是違反 SRP。