Ou porque não usar herança.

1. Strategy Pattern
Ou porque não usar herança...
Quando trata-se de desenvolvimento de
software a maior certeza que temos é que
ocorrerão mudanças.

2. O que é Herança em OO
Herança é um mecanismo que permite que características comuns a
diversas classes sejam fatoradas em uma classe base, ou superclasse.
A partir de uma classe base, outras classes podem ser especificadas.
Cada classe derivada ou subclasse apresenta as características
(estrutura e métodos) da classe base e acrescenta a elas o que for
definido de particularidade para ela.
Muitos programadores usam a herança incorretamente para reaproveitar
ou organizar código!

3. Quando usar herança
Estenda uma classe apenas quando for necessário substituir a
classe original pela subclasse, de forma a estender as
funcionalidades originais.
Siga o princípio da Substituição de Liskov o S do SOLID.

4. SOLID
S - Single Responsibility
O - Open/Closed
L - Liskov Substitution
I - Interface Segregation
D - Dependency Inversion

5. Princípio da substituição de Liskov
Na programação orientada a objeto, o princípio da substituição de Liskov é uma
definição particular para o conceito de subtipo. Foi introduzido em 1993 por
Barbara Liskov e Jeannette Wing através de um artigo de nome Family Values:
A Behavioral Notion of Subtyping.
"Onde um objeto da classe base pode ser usado, um objeto da
subclasse deve também poder ser usado".

6. Uma regra de ouro sobre herança
Se a sentença A é-um B "soa bem", então você deveria utilizar herança,
para aproveitar tudo que B oferece para A.
Caso contrário, tanto se A é-um B não "soa bem", mas deseja-se
reaproveitar o comportamento de B em A, como se A tem-um B "soa
bem", então você deveria utilizar composição.
Agora um pequeno exercício que demonstra claramente essa regra.

7. Começou com um simples aplicativo, como sempre começa
Joe trabalha para uma empresa que cria um jogo de simulação de lago com patos
de grande sucesso, o SimUDuck. O jogo pode mostrar uma grande variedade de
espécies de pato nadando e produzindo sons. Os designers iniciais do sistema
usaram técnicas OO padrão e criaram uma superclasse Duck

8. Mas agora precisamos que os patos VOEM
Os executivos decidiram que fazer os patos voarem é o que o simulador precisa para acaba com a
concorrência. E é claro que o gerente de Joe disse a eles que Joe poderia criar algo em uma semana.
“Afinal”, disse o chefe de Joe, “ele é programador OO... não pode ser muito difícil”.

9. Alguma coisa deu muito errado...
Joe não percebeu que nem todas as subclasses de Duck deveriam voar. Quando Joe adicionou um novo
comportamento à superclasse Duck, também estava adicionando um comportamento que não era
apropriado para algumas subclasses Duck. Agora, objetos inanimados estavam voando no programa
SimUPato.
Uma atualização localizada no código causou um efeito colateral
não-local (patos de borracha voadores)!

10. Resolvendo o nosso problema
● Identifique os aspectos de seu aplicativo que variam e separe-os do que
permanece igual
● Programe para uma interface e não para uma implementação, antes
estávamos presos a uma implementação concreta vinda da superclasse
Duck e não havia espaço para alterar o comportamento a não ser
escrevendo mais código
● Dê prioridade a composição ao invés da herança, em vez de herdar
comportamentos as classes devem obter seus comportamentos ao serem
compostas por outras classes separadas em conjuntos de classes

11. Interfaces e suas vantagens
● É um contrato que deve ser seguido quando fizermos uma implementação
● Reduz o acoplamento do seu código
● Pode ser usada como documentação do seu código já que é um contrato
que deve ser seguido pela classe que a implementa
● Oferece flexibilidade no desenvolvimento, o programador pode usar sua
própria classe desde que essa classe implemente a interface requerida para
executar certo método

12. Strategy
O padrão Strategy serve para “definir uma família de algoritmos, encapsular cada
uma delas e torná-las intercambiáveis. Strategy permite que o algoritmo varie
independentemente dos clientes que o utilizam” (como definido no livro do GoF).
Dica: use strategy quando tiver lógicas complexas
de condicionais!
O Padrão Strategy sugere que se produza uma família
de classes para cada variação do algoritmo