Este é um post disponível para assinantes MVP
dê seu feedback
post favorito
Desenvolvimento OO no Delphi XE 2 - Revista ClubeDelphi 137
Da aplicação do desenvolvimento orientado a objetos, seus pilares e boas práticas, utilizando recursos nativos do Delphi XE 2.
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da ClubeDelphi 137
O desenvolvimento orientado a objetos fascina muito desenvolvedor Delphi, mas às vezes por insegurança ou falta de prática mesmo, não o aplica em sua totalidade. Muitos só viram orientação a objetos na faculdade, e em outra linguagem. Ainda existe a situação onde muitos desenvolvedores iniciantes nem se dão conta que um formulário é uma classe que deriva de TForm (classe base de formulários), que um componente TButton é uma classe também e assim por diante.
O Delphi já nasceu orientado a objetos, mas sua natureza RAD acaba escondendo sua estrutura orientada a objetos. É muito mais prático arrastar e soltar do que criar uma estrutura que separe a UI das regras de negócio. A partir do Delphi XE 2 isso começa mudar. Recursos como o LiveBinding tiram do meio do caminho o grande empecilho e desculpa que havia: como vou ligar meus objetos à tela? Agora é possível utilizar classes de negócio (que entenderemos no decorrer do artigo) como fonte de dados reais.
Para se desenvolver um bom software orientado a objetos devem-se seguir algumas boas práticas, estratégias e organização que veremos a seguir e só então partiremos para a construção do exemplo.
Princípios de um
sistema orientado a objetos
Sempre que encontramos um sistema de muita manutenção tentamos resolver seus problemas imaginando que uma melhor coleta de dados junto ao usuário resolva o problema e o sistema se torne mais fácil depois disso. Existem problemas que vão além disso, problemas esses que estão localizados na estrutura do projeto. Existe um fato único que não muda: requisitos de sistema sempre mudam. Assim, é melhor preparar o desenvolvimento para isso, melhorar a coleta de informações ajuda, mas não resolve. O desenvolvedor deve criar o pensamento de “como escrever um código que se adapte fácil e rapidamente às mudanças que os clientes solicitam”. Para ajudar, existem alguns princípios: Modelar para interfaces, favorecer composição sobre herança e encontrar o que varia, e encapsulá-lo.
Modelar 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, podem-se utilizar 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, ou o tipo interface mesmo que oferece vantagens como possuir um contador de referências que, evita falhas no gerenciamento de memória.
Favorecendo composição sobre herança
Em sistemas orientados a objeto, para se conseguir
reutilização de funcionalidades, são utilizadas duas técnicas em especial:
herança e composição. A herança permite que o interior de uma classe base seja
vista pelas suas subclasses, isso caracteriza a herança como uma técnica white box, ou “caixa branca”.
A composição concede reutilizações mais complexas e exige
que os objetos envolvidos possuam interfaces bem elaboradas. Quando a
composição é utilizada em alternativa à herança, o interior dos objetos não
fica visível entre si e devido a isso é caracterizada como black box, ou “caixa preta”.
ATENÇÃO! A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVP
Space do autor
0
0
