前回の投稿では、Laravel で支払い処理を処理するための 2 つの異なる方法を検討しました:

• ハードコードされたサービス バインディング
• コンテキストバインディング。

どちらの方法も効果的ではありますが、実行時の条件 (ユーザー入力、構成設定など) に基づいて支払い処理業者を動的に選択する場合には制限があります。

最後の 3 番目のパートでは、より柔軟なアプローチ、つまりファクトリー パターンの使用について見ていきます。この設計パターンにより、コンテキストに基づいて PaymentProcessorInterface の適切な実装を選択できます (リクエストに応じて Stripe か PayPal のどちらかを選択するなど)。

ファクトリ パターンの実装

ファクトリ パターンは、実行時にさまざまな実装を動的に解決するスケーラブルなソリューションを提供します。設定方法を段階的に説明します。

ステップ 1: ファクトリ インターフェイスを作成する

まず、さまざまな支払いプロセッサを解決する方法の概要を説明する PaymentProcessorFactoryInterface を定義しましょう。

このインターフェイスにより、作成するファクトリには getProcessor メソッドが確実に含まれ、指定された引数 (例: 'ストライプ' または 'ペイパル') に基づいて適切な支払いプロセッサを返す役割を果たします。


  
  
  ステップ 2: ファクトリ実装を作成する


次に、プロバイダーの入力に基づいて適切な支払いプロセッサを解決するファクトリを実装します。


このファクトリは、実行時に提供された入力に基づいて正しい支払いプロセッサを動的に選択します。この例では、StripePaymentProcessor と PayPalPaymentProcessor の新しいインスタンスを直接返します。必要に応じて、これらのクラスを Laravel のサービス コンテナから解決して管理を改善することもできます。


  
  
  ステップ 3: Stripe および PayPal プロセッサを実装する


PaymentProcessorInterface を実装する StripePaymentProcessor クラスと PayPalPaymentProcessor クラスの両方があることを確認してください。

例: StripePaymentProcessor


例: PayPalPaymentProcessor

同様に、StripePaymentProcessor と同じパターンに従って PayPalPaymentProcessor クラスを実装します。


  
  
  ステップ 4: サービス コンテナでファクトリをバインドする


Laravelアプリケーション全体でファクトリーを確実に利用できるようにするには、PaymentProcessorFactoryをLaravelのサービスコンテナにバインドする必要があります。これは AppServiceProvider.
 で行うことができます。

App\Providers\AppServiceProvider.php の register メソッド内に以下を追加します:


public function register()
{
    $this->app->singleton(\App\Contracts\PaymentProcessorFactoryInterface::class, \App\Services\PaymentProcessorFactory::class);
}




このバインディングは、PaymentProcessorFactoryInterface が要求されるたびに PaymentProcessorFactory を使用するように Laravel に指示し、アプリケーション全体でファクトリのインスタンスが 1 つだけ存在するようにします。


  
  
  ステップ 5: コントローラーでのファクトリーの使用


これでファクトリがセットアップされたので、それをコントローラーに挿入して、リクエスト入力などの実行時データに基づいて適切な支払いプロセッサを動的に選択できます。

例: PaymentController


paymentProcessorFactory = $paymentProcessorFactory;
    }

    public function makePayment(Request $request)
    {
        $provider = $request->input('provider'); // E.g., 'stripe' or 'paypal'
        $amount = $request->input('amount');
        $currency = $request->input('currency');
        $paymentDetails = $request->input('details');

        // Get the appropriate payment processor based on the provider
        $paymentProcessor = $this->paymentProcessorFactory->getProcessor($provider);

        // Use the selected payment processor to create a payment
        $response = $paymentProcessor->createPayment($amount, $currency, $paymentDetails);

        return response()->json($response);
    }
}




このコントローラーでは、依存関係注入を通じて PaymentProcessorFactoryInterface を注入します。支払いがリクエストされると、リクエストから支払いプロバイダー (Stripe や PayPal など) を特定し、それを工場に渡し、適切な支払いプロセッサを動的に解決します。


  
  
  ステップ 6: さまざまな決済プロバイダーの処理


この設定では、コントローラーはリクエスト内のプロバイダー名を切り替えるだけで、さまざまな支払いプロバイダーを動的に処理できるようになりました。この方法は、ロジックを複製したり、コードを特定の実装に緊密に結合したりせずに、複数の支払いゲートウェイを処理する必要がある場合に特に強力です。


  
  
  結論


Laravel 11 で Factory Pattern を使用すると、実行時にさまざまな支払いプロセッサを選択するための非常に柔軟なアプローチが提供されます。ここで説明した手順の概要は次のとおりです:

• ファクトリ インターフェイスと実装: 文字列入力に基づいて正しい支払いプロセッサを動的に解決するファクトリを作成しました。
• プロセッサ実装: StripePaymentProcessor クラスと PayPalPaymentProcessor クラスの両方が PaymentProcessorInterface を実装していることを確認しました。
• サービス コンテナのバインド: アプリケーション全体で簡単に注入できるように、サービス コンテナ内でファクトリをバインドします。 コントローラ内の動的選択: コントローラ内のファクトリを使用して、実行時データに基づいて適切な支払いプロセッサを動的に選択して使用します。

ソフトウェア設計原則と設計パターン

この 3 部構成のチュートリアルは、ハードコードされた選択を使用して単一の決済プロセッサを使用して開始し、次に Laravel サービス コンテナ バインディングを使用してコード内 (「コンパイル時」) 構成を使用し、その後、この部分では設計のリファクタリングを続けました。原則と設計パターンを念頭に置いて、コードをリファクタリングして、次のことを実現できました。

• 動的な柔軟性: ファクトリ パターンを使用すると、実行時にさまざまな支払いプロセッサを選択できるため、アプリケーションがより柔軟でスケーラブルになります。
• 疎結合: ファクトリを挿入することにより、コントローラーは決済プロセッサーに疎結合され、将来の決済ゲートウェイの追加または交換が容易になります。
• 保守性: このアプローチにより、特に複数の支払いオプションを扱う場合に、よりクリーンで保守しやすいコードベースが提供されます。

このセットアップにより、Laravel で支払いを処理するための強力で柔軟なシステムが完成しました。追加のプロセッサをサポートする必要がある場合は、プロバイダーを選択するためのロジックをサポートおよび変更して、さまざまなビジネス ロジック シナリオを処理できるようにファクトリを簡単に拡張できます。