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

[...] continue lendo...

Design Patterns - Parte 3 - Artigo Clube Delphi 124

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.

Artigos relacionados