Decorator

O Decorator surgiu da necessidade de adicionar um comportamento, funcionalidade ou estado extra a um objeto em tempo de execução, por exemplo quando Herança não é concebível por ser um caso que geraria um número muito alto de sub-classes. Suponha que existe um objeto Arma, ela pode ter comportamentos diferentes dependendo da munição, dependendo do tipo de mira que tiver, se tiver algum tipo de silenciador ou outro acessório. Imagine criar agora uma sub classe para cada combinação possível de armas, o número de classes aumenta exponencialmente para cada opção a mais que você tiver. É ai que entra o Decorator. Outro exemplo de utilização desse padrão seria, por exemplo, um sistema de reserva de passagens no qual o passageiro possa adicionar itens e serviços à sua passagem área ou viária. Como bagagens extras, cabine com espaço maior e opções de refeição. Uma árvore de natal que recebe a adição de objetos e luzes que a decoram também é um outro exemplo do mundo real no qual aplicar-se-ia o padrão Decorator.

Um exemplo simples e prático da aplicação do Decorator seria colocar acessórios em uma arma, como miras e silenciadores. Um modo de se contornar esse problema seria criar uma interface e criar armas que implementam essa interface (Figura 2), porém isso faria com que tivéssemos muitas classes que implementam essa interface, para apenas dois acessórios teríamos que criar 4 classes (Arma sem acessórios, arma com silenciador, arma com mira, arma com mira e silenciador) tornando essa uma alternativa ruim. Além disso, essa alternativa viola os princípios de baixa acoplação e alta coesão. Outra solução seria utilizar o Design Pattern Decorator, com esse Design Pattern será possível contornar esse problema de uma forma simples e que não viole nenhum princípio de design. Além disso, ele possibilita que sejam adicionados acessórios durante o tempo de execução. A aplicação do padrão Decorator seria a seguinte (Figura 3).