Showing posts with label Delegates. Show all posts
Showing posts with label Delegates. Show all posts

Sunday, September 21, 2008

[.NET vs Java] Event Handling: Are you sure pure OOP is always the simplest?


After a long time I'm again here for another post!
I will talk about event handling, focusing at first on .NET way to supply it, and then spending 2 words about the Java style.
What I want to talk about is delegates and how are they used...I know old good Giovacchia has already spoken about them in a previous post (here) but I wanna talk about them again.
Why?
I'm leaving for a while the Java world and walking through the .NET Framework (I have to take some Microsoft Certifications, 2 or maybe 3 exams in just 1 month and a half...sounds crazy but it's my task in the short term): this means I have to study, as for now, 2 book of about 1000 pages each one.
I'm not taking part in the war between Open Source Multi Platforms Java Conding and Mama Microsoft Windows-Platform Framework yet, but in this path toward the MS certifications I will try to catch what's good and what's not in both frameworks.
At a first sight (I'm about at the half of the first book) 2 years of experience in Java programming has helped me a lot, but I stopped a while learning about delegates.
I don't want to explain what actually they are (Giovacchia in his post said it perfectly), let's just say delegates are a kind of function pointers, and you have to subscribe a delegate to a particular event in order to make it running when that event is raised.
Because my memory is so short term (could it be Google's fault?), during the reading I made a simple schema to remember which key words to use when declaring a delegate and rasing your own event.


namespace HereIsMyDelegateNamespace{
. . .

public delegate void MyEventHandler(object o, System.EventArgs ev);

. . .

public class MyClass{
. . .
public event MyEventHandler MyEvent;
. . .

/* this method raises an event */
publlic ReturnType RaisingMethod()
{
System.EventArgs ev = new System.EventArgs();
. . .
MyEvent(this,ev);
. . .
}
}
}

namespace ConsumerNamespace{

public class Consumer{

public static void Main(string[] args)
{
. . .
MyClass m = new MyClass();
m.MyEvent += MyEventHandler(m_MyEvent);
. . .
/* from now on we can call a method
* or make an action which causes MyClass to
* raise the MyEvent event */

m.SomeMethodThatRaisesTheEvent();
. . .
}

public static void m_MyEvent(object o, System.EventArgs ev)
{
. . .
/* handles the event */
}
}

}


You have to remember few things:


  • The signature of the delegate has to be the same of your own handling method

  • The signature of the delagete has to contain 2 parameters: the first one is an object reference, that refers to the object that launches the event, and the second one must be a subclass of System.EventArgs (there are a lots of them implemented for the common events)

  • You can subscribe to an event using the overloaded operator += but you can also unsubscribe by using the -=

  • For common applications, you won't need to raise yourself an event, but just supply a method and subscribe it to the event (the method, as said, has to have the same signature of the needed delegate)


And what about Java?
Learning Java I actually never had the need to write down some code to remember how Event Handling works.
Why? There are no delegates, in the sense you need to specify an entire class as the delegate for that event. What does it happen when you need to subscribe to an event?
In that situation Java is more OO then .NET, indeed you only use your Handler Class (such as MouseListener class, but for the common events, e.g. such as Mouse and Keyboard, you have at your disposal tons of ready-to-use classes) to manage the event. In this scenario you call directly by the object that throws the event, an addXXXListener() or removeXXXListener(), and inside your class, in which you surely have an array of potential listeners, when you want to raise the event, you have to iterate manually by calling all the needed methods of the listeners subscribed.
IMHO Java is straightforward to the OOP, but you need more code, and .NET allow you by using delegate and event keywords not to think to the propagation of the event. Moreover, in .NET you won't need to specify an entire class to handle the event, bringing to a more concise code style.

I'm not as experienced in .NET as I'm in Java, so maybe in few weeks I will post the exact opposite kind of opinion, but as for now I'm feeling better using C#, as it seems it has taken the good in Java and brought it to a more powerfull level (I'm refering to the whole framework ofcourse and not to the language itself).


kick it on DotNetKicks.com

Thursday, January 3, 2008

[.NET] Events and Delegates

Lately I've been reflecting about Events and delegates in the .NET framework: to my understanding event is actually not a type, just a keyword.

Quoting from MSDN:

The event keyword lets you specify a delegate that will be called upon the
occurrence of some "event" in your code. The delegate can have one or more
associated methods that will be called when your code indicates that the event
has occurred.


You can specify your own events, but in order to specify events and handle them you should:
//1) declare a delegate:
public delegate void myEventHandler(object sender, AlarmEventArgs e);
//2) "declare" an event on your delegate
//(read the first sentence from the quote now):
public event myEventHandler myEvent;
//3)Wire event and SomeMethod through the event delegate
//(At some initialization stage)

myControl.myEvent += new myEventHandler(SomeMethod);

You can do this without explictly declaring a delegate and event if you are using .NET built in controls, because they already have their own events and delegates (EventHandler - which uses a generic System.EventHandler delegate) declared so you can just wire an event to SomeMethod using the generic delegate called EventHandler, like this:

button.Click += new EventHandler(this.Button_Clicked);

Where button is the name of the control, Click is the event and Button_Clicked is the name of your method.

This stuff is not-so-easy-to-catch, so hope it might help someone.