Here's a quote from the Spring docs about the open/closed principal that I
think Henri is alluding to:
“Open for extension...”
One of the overarching design principles in Spring Web MVC (and in Spring in
general) is the “Open for extension, closed for modification” principle.
The reason that this principle is being mentioned here is because a number of
methods in the core classes in Spring Web MVC are marked final. This means of
course that you as a developer cannot override these methods to supply your own
behavior... this is by design and has not been done arbitrarily to annoy.
The book 'Expert Spring Web MVC and Web Flow' by Seth Ladd and others explains
this principle and the reasons for adhering to it in some depth on page 117
(first edition) in the section entitled 'A Look At Design'.
If you don't have access to the aforementioned book, then the following article
may be of interest the next time you find yourself going “Gah! Why can't I
override this method?” (if indeed you ever do).
1. Bob Martin, The Open-Closed Principle (PDF)
Note that you cannot add advice to final methods using Spring MVC. This means
it won't be possible to add advice to for example the
AbstractController.handleRequest() method. Refer to Section 6.6.1,
“Understanding AOP proxies” for more information on AOP proxies and why you
cannot add advice to final methods.
(The link to the pdf no longer works; it was going to www.objectmentor.com; I
think you can still find it if you hunt around on that site. The name of the
file is ocp.pdf.)
Henri Yandell wrote:
Generally agreed. With public APIs I've learnt to be stronger on
making things private as it tends to only come back to bite you if you
try to over think it; and when it's public you have no ability to
identify all the use cases so you end up in legacy hell.
I just fix the bugs though - I wasn't an original developer :) I
suspect their focus was strongly on implementing the spec and less on
the implementation classes themselves.
Hen
On Sat, Jul 11, 2009 at 1:32 AM, Stuart Thiel<stuart.th...@gmail.com> wrote:
Hello Henri,
Yes, that would solve my immediate problem. It is a bit of a one-off hack,
though. The follow-through would be to take a look at all the classes and
identify areas where "hooks" like that would be desirable.
It is perhaps a difference in philosophies of programming, but my preference
is generally to use protected methods instead of private methods (and avoid
final methods at all costs), and that would be my preferred approach here (I
don't know your direct involvement thusfar into how things are). However,
consistency is also good to see in a project, and it's not my show, so I'm
less inclined to prosthelytize on how to "do it right". I'd be glad to go on
at length as to why I think the protected methods approach would be best,
but will only do so upon request.
Stuart
Henri Yandell wrote:
I didn't explain myself well.
Basically I would insert reconfigureFormatter(NumberFormat/DateFormat)
inside doEndTag. By default it would nothing.
On Fri, Jul 10, 2009 at 5:03 AM, Stuart Thiel<stuart.th...@gmail.com>
wrote:
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-user-unsubscr...@jakarta.apache.org
For additional commands, e-mail: taglibs-user-h...@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-user-unsubscr...@jakarta.apache.org
For additional commands, e-mail: taglibs-user-h...@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-user-unsubscr...@jakarta.apache.org
For additional commands, e-mail: taglibs-user-h...@jakarta.apache.org
