Em nossa postagem anterior (Como adicionar e implementar interfaces de processamento de pagamento no Laravel 11: vinculação codificada), exploramos a primeira etapa na configuração de processadores de pagamento codificando a vinculação entre PaymentProcessorInterface e uma implementação específica, como StripePaymentProcessor.

Embora essa abordagem seja simples e eficaz para pequenas aplicações, ela carece de flexibilidade para cenários mais complexos onde você pode precisar lidar com vários gateways de pagamento, mas usando uma interface, nos permitiu desacoplar o código para que possamos estendê-lo ainda mais, de acordo com o princípio de abrir e fechar, para injetar a funcionalidade adequada:

• ligação contextual em tempo de compilação, usando o mecanismo Laravel Service Container.
• usando padrão de fábrica instanciando as classes necessárias em tempo de execução.

Nesta segunda parte, mergulharemos na vinculação contextual, uma técnica mais avançada no contêiner de serviço do Laravel que permite injetar diferentes implementações de uma interface com base no contexto específico. Isso é útil quando a escolha de um processador de pagamento depende do estado do aplicativo, como qual controlador está tratando a solicitação.

Etapa 1: Compreendendo a vinculação contextual

A ligação contextual no Laravel permite que o contêiner de serviço injete diferentes implementações de uma interface dependendo da classe ou contexto que a solicita. Em vez de depender de uma implementação única e codificada, podemos usar vinculação contextual para resolver diferentes processadores de pagamento com base no controlador ou em algum outro fator contextual.

Etapa 2: vinculação contextual no AppServiceProvider

Vamos começar configurando ligações contextuais no AppServiceProvider. Vincularemos diferentes processadores de pagamento com base no controlador que os solicita. Por exemplo, o StripePaymentController usará StripePaymentProcessor e o PayPalPaymentController usará PayPalPaymentProcessor.

Veja como você pode fazer isso:

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);
}

O que está acontecendo aqui?

• $this->app->when(): Isso diz ao Laravel para vincular uma implementação específica de uma interface quando uma classe específica (neste caso, um controlador) precisar dela.
• .needs(): especifica que a classe (StripePaymentController ou PayPalPaymentController) precisa de uma instância de PaymentProcessorInterface.
• .give(): determina qual implementação concreta fornecer. Por exemplo, StripePaymentController obtém StripePaymentProcessor e PayPalPaymentController obtém PayPalPaymentProcessor. Essa associação permite que você resolva dinamicamente o processador de pagamento correto, dependendo de qual controlador está processando a solicitação.

Etapa 3: controladores separados para cada método de pagamento

Com a vinculação contextual implementada, cada controlador agora pode ter seu processador de pagamento dedicado injetado automaticamente. Veja como você pode configurar seus controladores:

Exemplo: 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...
}

Exemplo: 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...
}

Em ambos os exemplos, o Laravel injeta automaticamente o processador de pagamento correto com base no contexto do controlador. Isso se deve à vinculação contextual configurada no AppServiceProvider.

Por que usar vinculação contextual?

A vinculação contextual é particularmente útil quando você sabe qual implementação de uma interface usar com base em classes ou contextos específicos, como controladores. Isso ajuda a manter seu código limpo e gerenciável, especialmente ao lidar com vários gateways de pagamento, cada um com seu próprio controlador.

Conclusão

Nesta postagem, exploramos como implementar vinculação contextual no Laravel 11 para processamento de pagamentos. Aqui está uma rápida recapitulação dos benefícios dessa abordagem:

• Código mais limpo: não há necessidade de lógica manual para escolher entre diferentes processadores de pagamento.
• Injeção automática: o Laravel injeta automaticamente o processador correto com base no contexto (controlador).
• Flexibilidade: você pode estender facilmente essa abordagem para outras partes do seu aplicativo, como diferentes serviços ou outros contextos. Quando usar vinculação contextual versus padrão de fábrica
• Contextual Binding: Ideal quando o processador pode ser selecionado com base em classes específicas (como controladores diferentes) ou contextos conhecidos. Ele simplifica o código onde o contexto é conhecido em tempo de compilação.
• Padrão de fábrica: use o padrão de fábrica se desejar selecionar dinamicamente um processador de pagamento com base em dados de tempo de execução (por exemplo, entrada do usuário, solicitação de API). Esta abordagem oferece mais flexibilidade para selecionar o processador de pagamento, em tempo de execução, com base em dados que podem não ser conhecidos até que a solicitação seja processada.

No próximo post exploraremos o Factory Pattern, que permite a seleção dinâmica de processadores de pagamento em tempo de execução, proporcionando ainda mais flexibilidade para aplicações complexas.

Fique ligado na próxima parte, onde abordaremos como usar fábricas para processamento de pagamentos no Laravel 11!