Menu
▾
▴
Re: RE: [Springframework-developer] Re: Final methods in SqlQuery
|
From: Dmitriy K. <dko...@ru...> - 2004-01-03 03:57:53
|
+1 on that one.
Regards,
Dmitriy.
----- Original Message -----
From: Choy Rim <ch...@ny...>
Date: Friday, January 2, 2004 9:48 pm
Subject: RE: [Springframework-developer] Re: Final methods in SqlQuery
> 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
> classesimplement 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-
> freedomand yet continues to maintain the clarity of design.
>
> --mark
>
> -----Original Message-----
> From: spr...@li...
> [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
> methodsnon-final today, if noone objects.
>
> 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
> thisdoesn'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.
>
> Juergen
>
>
> ________________________________
>
> 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 = 0;i<parameters.length;i++)
> {
> Object p = parameters[i];
> if(p instanceof java.lang.String)
> {
> parameters[i] = 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.
>
> 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
> >
> > 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=1278&alloc_id=3371&op=click
> _______________________________________________
> 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_id78&alloc_id371&op=ick
> _______________________________________________
> 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_id78&alloc_id371&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
|
