Artigo Clube Delphi 72 - Criação de Componentes

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (1)  (0)

Artigo da Revista Clube Delphi Edição 72.

Esse artigo faz parte da revista Clube Delphi Edição 72. Clique aqui para ler todos os artigos desta edição

Atenção: por essa edição ser muito antiga não há arquivo pdf para download deste artigo.

POO

Criação de Componentes

Aprenda definitivamente como criar componentes e formulários em runtime

 

Como membro ativo do fórum da ClubeDelphi (www.clubedelphi.net/forum), tenho notado que muitos desenvolvedores ainda não sabem criar objetos (e conseqüentemente, componentes) corretamente em run-time, introduzindo direta ou indiretamente memory leaks (veja próxima seção) em suas aplicações. Constatando essa carência na comunidade Delphi, decidi escrever este artigo para mostrar como manipular objetos em memória da maneira certa e elegante.

 

Memory leaks

Instanciar um objeto na memória do computador consome certa quantidade de bytes do total disponível (já subtraído o valor utilizado pelo sistema operacional, é claro). Quando não houver mais memória para se utilizar, a máquina irá parar de responder e eventualmente o SO irá (tentar) fechar aplicações críticas, isso é, que estão consumindo recursos em excesso.

Para evitar que isso ocorra, precisamos destruir tudo que criamos e que consome memória no nosso aplicativo. Quando esquecemos de liberar algo, estamos deixando que um memory leak aconteça, ou em português, um vazamento de memória.

 

Memory leaks no .NET

Quem conhece a arquitetura do .NET framework, sabe que uma de suas características é a existência de um Garbage Collector, responsável por liberar automaticamente todas as instâncias de objetos da memória, no melhor momento possível definido por ele. Isso significa que memory leaks não existem no .NET, certo? Mais ou menos.

Existem resource leaks, que ocorrem quando abrimos uma conexão com um banco de dados, por exemplo, e não a fechamos quando não precisamos mais usá-la. Esses recursos externos à aplicação são chamados no .NET de unmanaged resources.

Embora o Garbage Collector do framework saiba quando recursos não-gerenciados devem ser liberados da memória, ele não tem conhecimento de como fazer isso. Por essa razão, qualquer classe nessa situação deve implementar a interface IDisposable, publicando seu método Dispose e codificando-o para devolver à memória do computador o que estava sendo utilizado.

Mas antes de modificar seus projetos, atente para esse detalhe: no Delphi for .NET, todas as classes implementam implicitamente IDisposable, e redirecionam as chamadas à Dispose automaticamente para o destrutor da classe, Destroy. Isso quer dizer seu código continua o mesmo. Sequer é preciso chamar Dispose, pois Free, no Delphi for .NET, já faz isso por você. Para saber mais sobre esse assunto, confira a seção "

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?