Otaku, Cedric's weblog

From classes to components

After Holub's nonsensical article about getters and setters, it's quite a relief to read Anders Hejlsberg interview, especially since the C# architect is basically saying the exact opposite of what Holub tried to say.

Anders emphasizes the fact that nowadays, developers need to think less in terms of classes and more in terms of components (another debate that has recently flared up in the Java community).

The way I see it, Components are a superset of Classes.  What exactly differentiates components from classes is open for interpretation, but I like Anders' simplification:  while classes are about properties and methods (PM), components are defined by PME:  properties, methods and events.

This observation makes both Properties and Events prime citizens of the Component programming model, which explains why C# supports both of them natively, while Java achieves this through interfaces (another language that has native support for accessors but not events is Ruby).

I, for one, really wish that Java had native support at least for accessors, so that we can finally drop the confusing "A read-write property is defined if the Java class has two methods, getFoo() and setFoo().  In this case, the name of the property is that of the method where you remove "get" and lowercase the first letter of the remaining name".  Yikes.

Another topic that Anders discusses in this interview is delegates.

Ever since Microsoft's initial attempts to add delegates to its own Java Virtual Machine, Java developers have had a very strong bias against this concept.  While creating an incompatible JVM is indeed something that should be fiercely condemned, it's a shame that the concept of delegates was thrown away with it, because it makes a lot of sense in a language such as Java.

Anders gives several reasons why delegates are a good idea, but to me, the one that's most important is that delegates allow you to keep the amount of classes and interfaces to a reasonable level.

Every Java developer who has written Swing applications (or any GUI, for that matter) knows how Action objects quickly proliferate, making the whole architecture hard to follow, not mentioning the number of objects that get created just so that a callback method can be invoked.

Delegates allow you to tie an Action to one single method.  No new interface or new class is needed.

Delegates go one step further:  they don't require type conformance but only signature  conformance.  This design choice reopens the age-old debate about static versus dynamic binding, and more particularly, begs the following question:  if two methods have the exact same signature but belong to two different classes, are they semantically equivalent?

My experience is that in practice, it's something that doesn't really cause problems (I usually make a similar observation about untyped Collections and the fact that in practice, the downcast is rarely a source of ClassCastExceptions).

Anders makes some other excellent points, such as the performance gain of a delegate versus a direct method invocation, or his interesting take on what he calls "simplexity".  Read the interview for more details.

Posted by cedric at September 10, 2003 09:12 AM