策略設計模式
策略設計模式可讓您定義一系列演算法，封裝它們中的每一個並使它們可以互換。
客戶端程式碼（ 主班 ）將能夠選擇一種演算法（ 服務 ) 在執行時。
在本文中，我們將深入研究 Laravel PHP 策略設計模式，包括範例
設計模式策略
Il 設計模式策略 屬於以下類別 行為模式 並允許在運行時選擇演算法。這在您想要動態切換的情況下特別有用 算法 到另一種行為或從一種行為到另一種行為。
在這樣的背景下 Laravel/PHP，策略模式可讓您將特定演算法與客戶端解耦，從而使您可以輕鬆地在它們之間進行切換。這種方法遵循 開閉原則 （之一 孤獨原則D ），允許程式碼對擴充開放，但對修改關閉。
問題
在許多應用中 Laravel，存在需要根據運行時條件實現多種演算法或行為的場景。例如：
您有一個應用程序，用戶可以在其中註冊和使用您的服務。現在，顯然，您希望保護您的應用程式免受虛假帳戶的侵害。一種方法是阻止註冊：
- 虛假電子郵件
- 臨時或一次性電子郵件
- 無效電子郵件（ 看似有效但實際上不存在的電子郵件 ).
為此，我們可以建立一個驗證器來驗證一次性電子郵件，並透過外部提供者檢查電子郵件是否有效。
我們可以使用 kickbox.com 作為我們的服務，一切都很好。
如果我們還想實現另一個服務怎麼辦 零反彈網， 然後我們就可以繼續實施它。
稍後，假設我們還評估另一個支援需求 使用者檢查網站 ， 等等。
感謝策略模式，我們可以處理這些需求，而無需使用類似的語句 if-else or switch.
相反，如果我們使用更結構化的編程，因此大量使用 if-else 和開關，我們最終會得到 緊身的 程式碼，這將使我們在後期添加或更改演算法變得非常困難。程式碼變得複雜、難以測試並且違反了關鍵設計原則。
解
Il 策略模式 透過將演算法分離到實現公共介面的單獨類別中，為這個問題提供了一個優雅的解決方案。基本想法是：
- 定義一個將由所有演算法實現的介面。
- 落實每一個 算法 在它的具體類別中。
- 上下文類別使用這些演算法，並且可以在它們之間動態切換，而無需更改其內部邏輯。
這翻譯成 乾淨且可維護的程式碼 ，易於擴展和修改，無需改變現有邏輯。只需根據需要新增策略，無需更改客戶端程式碼。
在我們深入實現之前，讓我們先了解一下構成觀察者模型的關鍵元件。
- 語境 ：將其行為委託給所包含策略之一的物件。
- 策略介面 ：定義所有策略行為的介面。策略實現此介面以提供其獨特的行為實現。
- 具體策略 ：實作策略介面的類別。每個策略都封裝了上下文可以在運行時切換到的特定行為。
科迪斯
- 戰略介面 。首先，我們為不同的驗證策略建立一個通用介面。
<?php
介面 EmailValidationServiceInterface
{
公用函數 isRealEmail(string $email): bool;
}
2. 現在讓我們創建一些 具體策略 對於我們想要實現的每項服務：Kickbox、Zerobounce 和 Usercheck。
<?php
類別 KickboxService 實作 EmailValidationServiceInterface
{
公用函數 isRealEmail(string $email): bool
{
// KickboxService具體邏輯
返回true;
}
}
ZeroBounceService 類別實作 EmailValidationServiceInterface
{
公用函數 isRealEmail(string $email): bool
{
// ZeroBounceService特定邏輯
返回true;
}
}
類別 UsercheckService 實作 EmailValidationServiceInterface
{
公用函數 isRealEmail(string $email): bool
{
// UsercheckService具體邏輯
返回true;
}
}
3. 現在我們需要實現一個 上下文類別 。它負責選擇適當的驗證服務策略。
<?php
類別 EmailValidationContext
{
私有 EmailValidationServiceInterface $emailValidation;
公用函數 setEmailValidator(EmailValidationServiceInterface $emailValidation): EmailValidationServiceInterface
{
$this->emailValidation = $emailValidation;
}
公用函數驗證（字串$電子郵件）：布爾
{
返回 $this->emailValidation->isRealEmail($email);
}
}
採用
最後一部分是我們如何在應用程式中使用該策略。我們可以直接在控制器或自訂 Laravel 驗證器中實作電子郵件驗證策略。
<?php
RegisterController 類別擴充了 Controller
{
公共功能檢查（請求$請求）
{
$emailValidationContext = new EmailValidationContext();
// 為了便於論證，我們假設服務來自請求
// 或者更好的是在 `/config/services.php` 中配置
// 根據所選服務選擇策略
開關（$請求->服務）{
「kickbox」案例：
$emailValidationContext->setEmailValidator(new KickboxService());
打破;
案例“零反彈”：
$emailValidationContext->setEmailValidator(new ZeroBounceService());
打破;
案例“用戶檢查”：
$emailValidationContext->setEmailValidator(new UsercheckService());
打破;
默認情況下：
throw new \Exception("不支援驗證服務。");
}
// 使用服務驗證電子郵件
返回 $emailValidationContext->validate($request->email);
}
}
優點
1. 靈活性和可擴展性
策略模式可以輕鬆新增策略，而無需更改現有程式碼。例如，如果您需要新增新的驗證服務，您只需建立一個實現它的新類 EmailValidationServiceInterface 並將其註入上下文中。
2. 堅持SOLID原則
- 開閉原則 ：系統對擴充開放，但對修改關閉，允許在不更改現有程式碼的情況下擴展功能。
- 單一職責原則 ：每個類別都有一個職責，這樣更容易維護和測試。
3. 消除條件邏輯
該模型消除了對複雜指令的需要 if-else, switch 使程式碼更清晰、更具可讀性。
更多範例
您也可以將策略設計模式用於其他用例，例如在電子商務平台中使用不同支付網關處理訂單。例如，您可以擁有 PayPal、Stripe、BankTransfer 等，或使用不同的電子郵件傳送服務、Mailgun、SendingBlue、SMTP 等。
