On 8/13/05, Jonathan Locke <[EMAIL PROTECTED]> wrote: > > there's something wrong with delegation and inheritance being such a fixed > and fragile choice. there must be some way to structure a language so you > can mix in functionality at compile (or run) time, without the headaches > of manual > delegation, yet with usable compiler checking benefits and without the worst > problems associated with traditional MI.
I think that's why you are seeing such a growing popularity with Inversion of Control concepts. IoC functionality, like AOP or Dependency Injection containers, provides the sort of flexible, run time (or configuration time) composition required by today's more complex systems. I do believe, however, there is some different between inheritence and delegation that can help steer you in the right direction. For instance, to me, inheritence is good when I want to model an IS-A relationship. Of course, WebPage IS-A Page, so that was an easy choice. :) Delegation is good when the algorithm requires variability, especially at run time. A class should only do one thing, so when it needs to, for instance, combine multiple things together in a single algorithm, it will delegate each step in the algorithm to the appropriate classes. Delegation can come in many forms, from delegating to an overridable method (which is the solution you are proposing) to delegating to another interface. Delegating to an interface has the advantage of being able to swap out, easily, the implementation of the delegatee. Delegating via a method is more difficult, because to change that method's implementation, you either need to subclass the class, or enlist the help of AOP's Method Replacement. I believe delegation via interfaces to be more flexible, also because it's easiest to encapsulate behavior inside a class (it's more explicit than in a method, because the method is inheritly _part of_ some other algorithm, thus more tightly coupled). >From what I can tell, Wicket doesn't have the concept of a Container, and thus it's much more difficult to implement delegation via interfaces because then the question becomes, "Where do I get my class to delegate to?" This is why Tapestry, WebWork, and Spring all provide the concept of a container. I believe Wicket prefers its extensive use of anonymous inner classes, and inner classes, because it doesn't know _where_ to get classes otherwise. Not to say one way is better than the other, but maybe that can help shed the light on this topic. Good discussion! Seth ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Wicket-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-user
