Curso de Delphi Prism – Parte 2
Novidades da Linguagem – Métodos Anônimos e Delegates
Na primeira parte deste curso, vimos um pouco da história do suporte do Delphi ao .NET Framework. Examinamos o que considero serem as principais novidades da linguagem do Prism, como variáveis in-line (onde você pode declarar variáveis e objetos dentro do código, e não só na sessão var) e também o recurso de type-inference, onde é possível omitir o tipo da variável, usando mesmo assim, objetos fortemente tipados. Também vimos que é possível inicializar variáveis locais e usar type-inference na sessão var, sem recorrer a recursos não muito atraentes à programação orientada a objetos.
Neste artigo, vamos conhecer os métodos anônimos, que como o próprio nome do recurso sugere, são métodos que não têm nome. Esse é um recurso que possui uma íntima relação com eventos (e delegates, visto também neste artigo). Novamente peço para que você abra sua mente, deixe de ser um seguidor fiel do Niklaus Wirth e dê um passo rumo ao futuro.
Métodos Anônimos
Como de costume, para entendermos o presente e futuro, vamos analisar o passado, como funcionavam as coisas no mundo Delphi 7 Win32.
Em um formulário TForm do Delphi, quando adicionamos um manipulador para um evento de um controle de tela (Button, Edit, DBGrid), ou mesmo um componente não-visual (ClientDataSet, Timer, SQLConnection), estamos nada mais nada menos que apontando uma propriedade para um método. De fato, um evento é ponteiro para um método de uma classe, e também tem um tipo, como TNotifyEvent, principal tipo de evento da VCL do Delphi.
Por exemplo, na classe TControl, encontramos a definição do evento OnClick, que serve de base para muitas outras classes que herdam o evento, como um TButton. Observe o código da Listagem 1. A declaração do evento funciona exatamente como uma propriedade normal, possui uma variável privada que é mapeada por métodos Get e Set. Só que, ao invés de atribuirmos um valor para essa propriedade, como um objeto, uma string, um inteiro, apontamos para um método, que no Win32, obrigatoriamente deve ser um método de uma classe, functions rotinas e procedures fora desse escopo não funcionam (no Delphi for .NET do BDS funciona, pois units viram classes nos bastidores).
Listagem 1. Declaração do evento OnClick em TControl
TControl = class(TComponent)
...
FOnClick: TNotifyEvent;
...
property OnClick: TNotifyEvent
read FOnClick write FOnClick stored IsOnClickStored;
Se colocarmos um Button em um formulário e dermos um duplo clique nele, o IDE vai automaticamente criar um manipulador para o seu evento padrão, que no caso de um botão, é o OnClick. Então, implementamos o método. O código para isso pode ser observado na Listagem 2. Coloquei nessa listagem também a declaração da classe na sessão Type. Veja que o método Button1Click é declarado logo abaixo de TForm, depois do Button, e não possui um especificador de visibilidade como public ou private. Como TForm descende de TPersistent, classe que ativa a diretiva {$M+}, o compilador ativa a RTTI (Runtime type Type Information) e consegue ler do arquivo DFM a atribuição do evento antes de chamar o importante método virtual Loaded de TComponent. Por isso, por padrão, classes que descendem de TPersistent e não declaram o especificador para um método ou objeto (como no exemplo), automaticamente usam o modificador published para esses membros. Esse é um prerequisito para um método funcionar, experimente mover Button1Click para o private e você verá o que estou querendo dizer. Na Listagem 3, veja o fragmento de código do DFM que representa essa atribuição.
Listagem 2. Funcionamento de um evento
TForm1 = class(TForm)
Button1: TButton;
procedure Button1Click(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
...
