Design Pattern: Decorator
Chegamos ao nosso décimo Padrão de Projeto estudado em nossa série, sendo o nono da lista do GoF e o quarto da família Estrutural… pois bem, preparado para aprender mais um Design Pattern em apenas 10 minutos? Então fique com a gente!
Com o Decorator Pattern podemos deixar o projeto mais dinâmico, facilitando sua compreensão e visualização, agora sem ‘embromation’, vamos ao que interessa…
Definição GOF
Anexe responsabilidades adicionais a um objeto dinamicamente. Os Decorator´s fornecem uma alternativa flexível às subclasses para estender a funcionalidade.
A partir desta afirmativa da definição do GOF, ficou evidente que esse padrão utiliza alternativas à subclasse (ou seja, herança). Como proceder se a herança não for permitida? Sendo assim, este padrão preescreve que você faça uso de composição ao invés de herança.
Inclusive temos um benefício, pois seguindo o princípio SOLID, o Decorator promove o conceito de que sua classe é fechada para modificação, porém aberta para extensão, ou seja, utilizando este padrão você adicionará funcionalidades específicas para um determinado objeto sem alterar a classe subjacente.
Resumindo, um Decorator é uma espécie de Wrapper que envolverá o objeto original, adicionando funcionalidades ao mesmo (em alguns locais perceberá que este padrão chama-se Wrapper), conforme o Decorator é adicionado dinamicamente, não há problemas se decidir não utilizá-lo numa fase posterior do desenvolvimento, pois o objeto original está intocável.
Cotidiano
E aí, está com fome? Que tal um X-Tudo? Então… partiremos de um exemplo do nosso dia a dia para termos uma analogia para que sempre se recorde deste padrão e artigo.
O X-Tudo nada mais é que um sanduíche com diversos opcionais, não é verdade? Porém sua base é um hambúrguer, daí você decidiu incluir alguns adicionais como: mais queijo, bacon, ovo, carne, presunto, alface e por aí vai até onde sua fome desejar.
Estes adicionais seriam os Decorator´s concretos, pois você o adicionou sem impactar a matriz, apenas a cobriu com diversos opcionais para saciar sua fome.
Diagrama UML
Acima temos o Diagrama UML que representa o padrão Decorator, veja a descrição de cada item:
- Componente — Uma interface para definirmos nossa base, onde terão as responsabilidades padrões para que posteriormente possamos adicionar recursos dinamicamente.
- ComponenteConcreto — Implementa Componente, sua instância também pode ser decorada com inclusão de comportamentos.
- Decorator — Mantendo uma referência a Componente, também definindo uma interface compatível com Componente.
- DecoratorConcreto (A/B) — Estenderá de Decorator, nesta classe teremos a sobreescrita com as funcionalidades, como nome já diz de forma concreta.
Implementação
Não sei que horas vocês estão lendo este artigo, mas estou fazendo próximo da hora do almoço, portanto estou cheio de fome… kkkkk… Nosso exemplo será com base no cotidiano citado anteriormente, iremos construir um sistema para montar sanduíches, inclusive X-Tudo.
O Diagrama de Classe de nosso projeto ficou desta maneira, veja que temos diversos Decorator´s e peço que foque não apenas nisso mas veja que a estrutura original, de Sanduiche não sofre alterações logo caso queira montar um sanduíche simples com sua formação padrão é possível através do ComponenteConcreto. Por falar nisso, já conseguiu identificar no diagrama de classe todos os objetos citados no Diagrama UML?
Acima temos a implementação do Componente e ComponenteConcreto, conforme citado conseguimos gerar um sanduíche em seu estado padrão.
Nesta etapa, trouxe o Decorator e o DecoratorConcreto (2 dos 4 exemplos que consta no código), observe como é simples gerar adicionais em nosso projeto. Gostaria que você utilizasse nosso código no GitHub para criar mais adicionais, pense no que está faltando… Bacon, Ketchup, Carne?
Para finalizar a implementação, temos a classe Cliente (Program.cs) realizando as devidas chamadas para o Sanduiche tendo seu estado padrão no início da execução, em seguida com os respectivos adicionais, cujo pode observar que o valor sofreu o devido reajuste.
Vantagem
Conforme dito no início de nosso artigo, fazendo uso do padrão Decorator temos a aderência do princípio Open/Closed do SOLID, além disso temos maior flexibilidade se compararmos a herança, pois adicionamos recursos em tempo de execução, por fim e acredito já percebido por você leitor: podemos anexar diversos opcionais mantendo sempre a classe base inalterada e compatível.
Desvantagem
Como nem tudo são flores, a destavagem estaria num possível encadeamento de instâncias com isso aumento do acoplamento e conforme percebido aumento do número de classes, dependendo da complexidade do seu projeto isso pode representar um problema.
Código Fonte
Baixe o código fonte em meu GitHub clicando neste link, implemente alguns ajustes no Decorator Pattern, evolua o cenário do artigo e depois me conte nos comentários.
Por fim…
Agradeço a você que ficou até os finalmentes de mais um artigo de nossa série, na próxima semana estaremos vendo sobre o Padrão Bridget, da família Estrutural do GoF e mais uma vez peço a você que gostou que curta, aplauda aqui no Medium ou até mesmo compartilhe com seus amigos e colegas de trabalho/faculdade/comunidade.
Forte abraço e até a próxima…
