commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Bourg <ebo...@apache.org>
Subject Re: [DBUTILS] Pre RC for DBUTILS-2.0
Date Mon, 13 May 2013 20:30:29 GMT
Le 13/05/2013 21:24, William Speirs a écrit :
> 
> Yes, I did mean QueryExecutor... sorry. I make my methods protected rather
> than private because I'm not sure how someone (maybe myself) will need to
> change functionality in the future. If I make them private, then there's
> not going back. If I make them protected, someone can always extend and
> provide new functionality. I'm open to other suggestions/ideas though.

Actually it's the opposite. With protected methods there is no going
back. Binary compatibility dictates that these methods will stay there
forever, you won't be able to refactor them unlike private methods. You
can still relax the constraint later by making them protected or public
if the need arises.


> Yes... but to what advantage?

The advantage is an API that is cleaner and easier to understand.


> It is more "generous" in finding a matching name in the bean for a column.
> It will try to remove underscores from column names to match bean names.
> Maybe a better name would/could be UnderscoreAgnosticBeanHandler, but I
> think the idea was to eventually extend GenerousBeanProcessor to include an
> array (or string) of single characters that could be replaced/removed in an
> attempt to find a match. I don't think this needs to be a blocker though to
> get 2.0 out the door. I'll update the JavaDocs though.

Some examples in the Javadoc would help.

As for the name, what about "SmartBeanProcessor" or
"ImprovedBeanProcessor" (much like the ImprovedNamingStrategy in
Hibernate) ? If this implementation is much better than the one in
BeanProcessor, maybe it could be merged with BeanProcessor to be used by
default?

Emmanuel Bourg



Mime
View raw message