[Springframework-developer] Re: RE: Re: Final methods in SqlQuery

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Mark and Developers

Certainly it could be done with extension points, changing

	public final List execute(final Object[] parameters, Map
context) throws DataAccessException {
		validateParameters(parameters);
		ResultReader rr = newResultReader(this.rowsExpected,
parameters, context);

getJdbcTemplate().query(newPreparedStatementCreator(parameters),
rr);
		return rr.getResults();
	}

to

	public final List execute(Object[] parameters, Map
context) throws DataAccessException {
		//Pre execute extension point
		preExecute(parameters, context);
		validateParameters(parameters);
		ResultReader rr = newResultReader(this.rowsExpected,
parameters, context);

getJdbcTemplate().query(newPreparedStatementCreator(parameters),
rr);
		List results = rr.getResults();
		//post execute extension point
		postExecute(parameters, context, results);
		return results;
	}

	protected preExecute(Object[] parameters, Map context)
	{
	}

	protected postExecute(Object[] parameters, Map context,
List results)
	{
	}

But it seems to reduce the clarity of the codebase to add
extension points to a method with 4 lines of code,
especially when the extension points are 'pre everything in
the method' and 'post everything in the method' and the
method accomplishes a complete task.  Extending the class
and calling super.execute(...) seems a resonable way to
create this functionality, and it is a familiar idiom for
doing so.  IMHO the SqlQuery.execute() method here is not
so much providing IOC as it is using IOC provided by a
lower level and so more suited for overriding than
extension points.

Sincerely,

David Heimann

>+1 on that one.
> 
> Regards,
> Dmitriy.
> 
> ----- Original Message -----
> From: Choy Rim <choy@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: springframework-developer-admin@li...
 > [springframework-developer-admin@li...] On Behalf
 > Of j?gen h?ler [werk3AT]
 > Sent: Friday, January 02, 2004 5:45 AM
 > To: springframework-developer@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: springframework-developer-admin@li... im Auftrag
 > von David Heimann
 > Gesendet: Fr 02.01.2004 02:24
 > An: springframework-developer@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