commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Crum <adrian.c...@sandglass-software.com>
Subject Re: [ALL] Design question: static utility classes
Date Sun, 25 Aug 2013 16:45:00 GMT
+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-unsubscribe@commons.apache.org<javascript:;>
>>> For additional commands, e-mail: dev-help@commons.apache.org<javascript:;>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org <javascript:;>
>> For additional commands, e-mail: dev-help@commons.apache.org<javascript:;>
>>
>>


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


Mime
View raw message