Friday, October 24, 2003

Composition Trumps Inheritance

Just a random thought ... composition is more powerful than inheritance because, using composition, you always work in terms of a single, outward facing, public interface.

With inheritance, you have the public interface and the "protected" interface: the constructors and protected members inherited from a super-class. This creates a greater "surface area" that you have to adapt to.

With composition, you can extend an existing service (yes, this is about HiveMind because Tapestry is so inheritance based) by wrapping around it. You don't subclass to the other service, but you do delegate to it.

In some ways, inheritance is just a awkward and limited kind of composition. If class A inherits from class B, then class A implements the same interface as class B and delegates all methods to class B that are not overridden by class A. super is just explicitly delegating to B, and the rest is syntatic sugar for automatically delegating to B. Well, pretty much (this concept breaks down once you enter the idea of a super class invoking methods overriden by a subclass, not to mention reflection).

I think UML has recognized this for a long time; I've always had a hard time creating sequence diagrams for classes that make use of inheritance (and recursion) because there isn't a really good way of representing those kinds of invocations. With no inhertiance buts lots of delegation, such sequence diagrams are completely reasonable.

No comments:

Post a Comment

Please note that this is not a support forum for Tapestry. Requests for help will be deleted. Please subscribe to the Tapestry user mailing list if you are in need of support, or contact me directly for professional (for pay) support.

Spammers: Don't bother. I delete your comments and it's a waste of time for both of us. 垃圾邮件发送者:不要打扰。我删除您的评论和它的时间对我们双方的浪费