Refactor builders
Tracking issue for code refactoring mentioned in #532 (closed), #536, #538 (closed).
The following methods are to be refactored (number of copies × number of lines)
-
2 × 62 models_distribution
should be a function -
2 × 8 formatting_reference_data
should disappear as it only callsref_data_formatting
-
2 × 38 ref_data_formatting
should be a function -
pre_check
can be kept duplicated, but obia should benefit from what was added in classification builder -
check_input_text_files
only in classification builder but should be used in obia builder too. should be a function -
3 × 32 check_sensors_data
should be a function -
2 × 31 check_region_vector
should be a function -
2 × 10 test_database_name
should be a function -
check_config_parameters
→ pydantic -
2 × 10 check_mandatory_section
→ pydantic -
check_compat_param
→ pydantic -
2 × 54 init_dict_control_variables
→ pydantic -
generate_output_directories
should not be superseded byi2_builder
subclasses, see #536 -
get_outputs_data
is defined in classif builder but only used in vectorization builder for cross builder logic
More details
- TiledStep Steps which work with tiled data would have to inherit the "TiledStep" mixin
- when I write "should be a function", I mean that it can be detached from a parent class instead of going to a mixin since it does not use
self
(or only for minor use like config file path) - "→ pydantic" as I understood it, pydantic migration would allow to parse the config file only once at the beginning of the chain, and pass a valid dataclass containing the output of
getParam
to builders
To conclude, it appears to be no need for builder mixin, only step mixin. Most of the duplicated code can be put into simple functions. Also if I understood well the pydantic migration, a lot of code can be kept separate from the builders themselves.
Edited by Hugo Trentesaux