Delphi e Orientação a Objetos
Autor: Geek on the beach | Publicado: 2012-02-01T01:35:00-02:00

Introdução&nbsp;

Isso é um assunto um tanto quanto polemico mesmo nos dias atuais, o fato é que o Delphi desde de sua versão 3 (Delphi 3), possui orientação a objeto baseada em object pascal.


OO no Delphi

É um pouco complicado dizer de fato porque nem todo mundo utiliza OO no Delphi, sendo que desde de seus primórdios é possível fazer isso, se eu pudesse resumir tudo em motivo, acredito que seja o fato do ambiente RAD proporcional um velocidade de desenvolvimento inicial muito superior a soluções OO, apesar que mesmo utilizando de RAD e drag and drop, implicitamente o Delphi utiliza OO para controle dos forms, mas não se confunda, isso é para controle interno.

RAD e OO

É uma tarefa difícil e um pouco desgastante chegar em um denominador comum sobre esses dois estilos, implicitamente o Delphi é praticamente 100% orientado a objeto, mas é complexo desenvolver sistemas comerciais utilizando OO de forma pura, afinal RAD é muito mais pratico, e isso que torna o Delphi uma ferramenta fantástica, afinal tempo é dinheiro no mundo dos negócios. 

Porem não se assuste, existem maneiras de fazer isso, o segredo do negocio é não reinventar a roda, não adianta abandonar o desenvolvimento RAD, a ideia é encontrar um equilíbrio perfeito entre RAD e OO.

Conciliando RAD e OO

O maior problema quando falamos de orientação a objetos no Delphi, é que em tese perdemos nossos componentes "Data Controls" e definitivamente isso não é bom, utilizar Delphi, e não utilizar "Data Controls" é andar para trás, muito se escuta sobre substituir DBEdits por Edits comum e fazer o preenchimento manual dessas considerando as propriedades das classes criadas, eu posso afirmar que esse não é o caminho, durante muito tempo pensei a respeito e percebi que se adota-se tal pratica o ganho com OO seria equivalente a perda de produtividade devido o abandono de tais componentes, seja em manutenção e/ou desenvolvimento, para explicar de forma mais clara, eu divide a utilização de OO no Delphi, em 7 formas, que julgo ser os níveis de casamento entre o desenvolvimento RAD e Orientação a Objetos.


1- (Padrão Simples) Orientação a Objetos sem a utilização de Data Controls
2- (Padrão Melhorado) Orientação a Objetos com utilização de Data Controls, porém com preenchimento de registros de classes de forma rudimentar.
3- (Padrão Bem Definido) Orientação a Objetos com utilização de Data Controls e desvinculação do papel da classe e do banco.
4- (Padrão Bem Estruturado e Definido) Orientação a Objetos com utilização de Data Controls, desvinculação de papeis e utilização de design pattern (MVC)
5- (Padrão Bem Estruturado, Definido e Organizado) Orientação a Objetos com utilização de Data Controls, desvinculação de papeis, utilização de MVC e utilização de chamadas a métodos de aquisição de registro através de camadas de acesso a banco.
6- (Padrão Perfeito) Orientação a Objetos com utilização de Data Controls, desvinculação de papeis, utilização de MVC (Melhorado), utilização de camadas físicas de separação e chamada de métodos na camada factory no servidor para aquisição dos registros
7- (Padrão Mais que Perfeito) É basicamente a implementação de tudo relativo ao sexto padrão, com a utilização de orientação a aspecto para maior abstração das camadas do MVC melhorado.

Ao longo do tempo, eu vou entrar em mais detalhes com relação a cada nível de conciliação, mostrando exemplos práticos, sendo o ultimo o nível 7 o meu favorito, a primeira coisa que vocês iram observar e quanto maior o nível de conciliação melhor definidas são as funções de cada camada, maior o tempo de desenvolvimento inicial e menor o tempo de manutenção, eu costumo dizer que sistema desenvolvimento utilizando o nível 7 seguem a seguinte regra, os primeiros são demorados os próximos são desenvolvidos a kilo.

Desenvolvimento Inicial X Manutenção

A primeira coisa que devemos ter em mente é que o objetivo de conciliar o ambiente RAD e OO, trás como beneficio principal um código limpo, fácil, bem definido e principalmente simples de se efetuar manutenção, cada gota de suor despendida no desenvolvimento inicial (Muito comumente apelidado de "Burst") é recompensada posteriormente nos próximos "Burst' s" e na manutenção do sistema.

A segunda coisa e provável a mais significativa (Sim isso mesmo, organização é somente um dos ganhos) é que quanto maior o nível de conciliação, maior é a capacidade de escano labilidade do sistema, uma conciliação de nível 7, provê distribuição massiva do sistema em dezenas de milhares de terminais assim como a integração de praticamente qualquer linguagem, você deixa de lado o paradigma da OO para algo mais abstrato, chegando próximo do desenvolvimento orientado a serviço, com a diferença disso vir de forma implícita ao desenvolvimento mesmo não sendo o objetivo da sua produção.

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Pera ai, para tudo como assim?

De fato parece até mentiroso, mas a verdade, é que você cria um sistema distribuível, de forma implícita apesar do seu objetivo não ser esse, a utilização do ultimo nível 7, implica em um sistema facilmente integrável com outras linguagens e principalmente extremamente abstrato, não é necessário para os outros saberem como o sistema faz, mas sim que ele faz e isto é suficiente. A ideia por trás desse objetivo é criar um produto que seja abstrato até mesmo para o desenvolvedor, ai que entra a etapa de desvincular papeis.

Nos próximos posts, eu irei abordar um pouco sobre MVC, Singleton e alguns outros Design Patterns, eles são necessários para nossa introdução aos níveis de conciliação entre o desenvolvimento RAD e OO, também irei mostrar um pouco de orientação a objeto e boas praticas, coisas como construir uma classe, como abstrair a questão de herança e utilização pratica do polimorfismo e alguns outros assuntos interessantes.

Até a próxima