Hello Rusty,
I don't have the mentioned book, but I quickly found the article:
http://www.objectmentor.com/resources/articles/ocp.pdf
I'm afraid that such is not my interpretation of that article at all. It
seems to clearly suggest that an inviolate superclass, that can be
subclassed (what I propose would be facilitated by marking many of the
now private methods protected) to modify behavior as needed, is the
desired route for following the open-closed principle.
What it does talk about is strategic closing, which has nothing to do
with marking a method final, but is essentially an admission that
nothing can be set in stone. Again, though, the changes I suggest would
conform to the open-closed principle, and in fact would better support
it than the current approach. That is, I'm suggesting to close the
taglib classes against changes to interaction with their underlying java
components (that's a vague target, and it may be more accurate to say
that I want to make it so people can do whatever they want without
having to change the parent classes, while getting the most out of the
existing "closed" code).
It also reminds that making member variables anything but private is a
bad idea, and that explicit casting can make things brittle, but I am
definitely not suggesting either.
Actually, could you confirm that I'm reading the same article this is
mentioned, although it seems to have been written by an R. Martin? Is
the body of your quote the entire message? Have you read that article?
Stuart
Rusty Wright wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-user-unsubscr...@jakarta.apache.org
For additional commands, e-mail: taglibs-user-h...@jakarta.apache.org
