Artigo Clube Delphi 115 - Design Patterns para o mundo real

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (2)  (0)

Este artigo trata da aplicação prática de Design Patterns em problemas reais que enfrentamos no dia-a-dia. Construiremos um pequeno aplicativo orientado a objetos e ao longo do desenvolvimento implementaremos alguns design patterns para resolver problemas reais do sistema.

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

[lead]Do que trata o artigo

Este artigo trata da aplicação prática de Design Patterns em problemas reais que enfrentamos no dia-a-dia. Construiremos um pequeno aplicativo orientado a objetos e ao longo do desenvolvimento implementaremos alguns design patterns para resolver problemas reais do sistema.

Para que serve

A aplicação de design patterns pode aumentar a qualidade de seus sistemas, pois se trata de soluções testadas e aprovadas para problemas comuns do desenvolvimento de software. Com o uso de Patterns você pode reduzir acoplamento, melhorar a legibilidade de seu código e aumentar o grau de reuso do mesmo.

Em que situação o tema é útil

Design Patterns são exatamente soluções para resolver problemas corriqueiros, ou seja, você pode usá-los a qualquer momento em seus projetos, seja na fase de desenvolvimento ou de manutenção, você pode se deparar com um problema que já fora analisado e solucionado antes.

Resumo do DevMan

Neste artigo nós desenvolveremos uma aplicação orientada a objetos e iremos aplicar diversos patterns ao longo deste desenvolvimento. Neste primeiro artigo nós começaremos vendo a aplicação do Singleton para uma classe de conexão com o banco de dados e para o objeto que representa nossa aplicação, além de vermos o uso de DAO’S para abstrair o acesso a dados e Factory para isolar a criação de objetos.[/lead]

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.

[subtitulo]Singleton[/subtitulo]

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.

[subtitulo]DAO – Data Access Objects[/subtitulo]

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 "

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?