Nesta semana o tema da vez é Strategy, um dos design patterns mais famosos e usados no mundo, mas afinal o que são design patterns ? Para que servem ? Venha descobrir conosco logo mais.
Em 1994, quatro engenheiros de software escreveram o livro “Design Patterns: Elements of Reusable Object-Oriented Software” com o objetivo de catalogar problemas comuns aos projetos de desenvolvimento de software e as formas de resolver esses problemas. Os autores catalogaram 23 padrões que utilizaram ao longo de suas carreiras, que posteriormente, ficaram conhecidos por a “Gang of Four” (GoF).Proporcionando assim, a criação de outros livros com este mesmo intuito.
Design Patterns ou padrões de projetos são soluções generalistas para problemas recorrentes durante o desenvolvimento de um software. Não se trata de um framework ou um código pronto, mas de uma definição de alto nível de como um problema comum pode ser solucionado.
As principais vantagens de usar algum design pattern são: utilizar modelos já testados buscando o ganho de produtividade, ter um código mais manutenível, organizado e com o mínimo de acoplamento. Além disso vários design patterns são tão famosos que em uma conversa só utilizar o nome de algum deles já basta para o entendimento.
O strategy é um padrão comportamental de projeto, que permite a mudança de comportamento de um conjunto de classes em tempo de execução, fazendo com que seus objetos operem de forma diferente dependendo da operação a ser realizada. Tipicamente usado para melhorar manutenção do código, distribuir as responsabilidades de cada classe, encapsular algoritmos similares em uma tomada de decisão, entre outros.
Vamos a um exemplo, considere um programa simples para calcular alguns impostos sobre algum orçamento.
Acima temos a classe responsável por definir o valor do orçamento e também por fornecedor este valor por meio de um método get, já que o atributo valor é privado.Algo comum seria termos vários tipos de impostos, então um código comum seria algo do tipo:
Nesta classe recebemos o impostos como uma string e testamos para cada imposto qual seu valor. Até aqui tudo parece funcionar bem, porém imagine se tivéssemos vários impostos diferentes, com cálculos bem mais complexos que os até então apresentados, e pior que a cada período de tempo seja necessário adicionarmos novos impostos. Nossa classe ficaria enorme em pouco tempo e já não representaria bem seu papel. O segundo princípio do S.O.L.I.D diz que uma classe deve ser aberta a extensão, mas fechada para modificação, ou seja,quando novos comportamentos e recursos precisam ser adicionados no software, devemos estender e não alterar o código fonte original.
O strategy busca solucionar esse problema, criando uma interface imposto, nela criamos um método “calcula”, assim toda a classe que implementar esta interface imposto será obrigada a criar este método com este nome.
Agora para cada imposto criamos uma classe que implementa esta interface, considere o mesmo código para cada novo imposto, apenas aplicando um cálculo diferente conforme o necessário, logo a classe de algum imposto será:
Finalmente chegamos na classe “CalculadoraDeImpostos”, agora ela apenas aciona o método “calcula” referente a cada imposto passado como parâmetro, note que agora o imposto não é mais uma string e sim um objeto do tipo imposto, já que nossa interface obriga a implementação do método “calcula” não teremos problemas.
No nosso index, ou main, apenas passamos uma instância do imposto desejado e incluímos as demais classes do sistema.
Desta maneira, nossa implementação usando strategy elimina vários pontos fracos, como: o aumento incontrolável dos if’s da classe “CalculadoraDeImpostos” que conforme sua aplicação, aumenta de tamanho, e o forte acoplamento em uma única classe, no caso a “CalculadoraDeImpostos”, dificultando a manutenção e leitura. Além disso, ganhamos tempo quando for necessário desenvolver testes para as classes de impostos, já que as mesmas estarão isoladas em uma classe separada, contendo apenas suas funcionalidades.
Vários programadores optam por usar strategy no nome da interface, facilitando a leitura de outro programador, pois logo ele já saberá do que se trata tal interface.
O design pattern strategy tem vários usos, mas sua maioria gira em torno de eliminar o acoplamento em classes, sejam eles como o mostrado acima ou causados pelo mau uso da herança em projetos orientado a objeto.
O strategy têm três papéis bem definidos:
-
Context: É responsável pela criação e manutenção de uma referência a uma classe Strategy específica, no nosso exemplo seria a classe CalculadoraDeImpostos.
-
Strategy: É a interface comum a todos os algoritmos suportados. Através desta interface, o Context pode chamar o algoritmo criado pela ConcreteStrategy, no exemplo seria a interface Imposto.
-
ConcreteStrategy: Implementa o algoritmo usando a interface Strategy, no exemplo todos os impostos que desejamos criar, ICMS, ISS, entre outros.
A figura acima exemplifica como os papéis se relacionam no strategy, note que é possível ter quantas classes ConcreteStrategy desejar, todas elas seguindo a interface strategy.
Este é o famoso livro GoF, é um livro mais antigo com leitura não tão simples mas com muita qualidade:
GAMMA, Erich; HELM, Richard; JOHNSON, Ralph; VLISSIDES, John. Padrões de Projeto: soluções reutilizáveis de software orientado a objetos. Ed. 1. Bookman, 2000. ISBN 9788573076103.
Este é um livro de leitura mais simples, com exemplos mais visuais e até engraçados, vale muito a leitura:
Eric Freeman; Use a cabeça! : padrões de projetos; tradução Andreza Gonçalves, Marcelo Soares e Pedro Cesar de Conti. Ed. 1. Alta Books, 2009.
Bruno Rossi – 01/07/2020
