strategy 2

1. Mudar o exterior de um objeto versus mudar o seu interior. Podemos pensar em um decorador como sendo uma pele sobre um objeto que muda o seu comportamento. Uma alternativa é mudar o interior do objeto. O padrão Strategy (292) é um bom exemplo de um padrão para mudança do interior de um objeto. Strategies representam uma escolha melhor em situações onde a classe Component é intrinsicamente pesada, dessa forma tornando a aplicação do padrão Decorator muito onerosa. No padrão Strategy, o componente repassa parte do seu comportamento para um objeto strategy separado. O padrão Strategy permite alterar ou estender a funcionalidade do componente pela substituição do objeto strategy. Por exemplo, podemos suportar diferentes estilos de bordas fazendo com que o componente transfira o desenho de bordas para um objeto Border separado. O objeto Border é um objeto Strategy que encapsula uma estratégia para desenhar bordas. Através da extensão do número de estratégias de apenas uma para uma lista aberta (ilimitada) das mesmas, obtemos o mesmo efeito que quando encaixamos decoradores recursivamente. Por exemplo, no MacApp 3.0 [App89] e no Bedrock [Sym93a] componentes gráficos (chamados “views”(visões) mantêm uma lista de objetos adornadores (adorners) que podem ligar adornos adicionais, tais como bordas, a um componente visão. Se uma visão tem qualquer adorno ligado ou associado, então ela lhes dá a oportunidade de desenhar elementos adicionais. O MacApp e o Bedrock precisam usar essa abordagem porque a classe View é bastante pesada. Seria muito caro usar uma View totalmente completa somente para acrescentar uma borda.

Intenção 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. Também conhecido como Policy Motivação Existem muitos algoritmos para quebrar um stream de texto em linhas. Codificar de maneira fixa e rígida tais algoritmos nas classes que os utilizam não é desejável, por várias razões: • clientes que necessitam de quebras de linhas se tornam mais complexos se incluirem o código de quebra de linhas. Isso os torna maiores e mais difíceis de manter, especialmente se suportam múltiplos algoritmos de quebra de linhas;

• diferentes algoritmos serão apropriados em diferentes situações. Não queremos suportar múltiplos algoritmos de quebra de linhas se não usarmos todos eles; • é difícil adicionar novos algoritmos e variar os existentes quando a quebra de linha é parte integrante de um cliente. Podemos evitar esses problemas definindo classes que encapsulam diferentes algoritmos de quebra de linhas. Um algoritmo encapsulado dessa maneira é chamado strategy (estratégia).

Suponha que uma classe Composition seja responsável pela manutenção e atualização das quebras de linhas de texto exibidas num visualizador de texto. As estratégias de quebra de linhas não são implementadas pela classe Composition. Em vez disso, são implementadas separadamente por subclasses da classe abstrata Compositor. Subclasses de Compositor implementam diferentes estratégias: • SimpleCompositor: Implementa uma estratégia simples que determina quebras de linha, uma por vez. • TeXCompositor: Implementa o algoritmo TEX para encontrar quebras de linhas. Esta estratégia tenta otimizar globalmente as quebras de linhas, ou seja, um parágrafo por vez. • ArrayCompositor: Implementa uma estratégia que seleciona quebras de maneira que cada linha tenha um número fixo de itens. Por exemplo, é útil para quebrar uma coleção de ícones em linhas. Uma Composition mantém uma referência para um objeto Compositor. Sempre que uma Composition reformata seu texto, repassa essa responsabilidade para o seu objeto Compositor. O cliente de Composition especifica qual Compositor deveria ser usado pela instalação do Compositor que ele deseja em Composition. Aplicabilidade Use o padrão Strategy quando: • muitas classes relacionadas diferem somente no seu comportamento. As estratégias fornecem uma maneira de configurar uma classe com um dentre muitos comportamentos; • você necessita de variantes de um algoritmo. Por exemplo, pode definir algoritmos que refletem diferentes soluções de compromisso entre espaço/ tempo. As estratégias podem ser usadas quando essas variantes são implementadas como uma hierarquia de classes de algoritmos [HO87]; • um algoritmo usa dados dos quais os clientes não deveriam ter conhecimento. Use o padrão Strategy para evitar a exposição das estruturas de dados complexas, específicas do algoritmo; • uma classe define muitos comportamentos, e estes aparecem em suas operações como múltiplos comandos condicionais da linguagem. Em vez de usar muitos comandos condicionais, mova os ramos condicionais relacionados para a sua própria classe Strategy