Artigos .NET C# Orientado a Eventos - Delegates e Eventos - Revista .Net Magazine 99
Demais posts desta série:
C# Orientado a Eventos - Delegates e Eventos - Parte 2
Artigo no estilo: Curso

De que se trata o artigo

Vindo desde a primeira versão do Framework, o delegate tem como principal objetivo encapsular a chamada de métodos, além de facilitar a reutilização deste tipo de operação. O artigo trata do uso de delegates, mostrando desde o seu funcionamento até o uso de eventos.


Em que situação o tema é útil

O paradigma de programação orientado a eventos é largamente utilizado em interfaces (como formulários, botões, caixas de texto) e em arquiteturas de jogos, onde eventos desencadeiam outros eventos. Atualmente muitas ferramentas se utilizam deste paradigma para facilitarem o fluxo de codificação de uma aplicação, a exemplo: Linq, Entity Framework, NHibernate, Quartz, etc. Neste artigo, o leitor irá entender como funcionam as bases da programação orientada a eventos, que são os events e delegates, a fim de dar seu primeiro grande passo na codificação de aplicações mais dinâmicas.

C# Orientado a Eventos –Delegates e Events

Neste artigo iremos mostrar um recurso muito pouco explorado, mas bastante presente no C# em bibliotecas oficiais e não oficiais, que agiliza bastante o desenvolvimento de software. Por intermédio da comparação de delegates com interfaces, introduziremos uma forma prática de como desenvolver uma pequena aplicação orientada a eventos, apresentando ao leitor como funcionam os “events” em uma aplicação C#.

Em linguagens de programação modernas é recorrente o paradigma Orientação a Objetos. No entanto, quando tratamos deste assunto logo nos vem à mente a palavra class. Properties e Fields também são lembrados, visto que seus tipos também são classes.

Em muitos momentos da codificação o desenvolvedor é levado a pensar na possibilidade de encapsular suas funções em padrões determinados pela equipe, a fim de facilitar o desenvolvimento de aplicações simples.

As primeiras tentativas de tipificação de funções surgiram com as linguagens de terceira geração (PL/I, COBOL, Fortran 2003...), mas ganharam maior expressividade nas linguagens orientadas a objeto C++ e D (Nota do DevMan 1), quando essas introduziram o chamado function pointer (Nota do DevMan 2).

Nota do DevMan 1

A linguagem D foi projetada por Walter Bright em 1999 e originalmente criada para ser uma sucessora da linguagem C++, combinando alto desempenho com uma maior produtividade. Esta linguagem é fortemente tipada estaticamente, compilada para código nativo e multiparadigma.

Nota do DevMan 2

Function pointer é um tipo de ponteiro que, ao invés de referenciar valores de dados, aponta para um código executável na memória do computador. A partir de então ele é utilizado para invocar a função para a qual ele aponta, passando assim os parâmetros requeridos.

Tendo em vista a necessidade de apontar funções através de variáveis, o PHP introduziu as chamadas Funções Variáveis, permitindo que o programador passe o nome da função como parâmetro para outra função. Porém não temos como encapsular estas variáveis em tipos pré-definidos.

Também na tentativa de criar uma estrutura mais orientada a objetos, o Java expõe uma interface chamada ActionListener (Nota do DevMan 3), mas ainda assim não conseguimos ter uma noção direta de um objeto mais fortemente definido em um tipo de contrato de classes.

Nota do DevMan 3

ActionListener, em Java, é uma interface que serve para encapsular eventos de ação (click do botão, fechamento do formulário, dentre outras) bastante presentes em programação web, de desktop e de jogos.

Quando o C# foi criado, a ideia de métodos poderem ser encapsulados foi bastante pensada ao ponto que, além dos tipos básicos de objetos (class, interface, struct), temos um objeto chamado delegate, que é responsável por encapsular funções ou métodos.

Delegates

Imagine, por exemplo, um carro que contém um modelo e a possibilidade de iniciar uma viagem, conforme mostrado na Listagem 1. Para este contexto estamos definindo uma propriedade e um método para uma classe do tipo Carro. O veículo, por sua vez, pode ser colecionado e iterado de acordo com o fluxo de desenvolvimento. Este comportamento orientado a objetos é muito comum no C#, tanto em classes e interfaces como structs (int, log, DateTime).

Listagem 1. Classe carro e sua implementação.


1      public class Carro
2      {
3          public string Modelo { get; set; }
4  
5          public void IniciarViagem(int distancia)
6          {
7          }
8      }
9      static void ManipularCarro()
10     {
11        IList<Carro> carros = new List<Carro>();
12  
13        Carro carro = new Carro();
14        carro.Modelo = "Ferrari";
15        carros.Add(carro);
16  
17        foreach (Carro c in carros)
18        {
19            c.IniciarViagem(200);
20        }
21     }

Quando o padrão Orientado a Objetos foi criado, surgiram diversas metodologias de reaproveitamento de código, dentre elas destaco a frase “Programe para a interface e não para a implementação”. Pensando nesta abordagem, os analistas de sistema procuram extrair padrões de comportamento iguais a partir de objetos semelhantes. Baseado neste cenário, tomando como premissa o nosso exemplo, temos a propriedade Modelo e o método IniciarViagem, que pertencem a qualquer tipo de automóvel, e não necessariamente só à classe Carro.

Veja na Listagem 2 que extraímos as características e comportamentos comuns a Carros, Caminhões, Carretas, Motocicletas. Deste modo, vamos melhorar nossa classe Carro dizendo que ela implementa a interface IAutomovel.

Listagem 2. Criação da interface IAutomovel


1      public interface IAutomovel
2      {
3          string Modelo { get; set; }
4          void IniciarViagem(int distancia);
5      }

Após analisarmos a ...

Quer ler esse conteúdo completo? Tenha acesso completo