Artigos Delphi Artigo Clube Delphi 67 - Padrões de Projeto e POO

gem_artigo' alt="" src="/loja/img/capaCLUBE67_G.jpg" align="baseline" border="0" hspace="0">

Padrões de Projeto e POO

Parte I - Preparando-se para mudanças

 

Com o advento do .NET, muitos desenvolvedores Delphi têm se deparado com um novo paradigma, um novo conceito, imposto pela arquitetura .NET, a Orientação a Objetos, tema abordado nesta edição. Isso não deveria ser nenhuma novidade para os “Delphianos”, já que o Delphi nasceu orientado a objetos, porém essa não é a realidade que encontramos.

Tenho visto grandes esforços de grupos em divulgar conceitos e uso de ferramentas para a programação Orientada a Objetos, e o que venho apresentar não é nenhuma novidade. Os padrões de projeto (Design Patterns) surgiram de estudos na área de arquitetura civil e foram posteriormente aplicados na área de análise e desenvolvimento de software, sendo considerados como boa prática.

Não quero aqui promover um longo histórico sobre eles, vamos partir para seus conceitos que podem ser aplicados em qualquer análise e desenvolvimento OO, mostrando de forma prática e real seu uso, vantagens e desvantagens.

 

Definindo padrões de projeto

Segundo Martin Fowler, “um padrão é uma idéia que tem sido útil em um contexto prático e que provavelmente será útil em outros”, ou seja, é uma solução já testada para problemas de modelagem que acontecem sempre. Talvez quem não utilize a Orientação a Objetos na prática está se perguntando agora que problemas são esses. Durante esta série de artigos esses problemas serão apresentados juntamente com as respectivas soluções.

 

Princípios

Quando nos deparamos com um sistema que é de difícil manutenção, perguntamos onde está o problema? Talvez por nossa “herança estruturada” somos levados a pensar que a falha foi na coleta dos dados, e que melhorando essa obtenção dos usuários, o sistema se torne mais fácil de manter.

Existe uma verdade única, os requisitos sempre tendem a mudar. O usuário sempre desejará algo novo, algo que acompanhe as mudanças de sua regra de negócio, portanto, melhores técnicas de coleta de informações podem ajudar, mas não resolvem o problema.

É nisso que a visão dos padrões podem ajudar, o foco passa de “como coletar de forma melhor os dados” para “como escrever meu código de tal forma que se adapte bem à constante mudança de requisitos”.

Existem alguns princípios de modelagem e programação OO que levam os padrões de projetos a serem considerados como boas práticas, esses mesmos conceitos podem ser aplicados sem a utilização dos padrões. Portando, a idéia é entender esses princípios e procurar aplicá-los em nosso desenvolvimento. São eles: Modelar para interfaces, favorecer composição sobre herança e encontrar o que varia, e encapsulá-lo.

 

Modelando para interfaces

Existem dois problemas que impedem um sistema de ser facilmente alterado quando há uma mudança em seus requisitos: baixa coesão e alto acoplamento.

 

. Baixa coesão: Isso é detectado quando encontramos rotinas/classes que realizam várias funções e essas são dependentes entre si, ou seja, é o quanto as operações de uma rotina/classe dependem de outras;

 

. Alto acoplamento: Encontramos um alto acoplamento quando temos rotinas/classes que são muito dependentes de outras, aonde um alteração nessa conduz a um cascateamento de alterações, ou seja, é o quanto as rotinas/classes estão dependentes uma das outras.

 

Para amenizar, ou evitar esses problemas, pode-se aplicar o conceito de modelar para interfaces. Interface aqui não é a interface gráfica com o usuário do seu sistema, e sim o conjunto de operações, propriedades e atributos que compõe uma determinada classe.

É através de sua interface que uma classe se faz conhecida e interage com outras classes. Para aplicar esse conceito, é sugerido que heranças iniciem a partir de classes abstratas, que nada mais são do que interface pura, já que seus métodos são implementados por seus descendentes.

Para entender isso melhor, façamos um pequeno exemplo que mostra essa idéia que poderá ser utilizada em seus sistemas. Esse exemplo utiliza Firebird 1.5 e Delphi 7. Nele vamos fazer duas consultas diferentes utilizando um único formulário, porém esse formulário não saberá qual consulta que está em uso. Vamos abstrair o conceito de “consulta” e encapsularemos em duas classes distintas, chamadas: TConsultaCliente e TConsultaFuncionario ...

Quer ler esse conteúdo completo? Tenha acesso completo