Entendendo o pattern Strategy em PHP

<?php class Carrinho {
// adiciona item, remove item e outros métodos do carrinho
public function getTotal() {
$total = 0; foreach($this->itens as $item) { $total += $item->getValor(); }
return $total; }
public function getTotalComDesconto() { // precisamos implementar este método }
} ?> 

Então podemos começar a escrever o nosso método getTotalDesconto. Para poder calcular o desconto, precisamos saber qual é a forma de pagamento e por isso vamos pedi-la por parâmetro. Já que temos várias possibilidades, vamos verificar todas.

Mas o que acontece se for necessário implementar uma nova forma de pagamento? Bom, teríamos que adicionar mais um if a esse método e isso não é bom! Veja que o nosso método não vai parar de crescer nunca.

A nossa classe Carrinho sabe muito sobre os meios de pagamento, quem deveria saber como calcular o valor com desconto é o meio de pagamento, temos basicamente um código procedural disfarçado dentro de uma classe onde é necessário verificar todas as possibilidades com ifs para tomar uma decisão.

Já que não é responsabilidade da classe carrinho fazer este cálculo, vamos extrair esse comportamento para classes mais específicas, Por exemplo o primeiro if que verifica se a forma de pagamento Boleto no lugar de fazer:

podemos extrair para essa nova classe:

seguindo esse raciocínio cada forma de pagamento que estamos verificando nos ifs vai virar uma classe como Boleto,DebitoOnline,Paypal.

Agora que temos classes especificas para o pagamento vamos utilizá-las  no nosso método.

Veja que isso não resolveu o nosso problema dos ifs e esse método ainda cresce toda vez que é preciso adicionar uma forma de pagamento. Todas as formas de pagamento tem algo em comum,  elas possuem um método chamado calcula que recebe o valor bruto e retorna o valor com desconto. Se conseguirmos garantir isso, não importa qual é a forma de pagamento, só precisamos chamar o método calcula.

Em orientação a objetos, como podemos forçar que uma classe implemente um método ? Criando uma interface! Então vamos criar a interface FormaDePagamento que força todo mundo a implementar um método chamado calcula.

Agora todas as formas de pagamento devem implementar esta interface:

O nosso getTotalComDesconto pede alguém com um método calcula, que recebe o valor bruto por parâmetro e invoca esse método:

Veja que agora toda vez que for necessário adicionar uma forma de pagamento basta criar uma classe que implemente a interface FormaDePagamento portanto, o nosso método getTotalComDesconto não cresce conforme criamos uma forma de pagamento pois agora injetamos a estratégia do cálculo. A principal vantagem dessa solução é que a tarefa de adicionar uma forma de pagamento se torna muito mais simples o que facilita a manutenção do código, alem disso temos classes mais coesas e por mais que a classe carrinho esteja acoplada a outras classes veja que o parâmetro pede uma interface ou seja estamos nos acoplando a uma abstração que são naturalmente mais estáveis.

Esta abordagem que utilizamos é um design pattern que chamamos de Strategy.

Se interessa por design patterns? Veja este pattern e outros no nosso curso do alura!