Design Patterns - Parte 1- Clube Delphi 122

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.