Artigos Delphi Design Patterns - Parte 3 - Artigo Clube Delphi 124
Demais posts desta série:
Design Patterns - Parte 1
Design Patterns - Parte 2
Artigo no estilo: Curso

Do que trata o artigo

Será mostrado como usar os conhecimentos adquiridos nos artigos anteriores para criar um programa independente de banco de dados ou de tecnologia de acesso, tornando tudo isso configurável. Serão utilizados os padrões Singleton, Factory Method e Abstract Factory.

Para que serve

Abstract Factory é um modo de desacoplar ainda mais os sistemas, por delegar a criação de famílias inteiras de objetos sem se especificar uma classe concreta e usando uma única interface. Esse padrão permite decidir “tardiamente” qual a classe do objeto que será instanciado, tornando possível que várias partes do sistema sejam intercambiáveis.

Em que situação o tema é útil

Pode ser usado em qualquer situação onde há um conjunto de objetos que podem ser substituídos entre si para atender a um requisito. Serão aplicados esses conceitos na criação, configuração e conexão com bancos de dados. Porém não se aplica somente a isso. Num sistema de comunicações internas, por exemplo, pode-se decidir se uma mensagem é um SMS ou um e-mail em tempo de execução. Também é possível adiar a criação de gráficos após decidir pelo uso ou não de uma determinada API quando estiver criando games por exemplo.

Resumo do DevMan

A maior parte da literatura sobre Design Patterns aplica os padrões Factory Method e Abstract Factory à bibliotecas gráficas (Motif e Windows) para criação de Widgets como caixas de texto, combos etc. Assim, ao se criar um formulário, pode-se decidir em tempo de execução qual API usar. Isso torna o sistema compatível com diversos padrões de janelas e com diversos sistemas operacionais.

Como no Delphi nós já temos a VCL e o sistema multiplataforma não é o foco desse artigo, esses conceitos serão aplicados tanto à conexão com o banco de dados como à escolha de que tipo de componente usar. Sistemas modernos podem ser configurados com qualquer banco de dados. O tipo de SGBD utilizado nunca deveria ser pré-requisito ou fator decisivo para a implementação de um projeto, já que dados são uma coisa, de propriedade do cliente, e o sistema é outra coisa. Os sistemas não só devem ser flexíveis a ponto de utilizar diversas bases de dados como devem fazê-lo instantaneamente, ou até simultaneamente, integrando sistemas distintos.

Muito se comenta sobre a orientação a objetos e sua importância em aplicações bem estruturadas, flexíveis, robustas e de qualidade. Embora seja sempre comentada, a orientação a objetos ainda não é algo frequentemente utilizado pela comunidade Delphi, porém, esta série de artigos vem abordar um dos principais temas relacionados à POO e padrões de projeto. O intuito de tudo isto é fazer com que o leitor adote a orientação a objetos como uma forma de desenvolvimento cotidiano, fazendo com que qualquer aplicação ou problema seja resolvido de uma forma mais ampla, que permita facilidade de manutenção e poupe menos tempo.

Como já sabemos, os padrões de projeto foram criados para revolucionar a forma de se desenvolver softwares, sendo adotados principalmente no segmento de orientação a objetos. Estudar padrões de projeto não só torna o seu desenvolvimento muito mais produtivo, como também faz com que você possua muito mais interesse em se aprofundar na orientação a objetos e desenvolver softwares que utilizem estas metodologias e conceitos.

Nos artigos anteriores foram explorados muito os padrões Factory Method e Abstract Factory. Lembrando que o Factory Method é um método que se responsabiliza pela criação (e possível configuração ou ligação) de um objeto ou de um grupo de objetos. Ainda comentando sobre a importância da POO em aplicações flexíveis, vimos como o padrão Abstract Factory pode ajudar na flexibilidade do projeto, por postergar a decisão de que famílias de objetos criam para o cliente dos objetos propriamente ditos.

Além de continuar a explorar o padrão Abstract Factory, estudaremos outros padrões como o Singleton (já discutido), Mediator e Adapter, implementando-os como soluções para alguns dos problemas que teremos adiante. Será vista uma forma simples de se implementar um Singleton, e que é uma alternativa elegante, segura e encapsulada para variáveis públicas globais.

Este artigo irá abordar a base para a criação de um sistema multibanco, utilização de métodos de fábrica e fábricas abstratas para criação de objetos de conexão com o banco de dados, configuração da SQL, criação de DataSets corretos de acordo com o tipo, ligação ao Database e configuração dos Providers para que os dados possam ser acessados e modificados.

Note que todas estas operações serão realizadas através da orientação a objetos, utilizando padrões de projeto e com muito pouco código. Veremos como é simples adotar Design Patterns e como eles podem tornar a nossa vida muito mais simples, trazendo enorme flexibilidade e facilidade de expansão de um projeto.

Nota do DevMan

O padrão Singleton é uma convenção para garantir que um e apenas um objeto seja instanciado para cada classe. O padrão Singleton também nos dá um ponto de acesso global, assim como uma variável global, mas sem as desvantagens. Se você atribuir um objeto a uma variável global, esse objeto poderá ser criado quando seu aplicativo for iniciado. E se esse objeto tiver muitos recursos e seu aplicativo nunca acabar de usá-lo? O padrão Singleton é uma das soluções para este problema, pois garante que os nossos objetos sejam criados somente quando necessários. É importante dominar bem os conceitos de variáveis e métodos de classe estática, assim como os modificadores de acesso.

Nota do DevMan

O Mediator é um dos padrões de projeto para desenvolvimento de softwares orientados a objetos. Este permite que haja a “mediação” de um sistema por meio de uma interface. Esse padrão enquadra-se nos padrões comportamentais devido à maneira como ele pode alterar a execução do software. Para entender de uma forma clara, conforme um projeto cresce, suas classes crescem exponencialmente de forma natural, porém, as classes sempre possuem códigos e lógicas distribuídas entre si. Conforme o crescimento destas classes a comunicação entre as mesmas será cada vez mais complexa, havendo uma dependência muito maior entre elas e dificultando na manutenção do projeto. O padrão Mediator vem como sugestão para resolução deste problema, encapsulando a comunicação entre estes objetos e reduzindo a dependência entre si.

Nota do DevMan

Um Wrapper nada mais é que um outro nome dado a um padrão de projeto também conhecido como Adapter. Mais o que seria Adapter? Logo quando está se iniciando no mundo da orientação a objetos, sempre somos levados a pensar de uma forma comparativa ao mundo real, logo, transpondo isto para o mundo real, um adaptador nada mais seria que algo que servisse de “intermediador” parar tornar possível a compatibilidade entre objetos até então incompatíveis. Tratando-se de orientação a objetos em si, imagine que você está dando manutenção a um software já existente e deve criar uma nova classe que se comunique com classes existentes, porém, as interfaces de ambas as classes são diferentes, o que impossibilita essa comunicação “direta”. O padrão Adapter resolve este problema, pois, neste caso seria o “intermediador” encarregado de compreender e tornar possível a comunicação entre elas. Ele nada mais faz do que converter uma interface de uma classe para outra interface que o cliente espera encontrar, fazendo com que interfaces incompatíveis trabalhem juntas.

Nota do DevMan

Outros patterns comumente utilizados em Delphi

Command

O padrão Command faz parte dos padrões de projeto. Seu objetivo é encapsular qualquer ação que venha a ser chamada em um momento futuro. Essa ação torna-se um objeto que pode ser reutilizado, contendo em si a complexidade da chamada da ação original. Ao aplicar esse padrão conseguimos uma flexibilidade maior no sistema, já que para adicionar novas ações (comandos) não há necessidade de se alterar o design do projeto, apenas novos objetos são criados e associados à interatividade do sistema. Apesar dessa vantagem existe uma desvantagem no seu uso. Como seu uso implica na execução de objetos que sua única finalidade é executar uma ação, acabaremos por ter um código que se assemelha muito ao código procedural, orientado aos comandos.

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