Saturday, February 18, 2017, 7:09:09 PM, Woonsan Ko wrote:
[snip]
> I see your point. Let me try for the plan A option with an example again. :-)
> I guess it should look like this if we take all the existing requirements
> as-is:
>
> //stage#1:
> ConfigurationFactory configFactory =
> ConfigFactory.Builder.create(props)
> .setObjectWrapperFactory(
> DefaultObjectWrapperFactory.Builder.create()
> .setIterableSupport(true)
> //...
> .build()
> )
> //...
> .build();
>
> //stage#n:
> configFactory.getObjectWrapperFactory()
> .setForceLegacyNonListCollections(true)
> // ...
> Configuration config = configFactory
> .setDefaultEncoding("UTF-8")
> // ...
> .newInstance()
>
> I've just tweaked the example with an additional Factories to build,
> not the object directly. So, it's not creating the real Configuration
> or ObjectWrapper, but the builder crates a new ConfigurationFactory or
> ObjectWrapperFactory.
> Could this work instead? Or do you think it's too complex?
[snip]
What's the practical difference between a builder and a factory in
this case? I mean, I know what factories are for in general, but in
this case, as far as I see, you have introduced a factory merely so
that stage#n can tweak the settings. But then, isn't that factory just
a builder? Then instead of set/getObjectWrapperFactory we had
set/getObjectWrapperBuilder, and that's one less class (no need for
XxxFactory).
--
Thanks,
Daniel Dekany
