Artigos Delphi Design Patterns - Parte 1- Clube Delphi 122
Por que eu devo ler este artigo: Como instanciar Forms e utilizá-las através de arquivos de configuração ou registros em banco de dados e como criar uma aplicação totalmente independente de banco de dados e de tecnologia de acesso.

Os padrões de criação servem, principalmente, para isolar e desacoplar unidades com classes que precisam de um objeto das unidades que criam o objeto propriamente dito. O principal objetivo dos padrões mencionados é separar o processo de criação de um objeto de sua implementação. Ou seja, todas as units que usariam um determinado objeto não precisam conter uma referência à Unit que possui a declaração e implementação do mesmo.

Aliada com o uso de interfaces, esta técnica favorece a criação e o uso de objetos e famílias inteiras de objetos que possam ser intercambiáveis, inclusive em tempo de execução. Essencial quando uma classe precisa de um objeto de uma certa interface, mas não sabe exatamente qual objeto instanciar, ou quando queremos deixar a criação de um objeto ou exibição de um formulário a cargo do usuário, onde ele pode decidir e configurar qual classe será usada. Aplicações flexíveis e com mínimo acoplamento devem usar esta técnica.

Resumo: Cada vez mais nos é exigido que nossas aplicações sejam flexíveis e que possam ser usadas com vários bancos de dados. O custo, tempo e dificuldade de se fazer uma alteração desse tipo numa aplicação 100% RAD podem ser altíssimos. Mas ninguém transforma uma aplicação RAD já robusta e madura no mercado por algo totalmente Orientado a Objetos. Esse artigo mostrará técnicas básicas de padrões de projetos que podem ser usadas mesmo em aplicações RAD com componentes Data-Aware, pois o foco desta técnica é criar interfaces e objetos que possam ser configurados ou trocados em tempo de execução de maneira transparente para o usuário e fácil para o desenvolvedor, através de métodos de outras classes responsáveis por criar e configurar os objetos corretos. O principal exemplo disso seria a criação dos objetos de acesso a dados, dependendo do banco utilizado.

Quando precisamos flexibilizar nossas aplicações criamos uma complexa hierarquia de objetos, com vários níveis de descendência e várias classes irmãs com o mesmo ancestral em comum. Ao longo de nosso sistema precisamos passar objetos como parâmetros para métodos de outros objetos, e fazemos várias operações onde as instâncias configuram-se mutuamente.

Alguns impasses podem surgir como diminuir o acoplamento e a complexidade de uma aplicação, isolar a criação e configuração de um objeto da classe que precisará dele, sem alterar sua interface ou outros módulos que já dependem dele.

Vários cenários dão margem a esse impasses, como por exemplo:

  • Trocar uma classe ou Unit sem fazer alterações que comprometam o funcionamento do sistema;
  • Trocar o comportamento ou funcionalidades de nosso sistema apenas por adicionar ou trocar arquivos ou configurações;
  • Instanciar classes e Forms, e executar seus métodos através de Strings;
  • Criar famílias paralelas de objetos, com dados e operações diferentes, que podem ser facilmente trocados entre si pelo desenvolvedor ou até mesmo pelo usuário;
  • Criar aplicações que funcionem com múltiplos bancos de dados e múltiplas tecnologias de acesso.

Dois padrões de projeto que tornam isso possível são o Factory Method e o Abstract Factory. Factory Method é um método de uma classe chamada Factory (fábrica) que cria e retorna um objeto de outra classe chamado Product, separando assim a lógica da criação de um objeto do seu uso. Ele permite também que as subclasses da fábrica definam qual o tipo correto de objeto a ser criado. Já a Abstract Factory pode ser uma interface comum ou uma classe ancestral de todas as fábricas. Ela tem os métodos abstratos para criação de produtos, mas delega às suas descendentes a inteligência de saber qual família de produtos criar.

Neste artigo iremos abordar os temas Factory Method e Abstract Factory com exemplos teóricos e práticos. Além dos exemplos, mostrar como essas técnicas podem auxiliar no desacoplamento entre as partes do seu sistema e algumas dicas para tornar isso mais viável.

Mostraremos como isolar nossas classes de negócio das classes de persistência, mantendo, porém uma interface comum entre elas, para que os dois lados da aplicação possam ser alterados livremente.

Para isso usaremos os padrões de criação Factory Method e Abstract Factory, mas antes precisaremos explicar esses conceitos.

Cliente: Podemos usar a palavra cliente para designar um objeto que precisa ou depende de outro. Por exemplo, se um ClientDataset depende de um DatasetProvider e que este esteja instanciado, o ClientDataset é o cliente, e o DatasetProvider o provedor. No caso dessas classes em especial o nome delas já diz tudo. Porém veremos mais adiante casos especiais de clientes e provedores.

Padrões de criação: São padrões de projeto usados para se construir classes ou métodos que criem e configurem objetos de outras classes. Eles podem ser usados para se criar várias formas de se instanciar um objeto, ou vários objetos ligados entre si, sem que o cliente (objeto utilizador) saiba como esses outros objetos são ligados entre si e sem que a Unit cliente precise ter uma referência a Unit do provedor. Estudaremos dois desses padrões, o Factory Method e o Abstract Factory, porém existem outros que não serão abordados nesse artigo, como Builder e Flyweight, só para citar dois.

Nota: O Builder é um padrão de projeto que permite a separação da criação de um objeto da sua representação, de forma que este permita a construção de diferentes representações. Este padrão é muitas vezes comparado com ao Abstract Factory pois ambos podem ser utilizados para a construção de objetos complexos. A grande diferença entre ambos é que o Builder constrói apenas objetos complexos enquanto o Abstract Factory constrói famílias de objetos, simples ou complexos, de uma só vez.

O padrão Flyweight é apropriado quando vários objetos devem ser manipulados, e esses não suportam dados adicionais. Neste não existem ponteiros para os métodos, pois isto consome muita memória. Em contrapartida são chamadas sub-rotinas diretamente para acessar as informações.

Factory Method: É um padrão de projeto de Software que fornece uma interface para criação de famílias de objetos relacionados ou dependentes, sem especificar suas classes concretas. É um método de uma classe que cria um objeto. E Factory é uma classe que possui um ou mais factory methods. Esse padrão de projeto permite que a criação do objeto seja delegada para suas subclasses. Assim, se um cliente precisa de um objeto que faz parte de uma família ou série de classes que tem um mesmo ancestral em comum ou implementam a mesma interface mas não sabe qual classe necessariamente ele deve instanciar, ele simplesmente pode chamar um método fábrica de uma classe fábrica. Esse método será o responsável por saber que tipo de objeto criar e como inicializá-lo. Assim, a Unit do cliente não precisará ter em seu “uses” as Units dos provedores.

Abstract Factory: É um padrão de projeto que permite a criação de famílias de objetos relacionados ou dependentes, através de uma única interface e sem que a classe concreta seja especificada. Abstract Factory é uma classe abstrata mãe de todas as classes Factory, que têm a interface padrão de todas elas.

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