Atenção: esse artigo tem uma palestra complementar. Clique e assista!

Os Design Patterns são padrões de design de soluções de software que já foram usados e aprovados para solucionar problemas comuns do desenvolvimento. Os Patterns mais famosos são os que foram catalogados no famoso livro conhecido como GOF (Gang Of Four). Apesar de esta literatura conter a descrição de 23 Patterns, não significa que os Design Patterns se limitam a este grupo. O uso destes Patterns, tanto os descritos no GOF quanto outros, contribui para o aumento da qualidade do nosso software, permitindo um menor grau de acoplamento, um maior reuso de código devido ao nível de abstração aplicado, uma maior coesão das classes e uma melhor legibilidade do código. Os Design Patterns são independentes de plataforma e tecnologia, sendo possível aplicá-los em qualquer linguagem orientada dos objetos. O conhecimento de orientação a objetos, por sinal, é algo imprescindível para a compreensão dos patterns.

Segundo o GOF, os Design Patterns são divididos em três categorias:

• Criacionais – Factory Method, Abstract Factory, Builder, Prototype, Singleton;

• Estruturais – Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy;

• Comportamentais –Interpreter, Template Method, Chain of Responsability, Command, Iterator, Mediator, Memento, Observer, State, Strategy, Visitor.

Hoje existe uma gama enorme de material sobre Design Patterns, porém é mais comum encontrar este material para Java e .Net, não é muito comum vermos exemplos de aplicações práticas de Design Patterns em aplicações Delphi. É exatamente isso que vamos tratar aqui, demonstrar de forma prática, como aplicar Design Patterns em problemas reais que podemos enfrentar diariamente em nossos projetos.

Primeiramente nós explicaremos os Patterns que usaremos e depois desenvolveremos uma aplicação simples e ao longo dela iremos implementar os Patterns pertinentes a cada tipo de problema. Aqui usaremos o Singleton para garantirmos apenas uma instância de nosso objeto Aplicacao e Conexao, o DAO para abstrair o acesso a dados do nosso sistema e a Factory para abstrair e isolar a criações de nossas DAO’s.

Singleton

De acordo com o GOF, o objetivo do Singleton é garantir que uma classe possua apenas uma instância dentro da sua aplicação e que esta instância possua um ponto de acesso global a todo o sistema. O Singleton precisa garantir que não teremos duas instâncias de um determinado objeto em nosso sistema. Como podemos notar na Figura 1, a implementação tradicional do Singleton prevê que haja um atributo privado e estático do tipo da classe, aqui no exemplo chamado de FInstance. Esse atributo é onde ficará a única instância de nosso objeto. Observe também que o construtor está privado, isso é necessário para que não seja possível criar instâncias deste objeto em qualquer lugar do sistema. O método GetInstance é o nosso ponto de acesso global à nossa instância. Veja na Listagem 1 a implementação em Delphi desta classe.

Figura 1. O padrão Singleton

Listagem 1. Implementação padrão do Singleton

unit UMySingleton;
   
  interface
  type
    TMySingleton = class
      private
        class var FInstance:TMySingleton;
        constructor create();
      public
        class function GetInstance():TMySingleton;
    end;
   
  implementation
   
  { TMySingleton }
   
  constructor TMySingleton.create;
  begin
    inherited;
  end;
   
  class function TMySingleton.GetInstance: TMySingleton;
  begin
  //Verifica se a instância já foi criada
  //caso não tenha sido, cria a mesma usando o construtor privado
    if (not Assigned(FInstance)) then
      FInstance := create;
  //retorna a instância do Singleton
    result := FInstance;
  end;
   
  end.

DAO – Data Access Objects

Data Access Objects, mais conhecido como DAO, visa separar toda a parte de acesso a dados em classes específicas para esta tarefa. Isso aumenta a coesão do código, já que separamos o modelo e sua regra de negócio dos códigos SQL para persistência e recuperação de dados do banco. Normalmente temos uma classe DAO para cada domínio da aplicação. Isso pode parecer ruim, pois aumentaríamos consideravelmente o número de classes do sistema. Mesmo assim a aplicação deste Pattern é interessante, pois mantemos centralizado em uma única classe todo o código de acesso a dados referente a um determinado modelo. Na aplicação do pattern DAO, os métodos para as operações CRUD recebem os objetos a serem persistidos como parâmetro, conforme ilustrado na ...