如果你一路追這個系列，從第一集的 interface 是什麼、元件之間怎麼透過 interface 溝通、多型的威力，到後面聊的 單元測試、依賴注入，再到上一集的 介面隔離原則 (ISP)，你對 interface 這東西應該已經很有感覺了．
這一集，我想帶你回到第一集那個寄信的程式，那個例子當初只用來說明什麼是 interface，但其實它還藏著更多東西可以挖．這次我們要用它來聊一個很實用的設計模式：Strategy Pattern．它的核心精神，用一句話講就是：把怎麼做 從 做什麼 分離出來．
在這部落格裡，我沒打算寫太多有關物件導向 design pattern 的文章，而許多 design pattern 的做法其實在 interface 有很大的關係．雖然現在很流行用 AI coding tool 來寫程式，但不見得都能做出很好的設計，畢竟許多需求我們不知道該怎麼寫，在沒有好的資料輸入情況下，語言模型也不見得會給你較佳的設計，所以自己還是要多懂一點比較可靠．
第一集的故事是這樣的：你負責寫一個寄信程式，公司各部門都會把信件內容丟給你寄出去．但 A 部門有 A 部門的 email class，B 部門有 B 部門的 email class，如果你為每一個部門都寫一個 SendEmail()，程式碼就會蠢到不行．
當時的解法是：定義一個 IMailContent 的 interface，讓每個部門的 email class 都去實作它．這樣一來，不管是哪個部門的信件內容，都穿上了 IMailContent 這件外衣，你的寄信程式只要認得這件外衣就好，一個 SendEmail() 通吃所有部門．
我當時是這樣描述的：Interface 提供了 object 一種外衣，不同的 email content object 只要有相同的外衣 (IMailContent)，都可以在 SendEmail() 裡面使用．一個 object 可以有多個外衣，因此使得物件導向程式設計變得很彈性也很有趣．
第一集那件外衣是穿在 "資料" 上的 —— 也就是信件的內容．今天這一集，我們要把同樣的概念穿到一個完全不同的東西上面 - 寄信這個動作本身．這就是我說的更深一層的應用．
隨著時間過去與業務成長，需求也變複雜了．現在寄一封信這件事，有好幾種不同的做法：
- 有些信走公司自己架的 SMTP server (省錢，但量大時容易塞車)
- 行銷部門的大量電子報改用 SendGrid 這類第三方服務 (送達率高、有統計報表)
- 跑在 AWS 上的系統則直接用 AWS SES (跟雲端環境整合得好、便宜)
同樣是寄信，但底層怎麼寄，已經有三種完全不同的方式了．那你會怎麼寫？很多人第一直覺會用以下的程式碼來做，用一個參數告訴程式要走哪一種，然後用 if/else 去判斷．
public class EmailService
{
public void Send(EmailMessage message, string provider)
{
if (provider == "SMTP")
{
// 連到公司自架的 SMTP server
var server = new SmtpServer("mail.mycompany.com");
server.Connect();
server.SendMail(message.To, message.Subject, message.Body);
server.Disconnect();
}
else if (provider == "SendGrid")
{
// 呼叫 SendGrid 的 API
var client = new SendGridClient("API_KEY_HERE");
client.Post("/mail/send", message.To, message.Subject, message.Body);
}
else if (provider == "AWS_SES")
{
// 用 AWS SES 的 SDK
var ses = new AmazonSimpleEmailServiceClient();
ses.SendEmail(message.To, message.Subject, message.Body);
}
else
{
throw new ArgumentException("不支援的寄信方式");
}
}
}
這程式能跑，乍看之下也沒什麼大問題．但這種寫法會慢慢變成一場惡夢．
我們來想一下接下來會發生什麼事．
過了一段時間後，公司又要接一個新的寄信服務，比如說 Mailgun．你怎麼辦? 你只能把 Send() 這個 method 再打開，塞進一段新的 else if．再過半年又來一個，你又得打開它，再塞一段．這個 method 就像吹氣球一樣，越長越大，最後變成一坨幾百行、沒人敢碰的怪物．
這裡有幾個很實際的問題：
問題一：每次新增都要動到舊的程式碼．你只是想加一個新的寄信方式，卻被迫去改一個已經在正常運作的 method．每改一次，就有機會手滑改壞旁邊那些原本好好的邏輯．本來只想加東西，結果把別人的功能弄爆了，這種事在工程界天天上演．軟體設計裡有個很有名的原則叫做開放封閉原則 (Open-Closed Principle)，講的就是 "對擴充開放，對修改封閉"，理想的狀況是，要加新功能時用加新檔案的方式，而不是去改舊檔案．這個 if/else 的寫法剛好完全違反了這件事．
問題二：所有寄信方式全部攪在一起．SMTP 的連線邏輯、SendGrid 的 API 呼叫、AWS SES 的 SDK 操作，三套八竿子打不著的程式碼，硬是被塞在同一個 method 裡面．它們各自有各自的細節、各自的相依套件，現在全部纏在一起，光是讀都讀得很累．
問題三：根本沒辦法好好測試．還記得我們在前面的文章聊過 interface 跟單元測試的關係嗎？現在這個 Send() 你要怎麼測？你想測 SendGrid 那段邏輯有沒有正確組出參數，結果你一呼叫 Send()，它就真的去連 SMTP server 或真的去打 AWS 的 API 了．測試環境哪來這些東西? 這個 method 把決定用哪種方式 跟 實際去寄 死死綁在一起，導致它幾乎無法測試．
講到這裡，解法其實已經呼之欲出了．既然這些寄信方式做的是同一件事 (寄信)，只是做法不同，那我們是不是可以幫它們設計一件共同的外衣? 此時又回答了 interface 的本質了．沒錯，這就是 interface 出場的時候了．我們先問自己一個問題：不管是 SMTP、SendGrid 還是 AWS SES，它們共同的行為是什麼?
答案很簡單：把一封信寄出去．就這樣．於是我們可以定義這樣一件外衣:
public interface IEmailSender
{
void Send(EmailMessage message);
}
這件外衣只描述了一件事: 我會寄信，你給我一個 EmailMessage，我就把它送出去．至於是怎麼送的？外衣不管，那是各家自己的事．
接著，讓三種寄信方式各自去實作這件外衣，一種一個 class 如下所示
public class SmtpEmailSender : IEmailSender
{
public void Send(EmailMessage message)
{
var server = new SmtpServer("mail.mycompany.com");
server.Connect();
server.SendMail(message.To, message.Subject, message.Body);
server.Disconnect();
}
}
public class SendGridEmailSender : IEmailSender
{
public void Send(EmailMessage message)
{
var client = new SendGridClient("API_KEY_HERE");
client.Post("/mail/send", message.To, message.Subject, message.Body);
}
}
public class AwsSesEmailSender : IEmailSender
{
public void Send(EmailMessage message)
{
var ses = new AmazonSimpleEmailServiceClient();
ses.SendEmail(message.To, message.Subject, message.Body);
}
}
看到差別了嗎？原本那一大坨 if/else，現在被拆成了三個各自獨立、乾乾淨淨的 class．每個 class 只專心做好自己那一種寄信方式，互不干擾．SMTP 的歸 SMTP，SendGrid 的歸 SendGrid，誰也不認識誰．
這裡的每一個 class，就是一個策略 (strategy)．SmtpEmailSender 是一個策略，SendGridEmailSender 是另一個策略，AwsSesEmailSender 又是一個策略．它們穿著同一件外衣 (IEmailSender)，但裡面各做各的．
外衣定義好了，策略也都實作好了，那真正使用它的主程式會變成如下:
public class EmailService
{
private readonly IEmailSender _sender;
public EmailService(IEmailSender sender)
{
_sender = sender;
}
public void SendWelcomeEmail(string userEmail)
{
var message = new EmailMessage
{
To = userEmail,
Subject = "歡迎加入！",
Body = "感謝你的註冊，很高興認識你..."
};
_sender.Send(message); // 注意：EmailService 根本不知道背後是 SMTP 還是 SendGrid
}
}
請你仔細盯著那行 _sender.Send(message) 看．EmailService 在做的事情，是準備好一封歡迎信，然後寄出去．它從頭到尾完全不知道這封信是透過 SMTP 寄的，還是 SendGrid 寄的，還是 AWS SES 寄的．它只認得 IEmailSender 這件外衣，知道這東西會寄信，這樣就夠了．
這就是把怎麼做從做什麼分離的真正意思：
- EmailService 負責的是做什麼 -> 寄一封歡迎信
- 各個 Sender 負責的是怎麼做 -> 用什麼管道、什麼技術去寄
這兩件事，被 IEmailSender 這件外衣俐落地切開了．
現在最爽的地方來了．如果哪天要換寄信方式，程式怎麼改？
// 開發環境，用公司的 SMTP 就好 var emailService = new EmailService(new SmtpEmailSender()); // 要改用 SendGrid？換一件外衣就好，EmailService 一個字都不用動 var emailService = new EmailService(new SendGridEmailSender()); // 改用 AWS SES？也是一樣 var emailService = new EmailService(new AwsSesEmailSender());
就這樣．你想用哪一種，就在建立 EmailService 的時候，丟一件對應的外衣給它穿上去．EmailService 本身的程式碼完全不需要改動．
而且，如果哪天又要接 Mailgun 呢？還記得前面 if/else 版本要把 method 打開來改嗎？現在你完全不用碰任何舊程式碼，只要新增一個 MailgunEmailSender class，讓它實作 IEmailSender 就好．舊的東西一個都不用動，這就是前面提到的 "對擴充開放，對修改封閉"．
有沒有覺得這個換外衣的感覺，跟第一集很像? 第一集是各部門的信件內容穿上同一件外衣，讓寄信程式通吃．這一集是各種寄信方式穿上同一件外衣，讓主程式自由替換．同一個概念，一個套在資料上，一個套在行為上．這就是 interface 的威力，它不只能描述資料長什麼樣，更能描述一個東西會做什麼動作．
如果你有看第六集講依賴注入 (DI) 的那篇，看到上面那個建構式應該會會心一笑．沒錯，Strategy Pattern 跟 DI 根本是絕配．
EmailService 透過 constructor 接收一個 IEmailSender，這完全就是建構式注入 (Constructor Injection) 的標準做法．實務上你根本不會手動去 new 那些 sender，而是交給 DI 容器處理．例如在 ASP.NET Core 裡，你可以這樣設定:
// 整個專案要用哪種寄信策略，集中在這裡決定 builder.Services.AddScoped<IEmailSender, SendGridEmailSender>();
之後所有需要寄信的地方，只要在建構式裡寫上 IEmailSender，DI 容器就會自動把 SendGridEmailSender 注入進去．哪天要換策略? 改這一行就好，整個專案其他地方完全不用動．策略的 "選擇" 被收斂到了一個地方，乾淨又好管理．
看到這裡，比較敏銳的你可能會皺眉頭：「等等，你只是把那串 if/else 搬到別的地方去了吧? 總得有人決定要用哪個策略吧！」 問得好，這是個很重要的問題．答案是：對，那個判斷還在，但它被移到了一個正確的地方，而且只剩一個．
差別在哪？原本的 if/else 散落在核心的寄信邏輯裡面，每次寄信都要跑一次判斷，而且判斷跟實作攪在一起．現在如果你真的需要在 runtime 根據 configuration 來決定用哪個策略，你可以把這個判斷集中在一個地方，通常是程式啟動時的設定處或是一個專門的 factory，如下所示:
public IEmailSender CreateSender(string provider)
{
return provider switch
{
"SMTP" => new SmtpEmailSender(),
"SendGrid" => new SendGridEmailSender(),
"AWS_SES" => new AwsSesEmailSender(),
_ => throw new ArgumentException("不支援的寄信方式")
};
}
關鍵的差異是：這個判斷現在只出現在一個地方，而且它只負責挑策略，挑完就退場了．真正在做事的 EmailService 依然乾乾淨淨，完全不受影響．"選擇策略" 跟 "執行策略" 這兩件事被分開了，這才是重點．這跟原本那種每個 method 裡都重複一份判斷、判斷跟實作糾纏不清的狀況是天差地遠的兩回事．
學了一個新工具，最怕的就是看什麼都想用它．所以這裡也誠實講一下，什麼時候適合、什麼時候不適合．當你發現自己符合下面這些情況時，Strategy pattern 通常會幫上忙:
- 同一件事有好幾種不同的做法，而且未來可能還會增加 (像寄信、付款方式、檔案壓縮格式、運費計算規則)
- 你的程式裡開始出現越來越長的 if/else 或 switch，每個分支都是同一類事情的不同做法
- 你希望這些做法可以隨時抽換，或是想針對每一種做法分別寫單元測試
這跟我在之前的文章談 ISP 時的提醒一樣，設計模式都是拿來解決問題的，不是拿來炫技的．先確定你真的有那個問題，再用對應的工具去解．為了用而用，往往比不用還糟．
Hope it helps!
