commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <oliver.he...@oliver-heger.de>
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(...);

TIA
Oliver

[1] https://issues.apache.org/jira/browse/CONFIGURATION-486

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message