And that is a /GOOD/ thing. Most methods are an implementation detail, that need to be called in the framework. As Eelco and Johan and others already said here: the Component hierarchy has very particular behaviour that needs to be fixated at several places in the framework in order to remove the possibility of 'clients' altering that behaviour. ______________________________________ I don`t have problems with final methods. If a method was not designed to be overwritten, make it final. But I have problems if I can provide an alternative implementation that obays a general contract.
No, subclassing /used/ to be overrated. Subclassing has its place in an O.O. design. Look at the design patterns of Gamma et al. they use inheritence quite to the fullest and no one is calling their designs the sign of a beginning O.O. developer! ______________________________________ You didn`t get my point. I didn`t say all subclassing is bad, just a lot of it. There are a lot of ways to add functionality and subclassing is one of them. In most cases (not all) there are better ways that give a more flexible design. A lot of patterns in the GoF book are based on that assumption. and not on 'just' subclassing. Talking about a knee jerk reaction! The main architect of Wicket has over 20 years of O.O. design and development experience, he has worked on the Swing/JFC team and is considered by his peers as top notch. Hardly a beginning O.O. developer. ______________________________________ Maybe.. but you can`t tell my Swing is written extremely well. Check out all the AWT-Garbage. In general the Swing API is workable, but it could have been a lot better and cleaner. And I guess there is not a 'best' way to write software, but using class where interfaces should have been used is not the way I like to write software. Check out other api`s, like the collectionframework/concurrency framework/Spring. Most things are based on interfaces. Imho everything that defines a type and is 'core' (used by a lot of developers with a lot of different needs) should be designed from an interface. >Just my two cents... >-Matej > > > >>Another reason not to use interfaces here is that there is so much >>behaviour in here (in the pages and components), that it is very hard to >>extract something usefull out of it. What would the interface of a Page >>be? One of the good practices when making interfaces is that they should >>be small. Having an interface like >>http://jakarta.apache.org/tapestry/tapestry/apidocs/org/apache/tapestry/IPage.html >>doesn't really display that. They can be large, like the collection >>interfaces are, but they have to be really, really stable and consistent. >> >>Just to be sure, and as I didn't make this decision for Wicket I asked >>Jonathan Locke (who is doing movie stuff now, and left the mailing lists >>for some time) why he choose for interfaces. Here's a partial transcript >>of our chat: >> >>[22:31] jonathan: i don't believe in big interfaces >>[22:31] jonathan: no interface should be as large as Page >>[22:32] jonathan: it's too fragile >>[22:35] jonathan: abstract classes are evolvable >>[22:36] jonathan: interfaces should always be a set of methods that you >>cannot ever imagine extending >>[22:36] jonathan: it encapsulates a very specific set of behaviors >>[22:37] jonathan: everyone should feel free to create/extract his own >>IPage interface for use with proxies >>[22:38] jonathan: there's something fundamentally wrong with the way >>that current OO languages try to wire things together with static >>interfaces. >>[22:39] jonathan: unless i'm missing something, this is really not a >>problem with wicket >>[22:40] jonathan: in fact i think it's a feature >>[22:40] jonathan: interfaces are really most useful for things that are >>truly pluggable >>[22:43] jonathan: my ideal number of methods in an interface is 1 >>[22:43] jonathan: ;-) >>[22:44] jonathan: 2 is okay in some cases >>[22:44] jonathan: 3 often should be re-thought >>[22:44] jonathan: the more methods you have, the more likely it is that >>you've got a bad design >> >>So, it is a design decission not to work with interfaces. However, as >>Jonathan stated, you could extract an interface, let your page class >>implement it and off you go. Furthermore, I wonder what it is you want >>to do with a proxy that you can't do by simply subclassing? Or AOP? >> >>As a final statement I'd like to add that a framework like Wicket is >>very different from a business system, which could have tons of business >>methods that must be pluggable. Though even in that case, I think too >>that interfaces are overused/ get too much focus with some of the >>current popular frameworks. Seems to be getting a knee-jerk reaction >>instead of a design decision. But maybe that's just me. >> >>Regards, >> >>Eelco >> >> >>Peter Veentjer - Anchor Men wrote: >> >> >> >>>I`m trying to add Spring annotations to the Page, but because there is >>>no page interface and only a Page class (with final methods) it is not >>>possible to create a proxy and therefor it is impossible to enhance >>>objects. This is very inconvenient.. >>> >>>Why are the components not designed from interfaces? Designing from >>>interfaces is common oo practice. >>> >>> >>> >>>------------------------------------------------------- >>>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies >>>from IBM. Find simple to follow Roadmaps, straightforward articles, >>>informative Webcasts and more! Get everything you need to get up to >>>speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click >>>_______________________________________________ >>>Wicket-user mailing list >>>[email protected] >>>https://lists.sourceforge.net/lists/listinfo/wicket-user >>> >>> >>> >>> >> >>------------------------------------------------------- >>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies >>from IBM. Find simple to follow Roadmaps, straightforward articles, >>informative Webcasts and more! Get everything you need to get up to >>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click >>_______________________________________________ >>Wicket-user mailing list >>[email protected] >>https://lists.sourceforge.net/lists/listinfo/wicket-user >> >> >> > > > >------------------------------------------------------- >SF.Net email is sponsored by: Discover Easy Linux Migration Strategies >from IBM. Find simple to follow Roadmaps, straightforward articles, >informative Webcasts and more! Get everything you need to get up to >speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click >_______________________________________________ >Wicket-user mailing list >[email protected] >https://lists.sourceforge.net/lists/listinfo/wicket-user > > > > ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Wicket-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-user
<<winmail.dat>>
