To use the library in actual software projects, it would be great to be able to extend the classes, in order to add domain logic to them.
Currently, in the FeatureModelBuilder allows to be initialized with some instance of FeatureModel. This already allows to initialize it with a prototype of an extended FeatureModel inheriting the original implementation.
Yet, the Builder directly calls new Feature to create new Features. This makes it impossible, to extend Features with meaningful domain logic.
For this it would be great, to allow further configuration of the FeatureModelBuilder, by using a factory method instead, that can be injected.
Essentially I propose a field private Function<String, Feature> featureFactory with a default value of Feature::new but the option to replace it with some factory method for a Feature descendent. A dedicated (functional) interface could of course improve readability.
The same principle could be applied to the various constraints.
Of course, it would then be necessary, to put theese configured objects to use. Currently this is difficult, since UVLModelFactory creates its own instance of the UVLListener which creates its own instance of the FeatureModelBuilder, so eventually there would be some general refactoring necessary, to allow dependency injection and configuration over hard-coded object construction.
To use the library in actual software projects, it would be great to be able to extend the classes, in order to add domain logic to them.
Currently, in the FeatureModelBuilder allows to be initialized with some instance of
FeatureModel. This already allows to initialize it with a prototype of an extended FeatureModel inheriting the original implementation.Yet, the Builder directly calls
new Featureto create new Features. This makes it impossible, to extend Features with meaningful domain logic.For this it would be great, to allow further configuration of the FeatureModelBuilder, by using a factory method instead, that can be injected.
Essentially I propose a field
private Function<String, Feature> featureFactorywith a default value ofFeature::newbut the option to replace it with some factory method for a Feature descendent. A dedicated (functional) interface could of course improve readability.The same principle could be applied to the various constraints.
Of course, it would then be necessary, to put theese configured objects to use. Currently this is difficult, since
UVLModelFactorycreates its own instance of theUVLListenerwhich creates its own instance of theFeatureModelBuilder, so eventually there would be some general refactoring necessary, to allow dependency injection and configuration over hard-coded object construction.