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;"

[...] continue lendo...

Design Patterns: Implementando os padr�es Decorator e Singleton

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

Artigos relacionados