Strategy é um Design Pattern documentado no Catálogo GOF (Gang of Four), sendo categorizado como um padrão comportamental, de modo que delega as responsabilidades adquiridas pelas entidades.
Este padrão permite definir novas operações sem alterar as classes dos elementos sobre os quais opera. (resumindo drasticamente em poucas palavras, permite que o algoritmo varie independentemente de quem o utilizará). Dessa forma a comunicação entre os objetos é aprimorada, pois há a distribuição das responsabilidades.
“Strategy define uma família de algoritmos de forma que estes sejam independentes de quem as utilizam. “
| Strategy – Interface comum para todas as classes (variações concretas) que definem os diversos comportamentos esperados; ConcreteStrategy – Classes que implementam os algoritmos que devem atender a cada contexto; Context – Classe onde os objetos ConcreteStrategy serão instanciados; |
Resumindo:
– Encapsular um algoritmo em um objeto.
– Fornecer interfaces genéricas para suportar uma variedade de algoritmos.
– Facilitar a escolha e troca de algoritmos criados com uma mesma função.
Implementação
A questão abordada em nosso exemplo é a necessidade de termos duas lógicas (estratégias) diferentes para aplicar imposto, tanto para pessoa física e jurídica, onde as lógicas são diferentes. Abaixo temos um exemplo escrito em C#, que implementa o diagrama abaixo:
Em nosso exemplo, temos a classe PagamentoContexto que usa a interface IEstrategiaImposto para chamar as classes concretas:
Abaixo a codificação do nosso exemplo. No 1 nos temos a relação da classe PagamentoContexto com a interface IEstrategiaImposto. No 2, vemos que uma possível forma de passar a estratégia a ser usada (PessoaFisica ou PessoaJuridica) é via construtor. No 3 temos explicitamente o método que que seta a estratégia.
Observem que no 4 temos a invocação do método AplicarImposto. Reparem que não há distinção se PessoaFisica ou PessoaJuridica. Mas como isso é possível ?
Na imagem abaixo tempos a classe PessoaJuridica, que implementa a interface IEstrategiaImposto (5) (assim como a classe PessoaFisica). Essa interface possui o método AplicarImposto (7).
Abaixo podemos ver a Interface, onde a implementação desta é chave para o padrão Strategy, permitindo que a classe PagamentoContexto apenas chame o método AplicarImposto.
Por fim temos a execução do exemplo:
No 8 nos temos a declaração da interface que será usada pela classe PagamentoContexto. Repare que após declararmos, instanciamos a classe concreta PessoaFisica (que implementa a IEstrategiaImposto), a passando através do construtor da PagamentoContexto (9). Você pode voltar ao 2 para entender melhor.
No 10 chamamos o método AplicarImposto passando 10000 por parâmetro. No passo 11, usamos a mesma interface instanciando agora a classe concreta de PessoaJuridica, e novamente passamos para PagamentoContexto a estratégia a ser utilizada na etapa 12 (agora via método).
Acima temos a execução do programa. Espero que tenham entendido esse padrão. Forte abraço !
Referências:
www.hillside.net/patterns
GAMMA, Erich et al. Padrões de Projeto: Soluções reutilizáveis de software orientado a objetos.