Am 25.08.2013 18:45, schrieb Adrian Crum: > +1 > > -Adrian > > On 8/25/2013 9:26 AM, James Carman wrote: >> AtomicReference?
There are multiple aspects here. One is the safe publishing of a value written into the member field. This can be achieved by atomic references, synchronization, or a volatile field. The other aspect is that such a field of a static utility class is pretty global. You cannot have different values for different threads. So the question is, is it good design to have static utility classes with state? For users, it may be more convenient to simply access functionality through static methods, especially if the default values for static member fields are reasonable for most use cases. However, such a design makes it impossible to use the represented functionality with different settings in parallel. Also, I am not sure whether complex class loader scenarios (e.g. an application server or an OSGi container) may cause problems with the static approach. Oliver >> >> 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:;> >>> >>> > > > --------------------------------------------------------------------- > 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
