Slides - LES - PUC-Rio

Strategy
Projeto de Sistemas de Software
Evelin Carvalho Freire de Amorim
Sérgio Luiz Ruivace Cerqueira
Strategy
Propósito
Agrupar uma família de algoritmos, encapsulando cada
algoritmo. Cada algoritmo pode ser substituível um pelo
outro o que torna possível o cliente variar entre qualquer
dos algoritmos.
© LES/PUC-Rio
Motivação
• Uma biblioteca de Aprendizado de Máquina (AM)
pode ter diferentes estratégias para um problema
de classificação.
• Amarrar estas estratégias não é uma boa solução.
• Diferentes algoritmos são apropriados em momentos
diferentes. Uma árvore de decisão é pode ser mais
apropriada para um tipo de problema e AdaBoost para
outro.
• As estratégias de AM se tornam difíceis de mudar se
fazem parte dos clientes. Os algoritmos de AM estão em
constante processo de otimização.
© LES/PUC-Rio
Aplicabilidade
• Quando as classes diferem apenas no comportamento.
• A necessidade de algoritmos com diferentes
comportamentos.
• Quando o algoritmo utiliza dados que o cliente
desconhece.
• Evita declarações condicionais encapsulando em classes
Strategy.
© LES/PUC-Rio
Estrutura
© LES/PUC-Rio
Participantes
• Strategy: Declara uma interface em comum para
os algoritmos suportados.
• ConcreteStrategy: Implementa o algoritmo
utilizando a interface Strategy.
• Context:
o Possui um objeto ConcreteStrategy.
o Mantém referência para um objeto Strategy.
o Pode definir uma interface para Strategy
acessar seus dados.
© LES/PUC-Rio
Colaborações
• Para escolher o algoritmo as classes Strategy e Context
interagem.
• O cliente cria e passa um objeto ConcreteStrategy para
o Context. O cliente interage somente com o Context.
© LES/PUC-Rio
Conseqüências
• Benefícios
o Agrupar algoritmos relacionados
o Uma alternativa a subclasses
o Eliminação de declaração de condicionais
o Escolha de diferentes implementações
• Desvantagens
o O cliente deve conhecer as diferentes estratégias
o Overhead de comunicação entre Strategy e Context
o Aumento do número de objetos
© LES/PUC-Rio
Exemplo de Código
Exemplo de Código