Gustavo Hexsel wrote:
Isn't it contradicting that you guys use abstract classes because they are more
"evolvable" and then lock everything with "final" so things don't change as
easily?
Evolvable means that it is easier to add stuff to the class. The Wicket
team is responsible for evolving the classes, by providing stuff like
Ajax, CSS/JavaScript support, etc. By making stuff final we make sure
that things that are internal to us, stay that way.
Effectively those methods are no longer part of the public API. Every
public extension point we provide is no longer available to us to change
at our leisure. It is /the goal/ of a framework designer to minimize the
number of extension points, and at the same time deliver as much
functionality and flexibility as possible. There is a thin line, and
that line is created and maintained by making things final.
I quote Joshua Bloch here: design and document for inheritence or else
prohibit it. This is exactly what we do. We design our API such that you
can add your necessary functionality to the components, leveraging the
rich functionality the components provide.
There are lots of moments when we were saved by having something final,
and also a lot of moments where something wasn't final, but should have
been.
Martijn
[]s Gus
---------- Início da mensagem original -----------
De: [EMAIL PROTECTED]
Para: [email protected]
Cc:
Data: Sat, 16 Jul 2005 00:06:57 +0200
Assunto: Re: [Wicket-user] Why no page interface?
i agree.
When you have a IPage object there should be able to have multiply Page
implementations.
But this is not really possible because the internals of page are pretty
importand for wicket to let it work
If you have a full blown page with all kind of components on it. I don't
think putting an other page implementation beneath it
that does honor the complete interface will really render the page...
So if that isn't possible what is the use?
johan
Eelco Hillenius wrote:
Hi,
One /very/ important reason not to use interfaces in this case is
that: interfaces are hard to evolve. Interfaces have to be pretty darn
stable before even considering throwing them out in the public, as
there is no way (not without a tough fight at least) you can alter it
later on - even adding a new method will break all clients.
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_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_idt77&alloc_id492&op=click
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
