I'm a fan of the "bean-based" approach (no static methods). Seems cleaner to me.
On Mon, Aug 26, 2013 at 10:08 AM, Oliver Heger <oliver.he...@oliver-heger.de> wrote: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
