Strategy Pattern em Java: Como Tornar Pagamentos Mais Flexíveis e Extensíveis

RESUMO

Este artigo apresenta um estudo de caso sobre a aplicação do padrão de projeto Strategy na linguagem Java, tomando como cenário a evolução do PetHub, um sistema de gerenciamento e comercialização de produtos veterinários. O problema investigado decorre da necessidade de suportar múltiplas formas de pagamento - Pix, cartão de crédito e boleto bancário - sem concentrar suas regras em uma única classe por meio de estruturas condicionais, o que tende a aumentar o acoplamento e reduzir a extensibilidade do sistema.

A partir da fundamentação teórica do Strategy Pattern, é proposta uma solução orientada a objetos que encapsula cada forma de pagamento em uma estratégia independente, unificadas por uma interface comum e utilizadas por uma classe de contexto. São apresentados o diagrama de classes UML da solução, uma representação da arquitetura do sistema e a implementação completa em Java. Por fim, discutem-se as vantagens, desvantagens e os principais trade-offs envolvidos na adoção do padrão, concluindo-se que sua utilização é adequada quando há tendência real de crescimento e variação de comportamentos, ainda que introduza classes e abstrações adicionais ao projeto.

1 INTRODUÇÃO

No desenvolvimento de sistemas de software, é comum que uma aplicação precise executar diferentes comportamentos para atender às necessidades de seus usuários. Conforme o sistema evolui, novas funcionalidades podem ser adicionadas e, quando essas variações não são bem organizadas, o código tende a se tornar mais difícil de compreender, testar e manter.

Nesse contexto, os Design Patterns, ou padrões de projeto, oferecem soluções reutilizáveis para problemas recorrentes no desenvolvimento de software. Entre esses padrões está o Strategy, pertencente à categoria dos padrões comportamentais. Seu principal objetivo é permitir que diferentes algoritmos ou comportamentos sejam encapsulados separadamente, possibilitando que sejam substituídos de acordo com a necessidade da aplicação. Dessa forma, o sistema pode trabalhar com diferentes comportamentos sem concentrar todas as regras em uma única classe ou depender de uma grande quantidade de estruturas condicionais.

Neste artigo, o Strategy Pattern é aplicado em Java a partir de um estudo de caso baseado na evolução do PetHub, um sistema voltado ao gerenciamento e à comercialização de produtos para animais. Considerando uma possível evolução do sistema para permitir a realização de pedidos, surge a necessidade de trabalhar com diferentes formas de pagamento, como Pix, cartão e boleto. A implementação inadequada dessas opções poderia aumentar o acoplamento e dificultar a manutenção do sistema.

Diante desse cenário, o artigo apresenta como o Strategy Pattern pode ser utilizado para organizar os diferentes comportamentos de pagamento, demonstrando desde o problema inicial até a implementação da solução em Java. São apresentados também um diagrama de classes UML e uma representação da arquitetura de software, permitindo visualizar tanto a estrutura do padrão quanto sua aplicação dentro do sistema. Por fim, são discutidas as vantagens, desvantagens e os principais trade-offs envolvidos na utilização desse padrão.

2 O PROBLEMA: MÚLTIPLAS FORMAS DE PAGAMENTO

Sistemas de software frequentemente precisam lidar com diferentes maneiras de realizar uma mesma operação. Em uma aplicação de comércio eletrônico, por exemplo, um cliente pode escolher entre diferentes formas de pagamento, como Pix, cartão de crédito ou boleto. Embora todas tenham o mesmo objetivo - concluir o pagamento de um pedido -, cada uma possui regras e comportamentos específicos.

Para exemplificar esse problema, é considerada uma possível evolução do PetHub. Inicialmente, o sistema foi desenvolvido com foco no catálogo de produtos veterinários. Entretanto, em uma futura expansão, torna-se necessário permitir que os clientes realizem pedidos e efetuem pagamentos diretamente pela aplicação.

Em um primeiro momento, a implementação poderia parecer simples: bastaria criar uma classe responsável pelo pagamento e utilizar estruturas condicionais para verificar qual forma de pagamento foi escolhida, conforme ilustrado a seguir: