Igor Vaynberg wrote:
look at the java example. notice Window is an interface.
Yeah, but that's just because it's good practice to use the interface
when there is one. Notice that the actually decorated class is a new
SimpleWindow() in DecoratedWindowTest. Window might as well have been an
abstract class, or even a concrete one. The idea is that the contract of
the class you wrap is maintained, if that is an interface your decorator
implements that, when it's a class your decorator extends it. Same idea.
Of course, interfaces are cleaner and you can even decorate more then
one interface when you want to, but decorating a class is not uncommon
practice (at least where I come from).
Example: http://www.onjava.com/pub/a/onjava/2003/02/05/decorator.html
eg you cant do: add(new DecoratedComponent(someOtherComponent));
No, because component has final methods that you can't override so you
can't delegate to them (that whas my point), but not because you can't
decorate a class.
Matthijs.
PS. If you insist on that you can only decorate an interface, I'll call
it wrap-extend or something :)
-igor
On Thu, Jun 12, 2008 at 5:05 PM, Matthijs Wensveen <[EMAIL PROTECTED]> wrote:
Why would the decorator design pattern only work with interfaces? Maybe
we're talking about two different this here? (I'm talking about this one:
http://en.wikipedia.org/wiki/Decorator_pattern)
I can see why behaviors were introduced. A simple example: a factory method
creates a link. In my subclass I want the same link with the same onClick
behavior but I also want "hello" to be outputted to System.out. How would I
go about doing this with a Behavior? I couldn't figure it out... (which
isn't saying it's impossible).
Matthijs
[EMAIL PROTECTED] wrote:
decorators only work with interfaces, component class is not. This is
part of the reason why we have behaviors
-igor
On 6/12/08, Matthijs Wensveen <[EMAIL PROTECTED]> wrote:
Some useful design patterns like Decorator don't work with final
methods. Wicket components sometimes have overridable factory methods
for child components. The decorator pattern could be very useful here,
because you'd be able to decorate the original component with some extra
functionality (Link.onClick for example). Unfortunately this doesn't
work because some methods are final.
Matthijs
Igor Vaynberg wrote:
i mean generally, for methods, fields, and func args :) most of this
stuff can stay final, but people dont bother doing it because its
extra typing.
-igor
On Thu, Jun 12, 2008 at 8:38 AM, James Carman
<[EMAIL PROTECTED]> wrote:
You mean like C++?
On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg
<[EMAIL PROTECTED]>
wrote:
indeed. i wouldnt mind if final was the default in java :)
-igor
On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst
<[EMAIL PROTECTED]> wrote:
Without the use of final wicket would not have made it this far.
Martijn
On Thu, Jun 12, 2008 at 5:08 PM, Brill Pappin <[EMAIL PROTECTED]>
wrote:
I understand the reasoning, however I think "best practice" can be
debated.
To use your example Swing allows the user to override quite a bit,
and
it
doesn't make any (or very few) assumptions on what should and should
not be
done.
I don't like API's that assume I'm an idiot and prevent me from
manipulating
them how I see fit. If I cause a bug that I have to deal with, thats
*my*
problem to resolve.
In my book (and I'm not the only one) excessive use of final is an
anti-pattern.
- Brill Pappin
On 12-Jun-08, at 10:01 AM, cowwoc wrote:
Brill,
This is actually an API "best practice". Classes fall into two
categories:
ones designed for subclassing, and ones designed to be final. The
same
goes
for methods. Swing is full of examples of what goes wrong when
people
override methods in classes that haven't been designed with
subclassing in
mind.
Gili
Brill Pappin wrote:
on removing the finals
The final members are the worst thing I've had to deal with in
Wicket
so far.
Although I understand that there may be a reason for them, they
are
more a hinderance than anything else and seem to be trying to
"protect
users from themselves".
- Brill Pappin
On 12-Jun-08, at 1:03 AM, cowwoc wrote:
Have you considered moving from subclassing to composition in
Wicket
using
Callable<T>?
Currently it is quite common for developers to subclass a
component
in order
to override isVisible() and other properties. I am proposing that
instead
the component classes become final and properties may only be set
using
setter methods. The setter methods would take Callable<T> instead
of
T, so
for example setVisible(boolean) would become
setVisible(Callable<Boolean>)
The benefit of this approach is that you could introduce static
factory
methods to the Wicket components which would make them much
easier
to use in
their Generic form. You could then introduce various helper
classes
to
create Callable<T> for constant values, such as
Callable.valueOf(true) would
return a Callable<Boolean> that always returns true.
--
View this message in context:
http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17792488.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17800710.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Become a Wicket expert, learn from the best:
http://wicketinaction.com
Apache Wicket 1.3.3 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
