Artigos Delphi Design Patterns: Implementando os padrões Decorator e Singleton
De que se trata o artigo

O objetivo deste artigo é discutir cenários de implementação em que poderão estar sendo empregados os patterns Decorator e Singleton.


Em que situação o tema é útil

Certas situações dentro do desenvolvimento de software podem ser contornadas de maneira mais fácil por meio do uso dos design patterns. Um padrão corresponde a uma técnica bem sucedida e direcionada a um problema específico, possuindo ainda uma eficiência comprovada por sucessivas implementações do mesmo em numerosos projetos.

Design Patterns - Utilizando os padrões Decorator e Singleton

Determinadas situações podem se repetir com certa regularidade dentro do desenvolvimento de software. Em tais casos, não será raro que outros desenvolvedores tenham passado pelas mesmas dificuldades, sendo que aspectos como estes podem ter levado à elaboração de padrões visando solucionar destes problemas específicos.

O padrão Decorator procura ser uma alternativa para a inclusão (ou alteração) de comportamentos de um objeto de maneira dinâmica, sem que isto force a mudanças na estrutura original considerada. Já o pattern Singleton fornece diretrizes para a existência de uma única instância de uma classe durante todo o ciclo de vida de uma aplicação.

Este artigo continua a abordagem iniciada em edições anteriores a respeito do uso de design patterns na área de software. Para isto serão discutidos aqui cenários em que os padrões Decorator e Singleton podem ser empregados, assim como características e princípios próprios de cada um destes patterns.

Design patterns (ou em português “padrões de projetos”) são técnicas destinadas à resolução de problemas específicos, os quais podem acontecer com alguma frequência durante a codificação de sistemas. O uso de padrões em projetos de software objetiva:

• Um código menos extenso e mais fácil de ser compreendido;

• Maior flexibilidade de uma aplicação frente à necessidade de mudanças;

• Uma clara separação de responsabilidades entre as diferentes classes que formam uma aplicação, evitando com isto construções de código complexas;

• O reuso de estruturas tanto dentro da aplicação que serviu de base para o surgimento das mesmas, como também em outros projetos que dependam de funcionalidades similares.

Padrões de projetos não têm sua utilização restrita a uma tecnologia específica, mesmo porque procuram ser uma solução genérica para um determinado tipo de questão. Graças a este tipo de preocupação, um pattern pode vir a ser aplicado nas mais diferentes plataformas de desenvolvimento (Delphi, C#, VB.NET, Java, C++, etc.).

Podem ser listados como benefícios decorrentes do uso de padrões:

• Uma maior padronização do código-fonte, uma vez que as implementações são realizadas levando em conta boas práticas de Orientação a Objetos;

• Aplicações de software formadas por componentes mais coesos;

• A possibilidade de reuso de algumas estruturas baseadas em design patterns;

• Por contarem normalmente com extensa documentação, padrões de software podem ser assimilados mais rapidamente por membros de uma equipe de desenvolvimento.

É uma prática comum que muitos patterns sejam representados graficamente por meio da notação UML. Diagramas de classes são o tipo de recurso mais empregado nestes casos.

Nota do DevMan

UML (sigla em inglês para "Unified Modeling Language") é uma linguagem voltada à modelagem de componentes de software e que se baseia em conceitos de orientação a objetos. Trata-se de um notação que disponibiliza uma série de diagramas, sendo o de classes um dos mais conhecidos (com este último sendo utilizado para a demonstração dos diversos patterns descritos neste artigo).

Adicionando comportamentos dinamicamente com o padrão Decorator

O padrão estrutural Decorator (Figura 1) busca permitir a adição de um comportamento adicional a um objeto de maneira dinâmica, ou seja, em tempo de execução. Um objeto baseado neste pattern adiciona assim um tratamento específico a uma instância de classe, dispensando, no entanto a necessidade de alterar o código existente. Uma forma comum de se implementar esta prática é por meio do uso de subclasses que implementam um tipo básico.

As seguintes diretrizes servem de base para a implementação deste padrão:

• Uma classe abstrata (ou dependendo da situação uma interface), na qual existirá uma série de comportamentos esperados (Componente);

• Classes concretas baseadas no tipo básico (classe ComponenteConcreto no exemplo da figura);

• Um “decorador”, ou seja, um tipo (classe abstrata Decorator) que servirá de base para estender os comportamentos da classe abstrata básica;

• Classes concretas que derivam do “decorador” (DecoratorConcretoA e DecoratorConcretoB).

A utilização de um Decorator acontece de forma transparente aos consumidores de um tipo básico, já que estes desconhecem implementações específicas da classe-base considerada. Além de ser comumente empregado na inclusão de um novo comportamento dinâmico, um Decorator pode ainda redefinir uma operação dentro de sua implementação (fazendo uso então de sobrecarga do método considerado, por exemplo).

O padrão Decorator deve ser utilizado com critério, já que a aplicação do mesmo pode resultar em um grande número de subclasses, contribuindo para uma maior complexidade das estruturas presentes em um projeto.

...
Quer ler esse conteúdo completo? Tenha acesso completo