You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Martijn Dashorst <ma...@gmail.com> on 2007/09/10 10:30:31 UTC
Re: why final?
On 9/10/07, Matthijs Wensveen <m....@func.nl> wrote:
> Off-topic: Why are so much methods marked final? This might prevent
> API-misuse but also prevents innovative _use_! I can understand you want
> framework users to do it the wicket way, because they will probably only
> spam the users list with questions that have obvious solutions (like me
> :D ). But sometimes it's just frustrating.
Innovative use is something we frown upon. Seriously: we *NEED* the
ability to be able to get stuff out of the way. Sometimes the hiding
capabilities of Java are not enough in a good OO hierarchy. When we
open up something to be overridable we do so *only* when we are
confident it will not break stuff. This gives us leeway to replace
parts of our api we aren't proud of (yes we are still learning) with
an api that is much better suited.
More from an old faq (I added it to our wiki):
Classes and methods in Wicket are generally declared as final until
the need for extensibility is well understood. While this defensive
approach may seem obsessive to some, the major benefit is that classes
and methods which haven't been designed for extension cannot be
extended until the problem(s) at hand are examined by the Wicket
development team. This helps to ensure that the best approach is
taken. Sometimes, straightforward extension is not the best approach.
Sometimes, features of the API have been misapplied or misunderstood.
It's best to catch this early.
While this does provoke more discussion and sometimes a bit of
annoyance, the discussion generally improves Wicket and will help
ensure greater backwards compatibility in the future. It's really a
matter of how the development team manages API commitments. By making
fewer commitments in the API in terms of extension points, we are more
likely to be able to support those extension points that we do allow
in the future. We are also more likely to catch anti-pattern use cases
and provide features appropriate to the problems you are trying to
solve.
Honestly, we aren't trying to annoy anyone and we do aim to respond
quickly to any extension needs that arise which make sense. If you
really don't agree with all this, remember that Wicket is open source.
You can always check out the source code, remove the final keyword
that offends you and rebuild the project.
> Maybe this is a consequence of the fact that wicket forces you to
> subclass components so much. It's just too tempting to override so much
> methods. I love wicket (I really do!) but I'd rather see wicket more
> event listener oriented. This would also make it easier to listen to
> events that are very deeply nested (fetch the component, register a
> listener), which is almost impossible now.
This is not good OO IMO. Here you break encapsulation big time. It is
much cleaner IMO to provide extension points as part of your API, not
to give full access to a component.
The following panel illustrates my point: the panel clearly publishes
two important extension points: onLogin and onLogoff. Giving direct
access to the form and having to register an onSubmitListener or the
link and having to register an onClick listener breaks encapsulation:
I am then bound to always supply the link and form. I can't make it an
ajax panel without my clients having to know about it.
public abstract class LoginPanel extends Panel {
public LoginPanel(String id) {
....
if(Session.get().getUser() != null) {
add(new LogoffFragment("content"));
} else {
add(new UsernamePasswordFragment("content"));
}
}
protected abstract boolean onLogin(String username, Stringpassword);
protected abstract void onLogoff();
private class LogoffFragment extends Fragment {
...
add(new Link("logoff") {
protected void onClick() {
onLogoff();
Session.get().invalidate();
}
});
...
}
--
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.0-beta3 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: why final?
Posted by Matthijs Wensveen <m....@func.nl>.
Martijn Dashorst wrote:
> On 9/10/07, Matthijs Wensveen <m....@func.nl> wrote:
>
>> Off-topic: Why are so much methods marked final? This might prevent
>> API-misuse but also prevents innovative _use_! I can understand you want
>> framework users to do it the wicket way, because they will probably only
>> spam the users list with questions that have obvious solutions (like me
>> :D ). But sometimes it's just frustrating.
>>
>
> Innovative use is something we frown upon. Seriously: we *NEED* the
> ability to be able to get stuff out of the way. Sometimes the hiding
> capabilities of Java are not enough in a good OO hierarchy. When we
> open up something to be overridable we do so *only* when we are
> confident it will not break stuff. This gives us leeway to replace
> parts of our api we aren't proud of (yes we are still learning) with
> an api that is much better suited.
>
> More from an old faq (I added it to our wiki):
>
> Classes and methods in Wicket are generally declared as final until
> the need for extensibility is well understood. While this defensive
> approach may seem obsessive to some, the major benefit is that classes
> and methods which haven't been designed for extension cannot be
> extended until the problem(s) at hand are examined by the Wicket
> development team. This helps to ensure that the best approach is
> taken. Sometimes, straightforward extension is not the best approach.
> Sometimes, features of the API have been misapplied or misunderstood.
> It's best to catch this early.
>
> While this does provoke more discussion and sometimes a bit of
> annoyance, the discussion generally improves Wicket and will help
> ensure greater backwards compatibility in the future. It's really a
> matter of how the development team manages API commitments. By making
> fewer commitments in the API in terms of extension points, we are more
> likely to be able to support those extension points that we do allow
> in the future. We are also more likely to catch anti-pattern use cases
> and provide features appropriate to the problems you are trying to
> solve.
>
> Honestly, we aren't trying to annoy anyone and we do aim to respond
> quickly to any extension needs that arise which make sense. If you
> really don't agree with all this, remember that Wicket is open source.
> You can always check out the source code, remove the final keyword
> that offends you and rebuild the project.
>
Okay. I'll try to live with it. And when I find use-cases where I really
need final to be removed, I'll spam the list and either there is a
better way and I learn something, or I get my way and the final keyword
is removed. Sounds like a win-win situation! :)
>
>> Maybe this is a consequence of the fact that wicket forces you to
>> subclass components so much. It's just too tempting to override so much
>> methods. I love wicket (I really do!) but I'd rather see wicket more
>> event listener oriented. This would also make it easier to listen to
>> events that are very deeply nested (fetch the component, register a
>> listener), which is almost impossible now.
>>
>
> This is not good OO IMO. Here you break encapsulation big time. It is
> much cleaner IMO to provide extension points as part of your API, not
> to give full access to a component.
>
> The following panel illustrates my point: the panel clearly publishes
> two important extension points: onLogin and onLogoff. Giving direct
> access to the form and having to register an onSubmitListener or the
> link and having to register an onClick listener breaks encapsulation:
> I am then bound to always supply the link and form. I can't make it an
> ajax panel without my clients having to know about it.
>
> public abstract class LoginPanel extends Panel {
> public LoginPanel(String id) {
> ....
> if(Session.get().getUser() != null) {
> add(new LogoffFragment("content"));
> } else {
> add(new UsernamePasswordFragment("content"));
> }
> }
>
> protected abstract boolean onLogin(String username, Stringpassword);
> protected abstract void onLogoff();
>
> private class LogoffFragment extends Fragment {
> ...
> add(new Link("logoff") {
> protected void onClick() {
> onLogoff();
> Session.get().invalidate();
> }
> });
> ...
> }
>
>
Okay, I see what you mean. A component designed to do XX should publish
onXX methods that are overridable. That's so crazy it just might work!
Matthijs
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 4230000
F +31 20 4223500
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org