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

Why is the Single Responsability Principle important?

The Single Responsability Principle is one of the five S.O.L.I.D. principles in which i base my everyday programming. It tells us how a method or class should have only one responsability. Not a long time ago i was designing a reporting service with my colleague Nuno for an application module we were redoing and we had a method that was responsible for being both the factory method of a popup view and showing it to the user. You can see where this is going now... I figured out it would not be a that bad violation of the principle, so we moved on with this design. The method was called something like "ShowPrintPopup" and it took an IReport as an argument. All this was fine, but then we got to a point where we needed to have a permissions system to say if the user was able to export the report to Excel, Word, PDF, etc... The problem was the print popup would need to know beforehand if it would allow the user to export the report or not, so that it could show it's UI a...

From crappy to happy - refactoring untestable code - an introduction

I started testing my code automatically a couple of years in after starting my career. Working in a small company, there weren't really incentives for us to automate testing and we were not following any kind of best practices. Our way of working was to write the code, test it manually and then just Release It ™ , preferably on a Friday of course. I'm sure everyone can relate to this at some point in their career, because this is a lot more common than the Almighty Programming Gods of the Internet make us believe. I find that the amount of companies that actually bother writing tests for their production code is a fraction of the whole universe. I know some friends who work in pretty big companies with big names in the industry and even there the same mindset exists. Of course, at some point in time our code turned into a big pile of shit . Nobody really knew what was going on and where. We had quantum-level switcheroo that nobody really wanted to touch, and I suspect it i...

From crappy to happy - dependency what, now?

Following the introduction on this series on a previous post, we will now talk about dependency injection and how it has the effect of allowing for more testable code. Sometimes when I talk about this concept it is difficult to explain the effect that applying it might have on the tests. For that reason I think it is better to demonstrate with a near-real-world situation. Obviously, keep in mind this is not real code, so don't worry about the design or implementation details that don't contribute to the point being discussed. The code As you can see, it is simple. There's a class called ShipManager (what else?) that receives position updates for the ships. It keeps the last position reported from each ship and does some calculation to see how much the ship moved. It assigns some values to the update and finally it persists the final version of the update. How do we start testing? When you think about it, tests are dead simple. A test either passes or it doesn...