+1
-Adrian
On 8/25/2013 9:26 AM, James Carman wrote:
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:;>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
