Laravel で支払い処理インターフェイスを追加および実装する方法 ハードコードされたバインディングのパート

このブログ投稿では、Laravel 11 アプリケーションに支払い処理インターフェイスを追加して実装する最初のステップを実行する方法を説明します。まず、PaymentProcessorInterface と、StripePaymentProcessor などの特定の実装の間にハードコーディングされたバインディングを作成します。このアプローチは基本的なセットアップであり、動的バインディングやファクトリーの使用などのより高度なテクニックの基礎を築きます。これについては今後の投稿で説明します。

ステップ 1: Contracts ディレクトリを作成する (存在しない場合)

Laravel は、クリーンで組織化されたコードベースを奨励します。インターフェイスを実装するときは、通常、AppContracts ディレクトリ内にインターフェイスを配置します。

Contracts ディレクトリがアプリケーションにまだ存在しない場合は、ターミナルで次のコマンドを実行して作成できます。

mkdir app/Contracts

このディレクトリは、すべてのアプリケーション インターフェイスの場所として機能し、具体的な実装から分離します。

ステップ 2: PaymentProcessor インターフェイスを Contracts ディレクトリに保存する

Contracts ディレクトリができたので、PaymentProcessorInterface が存在する新しいファイルを作成しましょう。これを行うには、次のコマンドを実行します:

touch app/Contracts/PaymentProcessorInterface.php

これにより、次のステップで設定する空のファイルが作成されます。

ステップ 3: PaymentProcessor インターフェイスを定義する

新しく作成した PaymentProcessorInterface.php ファイルで、次のようにインターフェースを定義します。

<?php namespace App\Contracts;

interface PaymentProcessorInterface
{
    public function createPayment(float $amount, string $currency, array $paymentDetails): array;
    public function processPayment(array $paymentData): array;
    public function refundPayment(string $transactionId, float $amount): bool;
}

このインターフェイスはコントラクトとして機能し、これを実装するクラスには支払いの作成、処理、返金に必要なメソッドが確実に含まれるようにします。

ステップ 4: サービス クラスでのインターフェイスの実装

PaymentProcessorInterface を定義したら、次のステップは、このインターフェイスを実装するクラスを作成することです。通常、この実装は app/Services ディレクトリに配置します。

たとえば、このインターフェースを実装する StripePaymentProcessor クラスを作成してみましょう。次を実行してファイルを作成できます:

touch app/Services/StripePaymentProcessor.php

次に、以下に示すようにクラスを実装します。

<?php namespace App\Services;

use App\Contracts\PaymentProcessorInterface;

class StripePaymentProcessor implements PaymentProcessorInterface
{
    public function createPayment(float $amount, string $currency, array $paymentDetails): array
    {
        // Stripe-specific payment creation logic
    }

    public function processPayment(array $paymentData): array
    {
        // Stripe-specific payment processing logic
    }

    public function refundPayment(string $transactionId, float $amount): bool
    {
        // Stripe-specific payment refund logic
    }
}

このクラスには、Stripe の API を介して支払いを作成、処理、返金するために必要なメソッドが含まれるようになりました。同じインターフェースを実装する追加クラスを作成することで、必要に応じてこれを他の決済プロセッサに置き換えたり拡張したりできます。

ステップ 5: サービス コンテナ内のインターフェイスのバインド (ハードコード)

インターフェースとその実装の準備ができたので、PaymentProcessorInterface を解決する方法を Laravel に伝える必要があります。この最初のステップでは、Laravel のサービス コンテナ内の特定の実装にインターフェイスを明示的にバインドすることにより、ハードコーディングされたバインディングを使用します。

これを行うには、AppServiceProvider を変更するか、新しいサービス プロバイダーを作成します。

app/Providers/AppServiceProvider.php の register メソッド内に次のコードを追加します。

public function register()
{
    $this->app->bind(
        \App\Contracts\PaymentProcessorInterface::class,
        \App\Services\StripePaymentProcessor::class
    );
}

このバインディングは、PaymentProcessorInterface が必要なときはいつでも、StripePaymentProcessor クラスを自動的に挿入する必要があることを Laravel に伝えます。このアプローチは機能しますが、特定の実装をインターフェイスにバインドするため、制限があります。

このハードコーディングされたバインディングは出発点としては優れていますが、大規模なアプリケーションや複数の支払いプロセッサをサポートする場合に必要な柔軟性は提供されません。このシリーズの次のパートでは、Laravel のサービス コンテナとファクトリーを使用して動的バインディングを実現し、システムが必要な支払いゲートウェイに基づいて実行時に異なる実装を選択できるようにする方法を検討します。

• 動的バインディング: 異なる支払処理業者に複数の実装を許可します。
• ファクトリー パターン: ファクトリを使用して、実行時の条件に基づいて正しい支払いプロセッサを選択します。

以上がLaravel で支払い処理インターフェイスを追加および実装する方法 ハードコードされたバインディングのパートの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。