AtomicReference? On Sunday, August 25, 2013, Phil Steitz wrote:
> 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<javascript:;> > > For additional commands, e-mail: dev-h...@commons.apache.org<javascript:;> > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org <javascript:;> > For additional commands, e-mail: dev-h...@commons.apache.org<javascript:;> > >
