strategy 3

Participantes • Strategy (Compositor) – define uma interface comum para todos os algoritmos suportados. Context usa esta interface para chamar o algoritmo definido por uma ConcreteStrategy. • ConcreteStrategy (SimpleCompositor, TeXCompositor, ArrayCompositor) – implementa o algoritmo usando a interface de Strategy. • Context (Composition) – é configurado com um objeto ConcreteStrategy; – mantém uma referência para um objeto Strategy; – pode definir uma interface que permite a Strategy acessar seus dados. Colaborações • Strategy e Context interagem para implementar o algoritmo escolhido. Um contexto pode passar todos os dados requeridos pelo algoritmo para a estratégia quando o algoritmo é chamado. Alternativamente, o contexto pode passar a si próprio como argumento para operações de Strategy. Isto permite à estratégia chamar de volta o contexto conforme requerido. • Um contexto repassa solicitações dos seus clientes para sua estratégia. Os clientes usualmente criam e passam um objeto ConcreteStrategy para o contexto; após isso, interagem exclusivamente com o contexto. Freqüentemente existe uma família de classes ConcreteStrategy para um cliente fazer sua escolha. Conseqüências O padrão Strategy tem os seguintes benefícios e desvantagens:

1. Famílias de algoritmos relacionados. Hierarquias de classes Strategy definem uma família de algoritmos e comportamentos para os contextos reutilizarem. A herança pode ajudar a fatorar a funcionalidade comum dos algoritmos.
2. Uma alternativa ao uso de subclasses. A herança oferece uma outra maneira de suportar uma variedade de algoritmos ou comportamentos. Você pode especializar uma classe Context para lhe dar diferentes comportamentos. Mas isso congela o comportamento em Context, misturando a implementação do algoritmo com a de Context, tornando Context mais difícil de compreender, manter e estender. E não se pode variar de algoritmo dinamicamente. Você acaba tendo muitas classes relacionadas cuja única diferença é o algoritmo ou comportamento que elas empregam. Encapsular os algoritmos em classes Strategy separadas permite variar o algoritmo independentemente do seu contexto, tornando mais fácil trocá-los, compreendê-los e estendê-los.
3. Estratégias eliminam comandos condicionais da linguagem de programação. O padrão Strategy oferece uma alternativa ao uso de comandos condicionais para a seleção de comportamentos desejados. Quando diferentes comportamentos são agrupados em uma classe é difícil evitar o uso de comandos condicionais para a seleção do comportamento correto. O encapsulamento do comportamento em classes Strategy separadas elimina estes comandos condicionais. Por exemplo, sem usar estratégias, o código para quebrar o texto em linhas se pareceria com O padrão Strategy elimina este comando case pela delegação da tarefa de quebra de linhas para um objeto Strategy: Um código que contém muitos estados freqüentemente indica a necessidade de aplicar o padrão Strategy.
4. A possibilidade de escolha de implementações. As estratégias podem fornecer diferentes implementações do mesmo comportamento. O cliente pode escolher entre estratégias com diferentes compromissos entre tempo e espaço.
5. Os clientes devem conhecer diferentes Strategies. O padrão tem uma deficiência potencial no fato de que um cliente deve compreender como Strategies diferem, antes que ele possa selecionar o mais apropriado. Os clientes podem ser expostos a detalhes e aspectos de implementação. Portanto, você deveria usar o padrão Strategy somente quando a variação em comportamento é relevante para os clientes.
6. Custo de comunicação entre Strategy e Context. A interface de Strategy é compartilhada por todas as classes ConcreteStrategy, quer os algoritmos que elas implementem sejam triviais ou complexos. Daí ser provável que alguns ConcreteStrategy não usem toda a informação passada através desta interface; ConcreteStrategies simples podem não usar quaisquer dessas informações! Isso significa que existirão situações em que o contexto criará e iniciará parâmetros que nunca serão usados. Se esse for um problema, você necessitará de um acoplamento maior entre Strategy e Context.
7. Aumento do número de objetos. Strategies aumentam o número de objetos numa aplicação. Algumas vezes, você pode reduzir esse custo pela implementação de estratégias como objetos sem estados que os contextos possam compartilhar. Qualquer estado residual é mantido pelo contexto, que o passa em cada solicitação para o objeto Strategy.