Skip to main content

C# 2.0 - Métodos Anónimos

Vamos voltar às minhas traduções dos artigos sobre a evolução do C#.

Todos estamos familiarizados por esta altura com o que é um delegate, correto? Os delegates são uma parte muito importante do sistema de eventos no .NET. Basicamente, registamos um método (chamado handler) num delegate que irá ser chamado quando evento é invocado. Por outras palavras, um delegate simplesmente aponta para um método. É um apontador que tem as vantagens de type safety e da abstração de alto nível. A grande vantagem é que um delegate é um objecto que contém informação sobre como chamar um método, e traz-nos todas as vantagens da utilização de objectos, como por exemplo a capacidade de o passar por parâmetro. Vamos ver:

Esta é uma forma de utilizar os delegates dos eventos.  Uma qualquer classe expõe o evento e nós registamos o método no seu delegate. Quando o delegate é invocado, todos os métodos registados serão também chamados. O facto de termos vários métodos registados indica que este é um multicast delegate. O compilador assegura-se que apenas métodos compatíveis com o delegate possam ser registados e dispara um erro quando há incompatibilidade.

No exemplo precisámos de declarar dois métodos que apenas executavam um Console.WriteLine. Não serão demasiadas formalidades? Na minha opinião ter que declarar todo um método para encapsular uma linha de código é uma complexidade desnecessária. O que podemos fazer nesta situação é utilizar os Métodos Anónimos do C#2.0. Com esta melhoria torna-se possível escrever o seguinte código:

Claramente conseguimos ver uma diferença. Apenas usámos um método anónimo  para registar no delegate e nunca precisámos de declarar o corpo dos métodos. Claro que a assinatura (tipo de return e parâmetros) do método anónimo ainda precisa de respeitar o delegate, e o compilador está do nosso lado nesse aspecto. Podemos passar os parâmetros dentro da chamada à palavra delegate() , tal como faríamos num método normal.

Delegates são úteis para maximizar o reaproveitamento e manter o código simples. Métodos anónimos são apenas uma facilidade sintáctica para ajudar o programador quando parece demasiado declarar um método inteiro apenas para um delegate. Utilizo bastante para por exemplo registar handlers para eventos que apenas chamam um método, em WinForms, mantendo assim o código todo visível no ecrã.

Este é apenas um passo no caminho para uma feature maior, como vamos descobrir no C# 3.0. Entre as principais vantagens da utilização de métodos anónimos está o facto de podermos definir o seu comportamento numa única linha, mas isto também pode promover métodos longos e diminuir a sua legibilidade, quando mal utilizado. Como tudo, tem que ser utilizado com peso e medida.

Até breve!

Comments

Popular posts from this blog

The repository's repository

Ever since I started delving into architecture,  and specifically service oriented architecture, there has been one matter where opinions get divided. Let me state the problem first, and then take a look at both sides of the barricade. Given that your service layer needs to access persistent storage, how do you model that layer? It is almost common knowledge what to do here: use the Repository design pattern. So we look at the pattern and decide that it seems simple enough! Let's implement the shit out of it! Now, let's say that you will use an ORM - here comes trouble. Specifically we're using EF, but we could be talking about NHibernate or really any other. The real divisive theme is this question: should you be using the repository pattern at all when you use an ORM? I'll flat out say it: I don't think you should... except with good reason. So, sharpen your swords, pray to your gods and come with me to fight this war... or maybe stay in the couch? ...

Follow up: improving the Result type from feedback

This post is a follow up on the previous post. It presents an approach on how to return values from a method. I got some great feedback both good and bad from other people, and with that I will present now the updated code taking that feedback into account. Here is the original: And the modified version: Following is some of the most important feedback which led to this. Make it an immutable struct This was a useful one. I can't say that I have ever found a problem with having the Result type as a class, but that is just a matter of scale. The point of this is that now we avoid allocating memory in high usage scenarios. This was a problem of scale, easily solvable. Return a tuple instead of using a dedicated Result type The initial implementation comes from a long time ago, when C# did not have (good) support for tuples and deconstruction wasn't heard of. You would have to deal with the Tuple type, which was a bit of a hassle. I feel it would complicate the ...

C# 2.0 - Partial Types

For those of you interested, i found a very interesting list of features that were introduced in C# in  here . This is a very complete list that contains all the features, and i'm explaining them one by one in this post series. We've talked about  Generics  and  Iterators . Now it's time for some partial types . A partial type  is a type which definition is spread across one or more files. It doesn't have to be in multiple separated files, but can be. This is a very simple concept that can give us many benefits, let's see: If a type is partial, multiple developers can work on every part of it. This allows a more organized way of working and can lead to production improvement.  Winforms , for example, generates a partial class for the form so that the client can separately edit other parts it. This way, a part contains information about the design and the other contains the logic of the form. In fact, this is a very spread pattern across .Net. Ent...