Design Patterns - Parte 1- Clube Delphi 122

Este artigo abordará o tema Design Patterns ou padrões de projeto. Explicaremos como funcionam os padrões de projeto criacionais Factory Method e Abstract Factory e demonstraremos como eles podem ser usados para criar uma aplicação com o menor nível de acoplamento possível entre os módulos. Serão mostrados vários exemplos de criação e utilização desses padrões com dificuldade progressiva.

Fique por dentro
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:

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

[...] continue lendo...

Artigos relacionados