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
signature.asc
Description: OpenPGP digital signature
