Peter Veentjer - Anchor Men wrote:
Although I do use interfaces for my facade/dao.
---------------------------------------------
In the beginning I though that it would be a good idea to create a dao
abstraction. But my experience so far is that is it impossible to switch from
Dao implementation. There are so many unwritten OR-mapper rules (especially
Hibernate) that I think writing a DAO interface is doing a lot of extra work
for something that could never be given an alternative implementation.
Mine experience is different. It depends on how your DAOs are designed.
If you rely too much on the ORM tool, the switch really can hurt.
You don't need to build entire facade, simple DAO abstraction seems
enough for me. I think with simple business model, it's matter of hours.
And if the business model is not simple, then doing it without DAO
abstraction is daring at least. Proper layering is the key :))
And there is a big problem with injection. Pages get serialized. Setting
orm sessions, etc. as page properties would serialize them either. What
for? The point is to have the page instances as small as possible.
From what I've seen you want to do AOP more than actual injections.
While annotations really look nick, there are issues.
The problem with wicket is that due to it's component nature making
proxies of pages is hardly to be suffiecient, even if that was possible.
To exploit it's main strength, true reusability, you would need to
inject components too. Not mentioning, that most of interaction handlers
are methods of anonymous classes.
-Matej
AOP could be nice, although I can't really think of anything useful that
wouldn't be possible with subclassing. And for that you would have to
handle spring creating pages and give up passing arguments through page
contructor.
----------------------------------------------------
The CGlib doesn`t allow making proxies of classes with argument-less
constructors.. but I should be possible. I hate adding stuff with setters
because I can`t give a guarantee that my objects are in a consistent state.
But sometimes you have give in... (if you don`t have to give in too much).
And true subclassing only is possible if every method was subclassable.. that isn`t the case.. most methods are final. But I think Subclassing is overrated and a sign of a beginning oo developer.. There are other ways... but you need a seperation of definition and implemenation to realise it.
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
