A Model-Driven Software Reuse Approach (in portuguese)

padrão, cria-se uma classe abstrata para o ponto de variação, com um método principal e um
método para adicionar comportamentos adicionais. Dentro do método principal, adiciona-se
uma chamada para um comportamento abstrato, a ser implementado por cada instância concreta
que corresponde às variantes.
Figura 18: Uso do padrão Chain of Responsibility para or features
A Figura 18 ilustra o uso do padrão Chain of Responsibility na implementação de or
features. Para cada ponto de variação, no caso featureA, cria-se uma classe abstrata, contendo
um método principal (metodo()), a ser chamado no produto. Também é criado um método
(setNext()) que permite “encadear” outras instâncias a esta. Para cada variante (featureA
sozinha e sub-features A1, A2 e A3), cria-se uma subclasse que implementa o comportamento
específico da variante. O gerador, para combinar as features selecionadas, cria uma instância
da feature principal (linha 3), cria instâncias das sub-features selecionadas (linhas 4 e 5), e faz
o encadeamento (linhas 6 e 7). Dessa forma, ao se chamar o método principal (linha 9), os
comportamentos específicos de cada sub-feature são chamados.
O Chain of Responsibility permite a combinação de comportamentos sequenciais, ou seja,
um é executado após o outro. Em interações mais complexas, onde a ordem de chamada
dos comportamentos específicos não é sequencial, exigindo um código específico para isso,
o padrão Decorator pode ser utilizado. Neste padrão, cria-se um decorator para cada variante.
129