В нашей предыдущей статье (Как добавить и реализовать интерфейсы обработки платежей в Laravel 11: жестко закодированная привязка) мы рассмотрели первый шаг в настройке платежных процессоров путем жесткого кодирования привязки между PaymentProcessorInterface и конкретная реализация, например StripePaymentProcessor.

Хотя этот подход прост и эффективен для небольших приложений, ему не хватает гибкости для более сложных сценариев, где вам может потребоваться обработка нескольких платежных шлюзов, но использование интерфейса позволило нам отделить код, чтобы мы могли его дальше расширять, в соответствии с принципом открытия-закрытия, чтобы внедрить надлежащую функциональность:

• контекстная привязка во время компиляции с использованием механизма Laravel Service Container.
• использование фабричного шаблона, создающего экземпляры необходимых классов во время выполнения.

Во второй части мы углубимся в контекстную привязку, более продвинутую технику в сервис-контейнере Laravel, которая позволяет вам внедрять различные реализации интерфейса на основе конкретного контекста. Это полезно, когда выбор платежного процессора зависит от состояния приложения, например от того, какой контроллер обрабатывает запрос.

Шаг 1. Понимание контекстной привязки

Контекстная привязка в Laravel позволяет контейнеру службы внедрять различные реализации интерфейса в зависимости от класса или контекста, запрашивающего его. Вместо того, чтобы полагаться на единую, жестко запрограммированную реализацию, мы можем использовать контекстную привязку для определения различных платежных процессоров на основе контроллера или какого-либо другого контекстного фактора.

Шаг 2. Контекстная привязка в AppServiceProvider

Давайте начнем с настройки контекстных привязок в AppServiceProvider. Мы свяжем разные платежные системы в зависимости от контроллера, который их запрашивает. Например, StripePaymentController будет использовать StripePaymentProcessor, а PayPalPaymentController будет использовать PayPalPaymentProcessor.

Вот как это можно сделать:

use App\Contracts\PaymentProcessorInterface;
use App\Services\StripePaymentProcessor;
use App\Services\PayPalPaymentProcessor;

public function register()
{
    $this->app->when(StripePaymentController::class)
              ->needs(PaymentProcessorInterface::class)
              ->give(StripePaymentProcessor::class);

    $this->app->when(PayPalPaymentController::class)
              ->needs(PaymentProcessorInterface::class)
              ->give(PayPalPaymentProcessor::class);
}

Что здесь происходит?

• $this->app->when(): указывает Laravel привязать конкретную реализацию интерфейса, когда это необходимо определенному классу (в данном случае контроллеру).
• .needs(): указывает, что классу (StripePaymentController или PayPalPaymentController) необходим экземпляр PaymentProcessorInterface.
• .give(): определяет, какую конкретную реализацию предоставить. Например, StripePaymentController получает StripePaymentProcessor, а PayPalPaymentController — PayPalPaymentProcessor. Эта привязка позволяет вам динамически определять правильный платежный процессор в зависимости от того, какой контроллер обрабатывает запрос.

Шаг 3. Отдельные контроллеры для каждого способа оплаты

Благодаря контекстной привязке каждый контроллер теперь может автоматически внедрять свой выделенный платежный процессор. Вот как вы можете настроить контроллеры:

Пример: StripePaymentController

use App\Contracts\PaymentProcessorInterface;

class StripePaymentController extends Controller
{
    protected $paymentProcessor;

    public function __construct(PaymentProcessorInterface $paymentProcessor)
    {
        $this->paymentProcessor = $paymentProcessor;
    }

    // Methods to handle Stripe-specific payments...
}

Пример: PayPalPaymentController

use App\Contracts\PaymentProcessorInterface;

class PayPalPaymentController extends Controller
{
    protected $paymentProcessor;

    public function __construct(PaymentProcessorInterface $paymentProcessor)
    {
        $this->paymentProcessor = $paymentProcessor;
    }

    // Methods to handle PayPal-specific payments...
}

В обоих примерах Laravel автоматически добавляет правильный платежный процессор на основе контекста контроллера. Это происходит благодаря контекстной привязке, настроенной в AppServiceProvider.

Зачем использовать контекстную привязку?

Контекстная привязка особенно полезна, когда вы знаете, какую реализацию интерфейса использовать на основе конкретных классов или контекстов, например контроллеров. Это помогает поддерживать чистоту и управляемость вашего кода, особенно при работе с несколькими платежными шлюзами, каждый из которых имеет свой собственный контроллер.

Заключение

В этом посте мы рассмотрели, как реализовать контекстную привязку в Laravel 11 для обработки платежей. Вот краткий обзор преимуществ этого подхода:

• Чистый код: нет необходимости вручную выбирать между различными платежными системами.
• Автоматическое внедрение: Laravel автоматически внедряет правильный процессор в зависимости от контекста (контроллера).
• Гибкость: вы можете легко распространить этот подход на другие части вашего приложения, например, на различные сервисы или другие контексты. Когда использовать контекстную привязку, а не фабричный шаблон
• Контекстная привязка: идеально, когда процессор можно выбрать на основе определенных классов (например, различных контроллеров) или известных контекстов. Это упрощает код, поскольку контекст известен во время компиляции.
• Шаблон Factory: используйте шаблон Factory, если вы хотите динамически выбирать платежную систему на основе данных времени выполнения (например, ввод пользователя, запрос API). Этот подход обеспечивает большую гибкость при выборе платежной системы во время выполнения на основе данных, которые могут быть неизвестны до тех пор, пока запрос не будет обработан.

В следующем посте мы рассмотрим шаблон Factory, который позволяет динамически выбирать платежные процессоры во время выполнения, обеспечивая еще большую гибкость для сложных приложений.

Ждите следующей части, где мы расскажем, как использовать фабрики для обработки платежей в Laravel 11!