|
From: Choy R. <ch...@ny...> - 2004-01-03 02:48:33
|
Juergen,
Let's not get carried away here. I don't think it's such a good idea to
make these methods non-final. If I'm not mistaken, some of these classes
implement the TEMPLATE METHOD pattern. If that is the case, then it is
recommended to make the template method final. Sticking to this
convention may sound dogmatic but IMHO it will maintain the integrity of
the code. Extension points will remain clear. Invariants will be
maintained. Etc., ...
Adding an extension point or hook like doPreprocess() that is called by
execute() would be more consistent with the TEMPLATE METHOD pattern. If
the number of hooks becomes unwieldy, perhaps introduce the STRATEGY
pattern.
I understand that restrictions ("tie my hands") tend to be unpopular.
But we'd be better off evangelizing the benefits of the pattern, than
introducing cracks in the integrity of the code base.
IMHO one of the strengths of the spring framework is the clarity of its
design. I hope we can find a compromise that provides both 80-20-freedom
and yet continues to maintain the clarity of design.
--mark
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf
Of j?gen h?ler [werk3AT]
Sent: Friday, January 02, 2004 5:45 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Re: Final methods in SqlQuery
This sounds plausible to me. I'll look into turning appropriate methods
non-final today, if noone objects.
=20
The original rationale behind the final methods is to offer clear
extension points: Subclassers should know which methods are intended for
overriding and which are not, avoiding confusion. But I agree that this
doesn't work for cases that the framework developers didn't expect, so
it's probably better to not use final for methods where there is no
clear general extension hook. I've already applied the same principle in
the bean factory implementation hierarchy.
=20
Juergen
=20
________________________________
Von: spr...@li... im Auftrag
von David Heimann
Gesendet: Fr 02.01.2004 02:24
An: spr...@li...
Betreff: [Springframework-developer] Re: Final methods in SqlQuery
Ken and developers,
I have a business rule in my system that all the data be
stored in upper case in the database. This sugests the
following design:
1)This is a business rule and so should be in the model
layer rather than the presentation layer
2)The code to upper case the data should be centralized.
Requiring each developer to upper case the data before
calling the execute or update methods duplicates code and
is error prone. (the PetClinic sample has around 12
execute or update calls, each of which would need to be
prefaced by upper casing code)
3)This suggests a design where I extend SqlUpdate and
SqlQuery and override the SqlUpdate.update and
SqlQuery.execute methods, for example
public abstract SqlQueryUpper extends SqlQuery
{
public List execute(Object[] parameters, Map context)
throws DataAccessException {
//upper case string parameters
for(int i =3D 0;i<parameters.length;i++)
{
Object p =3D parameters[i];
if(p instanceof java.lang.String)
{
parameters[i] =3D p.toUpper();
}
}
return super.execute(parameters, context);
}
}
Of course, I could create my own method with a different
name such as
...
public List executeUpper(Object[] parameters, Map context)
throws DataAccessException
{
(same as above)
}
But if I do that, then I
1)Still have the original SqlQuery.execute method out
there which no one should use.
2)Do not have all the other signatures available such as
SqlQuery.execute(int), SqlQuery.execute(String) etc because
they all still go through the original execute method.=20
Finally, my problem is an example of something not included
or anticipated by the developers of the Spring Framework.
There is no built in Spring 'auto-upper' option nor should
there be. Putting final on methods stops me from adding it
myself, making the framework unextendable in this area.
IMHO final methods should be few and far between in an
extensible framework and I do not think they are called for
here.
Sincerely,
David Heimann
>David,
>
> I don't understand why you think it would be nice to
***override*** it.
> The execute method does all the IOC hard stuff for you.
If you override
> it, you have to do this yourself, adding unnecessary
duplication. That's
> why it's final. The same goes for SqlUpdate.update. In
your example, why
> not simply manipulate the parameters to your heart's
content before
> passing them to the execute method ?
>
> Ken
>=20
> Heimann, David X - San Mateo, CA wrote:
>
> > Developers,
> >
> > Could you change
> >
> > *public** final* List execute(*final* Object[]
parameters, Map context)
> > {
> > ...
> > }
> >
> > in org.springframework.jdbc.object.SqlQuery to not be
final ? It
> > would be nice to overload it, for example to change all
parameters to
> > upper case before executing. The similar update method
in SqlUpdate
> > is not final. Why be final at all ?
> >
> > David Heimann
> >
__________________________________
Do you Yahoo!?
Find out what made the Top Yahoo! Searches of 2003
http://search.yahoo.com/top2003
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for
IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys
admin.
Click now! http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for
IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys
admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id371&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|