When you write .NET code that takes callback parameters, your first instinct may be to use delegates, but it may not occur to you that you can use an interface instead. Learn why and when an interface may be a better answer.
Delegates vs. Interfaces in .NET
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
At least C# gives you the choice of using an interface or a delegate for your callbacks, unlike another well known language. I find delegates also leads to less clutter in your code.
Something about adapter classes with empty methods derived from interfaces doesn’t sit well with me.
I think delegates should be used in all but the most specialized scenarios. The reason .NET has delegates is that it frees the code from all of the anonymous adapter classes thet plague Java. (However, I do wish .NET had anonymous classes, because there are times when they are really handy, bust most of the time they are overkill and clutter.)
Delegates are much more convenient and easy to use than interfaces. And they are as fast as interfaces in .NET 2.0. Delegates also support multicast without much work.
The whole point of callbacks is that they should allow for loose coupling. Interfaces place a larger burden on the callback consumer and lead to tighter coupling.
The author does not even know delegates very well:
“Conversely, you can not go from a delegate to the instances it will call, or to any other methods those instances may support.”
This is wrong. You can get the target by using the Target (duh) property of the delegate.
So the only reason to use an interface is when there are a bunch of related methods that *must* all be implemented in a consistent manner.
If you were to use delegates in this case, the user would have to look up the requirement in the docs. With an interface you make it explicit.
But this does not happen very often.
To summarize: bad article from a guy who wants C# to be java.
You don’t know what .NET is? Its the same as with java. There is the java language, the java VM and the java class libraries. Combined they are the java platform.
In .NET it is the same. First there is the runtime with the base libraries that define the type system. Then there are a bunch of languages targetting the runtime. And then there are the framework class libraries. Together they are the .NET platform.
But I guess you were not looking for an explanation, but just wanted to bash .NET even though you obviously do not know it very well.
Lemme guess what’s the technology you know..hum..would it be Java?
I know Java.
I’m just frustrated coz I’m forced to work with .NET and by now DontGetIt. Maybe it’s a holly graal, but my question is still valid what is it?
I understand
JVM = CLR
Bytecode = IL
Some (!)API ARE implemented (JDBC ~ ADO.NET)
Where is J2EE???
In Java I have VM and J2SE over it (implemented in JAVA language). Then I have J2EE implemented over J2SE (don’t mention J2ME – it’s apart).
In .NET I have CLR, then some wrapper API for it to connect to Windows (ADO.NET, WinForms) which I can use from C#. Next We have IIS and MSSQL Server (which M$ put inside .NET framework!) We have COM+ (isn’t it Windows technology) We have MTS. As JNDI for COM+ Windows Registry is using (?). So what is a value of VM if all API are deadly mapped to Windows??? And again the only thing that is a standard is VM/C#. The rest is patented.
Again where can I find a good chart about .NET architecture?
Not some stupid picture where we have ADO.NET on top of WebServices or vice versa.
You can find the structure of J2EE in almost ANY book about it with ALL Servlet/JSP/JSTL/Struts/JSF… JNDI/JMX/JCA/JTS… EJB/JDO/JDBC etc… etc…
Does .NET has 5% of what Java has or I miss something?
And Java is FREE, Portable, Mature!
Has Eclipse, Netbeans, JBuilder, IDEA, JDeveloper (more… ?)
Any IDEA?
I’m not sure I understand your question.
You understand the basic fundamentals: JVM = CLR, Bytecode = IL, etc.
You say “some” API are implemented. Name a Java API that has no equivalent in .NET. Not to mention the fact that .NET’s APIs tend to be more consistent.
I think the closest equivalent to J2EE would be COM+, which is not a .NET technology, but which .NET objects can plug into. There is also remoting, which is roughly equivalent to RMI.
So we have to compare .NET with J2SE fo far…
Swing??? 😉
is WinForms ~ AWT? (No MVC???)
How is it compare to SWT???
NET Remoting (Distributed GC?)
RMI/IIOP – Remoting/IIOP 😉
ADO.NET without OLE & ODBC = Oracle/MS Datasource…
Just silly to compare with JDBC. (Yes we have RowSets 😉
Well to be honest the rest looks more or less similar…
In 2 words .NET is JAVA 1.1.4 (1997 🙂 Didn’t M$ had J# oops J++ these years? 😉
Regards
Haha. I think at this point we’re entering the realm of opinion. I abandoned Java for .NET because I feel just the opposite to you. I see .NET as an improvement on Java. For instance, I found JDBC to be seriously lacking in comparison to ADO.NET.
You’re the first person I’ve ever heard complain about not having a direct equivalent of CORBA/IIOP/ORB on .NET. That stuff was bloated. But to each his own.
🙂 What exactly you lack in JDBC?
XA, batch updates, updates on ResultSet??? 😉
So you are looking for an exact copy of lightweight and well-designed technologies such as swing and enterprise java beans?
I try to understand WHY?
I understand WHY Microsoft need it, but looking at companies moving to .NET…
I thought in 2000 there were noone so stupid to trump itself again and again and again…
Sad.
Delegates are probably the better choice for ALL callback mechanisms. Interfaces are helpful when you need to specify more than one method (but that situation isn’t usually considered a “callback”). Interfaces with only one method just add to source-code bloat.
But the problem with C# delegates is that they’re all multicast delegates. The CLR has ‘Delegate’ and ‘MulticastDelegate’ classes, but C# delegates always derive from ‘MulticastDelegate’. This means that you can’t have the equivalent of a method pointer, resulting in a weaker type system. That’s also what makes them slow. A “single-cast” delegate invocation would be faster than an interface call because you don’t have to do a vtable lookup.