Hi all, regarding a principle design question I would like to get your opinion:
In [configuration] there are a few static utility classes. One of them is BeanHelper which supports the creation of beans from configuration data. The actual bean creation is done by a BeanFactory which can be configured using the static (currently unsynchronized) setDefaultBeanFactory() method. Sebb stated correctly that this approach is thread-hostile [1]. An alternative could be to make BeanHelper a non-static class which can be instantiated and configured per instance. This would be more flexible and would also simplify testing of client code (just pass in a mock object). The drawback is that clients now always would have to create an instance, so the API becomes slightly more verbose - in fact, most clients will probably never have the requirement to change the default bean factory. So, the question is, what do you prefer? The static approach like Object myBean = BeanHelper.createBean(...); or using an instance as in BeanHelper helper = new BeanHelper(myFactory); // or use no-args ctor for default factory Object myBean = helper.createBean(...); TIA Oliver [1] https://issues.apache.org/jira/browse/CONFIGURATION-486 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
