You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current configuration system feels a little bit clunky. Many fields could be moved to a common abstract superclass, and various methods are hard-coded to return null or throw an Exception.
I propose to research and possibly implement, depending on the results, a fairly fundamental (and breaking) change, that would, in my opinion, improve the configuration system.
Concretely I propose the following:
Do away with the CoreConfiguration and OverrideConfiguration classes, but retain the Configuration interface.
A paradigm shift, from considering configurations to be semi-mutable, to making them immutable data-carriers (records). Consider the following example:
publicrecordBeanMapperConfiguration(/* The necessary fields */) implementsConfiguration {
publicBeanMapperConfiguration(finalBuilderbuilder) {
this(/* The necessary fields, recovered from the builder */);
}
publicstaticclassBuilder {
// Mutable fields mirroring those in the BeanMapperConfigurationpublicBuilder(finalConfigurationconfiguration) {
// Populate fields based on the given configuration, just like the current OverrideConfiguration would.
}
publicBeanMapperConfigurationbuild() {
returnnewBeanMapperConfiguration(this);
}
}
}
Note that this does allow the user to create custom configuration-implementations still, as we retained the Configuration interface. However, I do recommend trimming the Configuration interface, to suit the immutable data-carrier paradigm, by removing the mutator-methods.
As the current BeanMapperBuilder is more of a ConfigurationBuilder, I propose scrapping the BeanMapperBuilder entirely, and replacing it with a BeanMapperFactory, looking something like this:
The current configuration system feels a little bit clunky. Many fields could be moved to a common abstract superclass, and various methods are hard-coded to return null or throw an Exception.
I propose to research and possibly implement, depending on the results, a fairly fundamental (and breaking) change, that would, in my opinion, improve the configuration system.
Concretely I propose the following:
Note that this does allow the user to create custom configuration-implementations still, as we retained the Configuration interface. However, I do recommend trimming the Configuration interface, to suit the immutable data-carrier paradigm, by removing the mutator-methods.
The example could also be implemented as a Singleton, for thread-safety.
The text was updated successfully, but these errors were encountered: