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.