Why delegate is better than interface – in some situations
I know the mechanics of delegate, but I do not really “appreciate” it: I always ask myself: why I should use delegate, instead of interface?
Here is the answer:
http://www.artima.com/intv/simplexity2.html
Basically, if you delegates, it means the signatures are the same; this “coincide” with that convention that when you use delegates, always use the same signature – do not be creative – it all make sense now: delegates/events are simple and mundane “interfaces” -- just like “properties” are get/set methods, which is mentioned in http://www.artima.com/intv/simplexity3.html
C# cleaned up Java’s get/set and simple interfaces, and that is the difference between “class programming” and “component programming”, in simple terms.
posted by survic at
9:56 AM
2 Comments:
Just a note: this “in simple terms” is a serious insight, while at same time kind of humorous, isn't it.
In case you wonder what is the "serious treatment", check out the book:
Programming .NET Components, 2nd Edition
By Juval Lowy
I bought its first edition; and I read it from http://safari.oreilly.com/mybookshelf
time to time.
Mr. Lowy's "component" is more platform oriented; for day to day modeling and programming, set/get and semi-fixed interface is all about "component".
Mr. Lowy's "component" is more platform-oriented; for day to day modeling and programming, set/get and semi-fixed interface is all about "component". If you do not know this insight, it means you have not got OO yet – the reason is simple: in pure OO, there are no such things like property and events; you got to “reduce” them, and reduce them in a sweet and easy way.
Post a Comment
Subscribe to Post Comments [Atom]
<< Home