I prefer a slight variant: don't give the user static methods on a
different class, just give them one static method yielding an instance
configured for default behavior. I think that's the basic approach being
taken with CSV formats, no?
Matt
On Thu, Aug 29, 2013 at 1:52 PM, Oliver Heger
<oliver.he...@oliver-heger.de>wrote:
> Am 29.08.2013 10:26, schrieb Benedikt Ritter:
> > 2013/8/27 Oliver Heger <oliver.he...@oliver-heger.de>
> >
> >> Am 27.08.2013 07:06, schrieb Phil Steitz:
> >>> On 8/26/13 11:28 AM, Oliver Heger wrote:
> >>>> Am 26.08.2013 16:18, schrieb Phil Steitz:
> >>>>>
> >>>>> On Aug 26, 2013, at 7:38 PM, 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?
> >>>>> Excellent point. The key question to ask is are there use cases
> where
> >> different threads in the same JVM are really going to want different
> >> default factories. I wonder if any actual user of the current code has
> >> ever wanted this.
> >>>>>
> >>>> In this special case, I *assume* that there are hardly any concrete
> use
> >>>> cases, but of course, we cannot be sure.
> >>>>
> >>>> However, there may be other examples in [configuration]. Would it make
> >>>> sense to be homogeneous here, i.e. use the same design principles for
> >>>> all classes?
> >>>
> >>> Yes and the non-static approach is certainly more flexible, so on
> >>> balance I think you and James are right.
> >>
> >> Many thanks for the feedback! So I think I will go for the "bean-based
> >> approach" then.
> >>
> >
> > One possibility to have the best of both worlds is to create a class with
> > all static methods that delegates to an instance that is hold in a static
> > field. This would be for all those that want the default behavior. Those
> > who need customized behavior could instanciate the delegate directly an
> > configure it the way they like:
> >
> > public final class BeanHelperUtils {
> >
> > private static final BeanHelper DELEGATE = new BeanHelper(new
> > DefaultBeanFactory());
> >
> > public static Bean someMethod() {
> > return DELEGATE.someMethod();
> > }
> >
> > }
> >
> > public class BeanHelper {
> >
> > private final BeanFactory factory;
> >
> > public BeanHelper(BeanFactory factory) {
> > this.factory = factory;
> > }
> >
> > public Bean someMethod() {
> > factory.createBean();
> > }
> > }
> >
> > client code can either call BeanHelperUtils.someMethod()
> > or create a BeanHelper with the appropriate BeanFactory instance...
>
> I was thinking about such a hybrid approach, too. But then, giving users
> too many options and alternatives could be again confusing.
>
> Oliver
>
> >
> > just my 2 cents
> > Benedikt
> >
> >
> >>
> >> Oliver
> >>
> >>>
> >>> Phil
> >>>>
> >>>> Oliver
> >>>>
> >>>>> Phil
> >>>>>> 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
> >>>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> 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
> >>
> >>
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
