commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <>
Subject [ALL] Design question: static utility classes
Date Sat, 24 Aug 2013 18:33:06 GMT
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(...);



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message