On 8/24/13 11:33 AM, Oliver Heger wrote: > 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(...);
Personally, I would like the static method better as a user. Synchronizing access to the static factory field would seem to fix the problem unless I am missing something. Also, I would not expect lots of concurrent access to the getter/setter for this field in normal use cases , so the performance overhead of the sync would be immaterial. Having the setter there may also be a little easier for dependency injection. Phil > > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
