On Sat, Feb 18, 2017 at 4:04 PM, Daniel Dekany <[email protected]> wrote: > 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).
Right. Either ObjectWrapperFactory or ObjectWrapperBuilder should work without having two layers. In Configuration example, I vaguely added ConfigurationFactory to be created by ConfigurationFactory.Builder just in case the factory itself could be determined by multiple arguments or which factory could be determined by the builder, just as possibility. If not, just having either Factory or Builder should suffice, IMHO. Regards, Woonsan > > -- > Thanks, > Daniel Dekany >
