Scenario builder 3 : remove dependency to the study

[guilpier-code]

This page discusses a particular aspect of this more general discussion

Scenario builder is dependent to the Study : not only the scenario builder is nested in the Study (have a look at the general discussion), but it's also dependent on the Study. At least it prevents the scenario builder from being tested in isolation.
Few examples of reasons for which scenario builder needs the study :

• In class Rules (rules.cpp), when reading scenario builder input data (from scenariobuilder.dat), we need to check that an area name we just read is an existing area in the study.
• When saving to scenariobuilder.dat, mapping of areas names and numbers when saving to scenariobuilder.dat (will disappear when GUI is removed).
• in the apply() step, the scenario builder needs to copy the content of the scenario 2d-matrices it owns into the simulation 2d-matrices. It happens to be that all these target matrices are held by the Study, most of the time inside Areas.

[guilpier-code]

How to remove the dependency to Study

This suggestion about scenario builder internal design implies to separate the fetch of information in the study from the scenario builder usual actions (resetting, reading input from file, saving its content to file, apply to matrices, ...). We call these classes scenario category properties (for lack of a better name). Each scenario category has its own property class.

This suggestion of internal design implies that we instantiate these property classes in the class Rules's constructor, and that's the (only) place where we notice the dependency of the scenario builder to the study.

But we can improve this, and possibly remove all dependency to the study, by instantiating the scenario category property classes outside the scenario builder, and add these object to the scenario builder :

Rules::Rules(Study& study, std::string name) : name_(name)
{
    ...
}

Rules::addCategory(std::string categoryName, std::unique_ptr<MatrixProperties> matrixProperty)
{
    categories_[categoryName] = matrixProperty;
}

And then, on the client side :

int main()
{
    ....
    Rules rules("Custom rule set");
    
    // Wind properties
    auto windMatrixProperties = std::make_unique<WindMatrixProperties>(study);
    windMatrixProperties->build();
    
    rules.add("Wind", std::make_unique<SingleScenarioCategory>(windMatrixProperties));
    
    // Thermal properties
    auto thermalScenario = std::make_unique<MultipleScenarioCategory>( /* no arg needed */ );
   
    for(auto& area : study.areas)
    {
        auto thermalMatrixProperties = std::make_unique<ThermalMatrixProperties>(area);
        thermalMatrixProperties->build();
       
        thermalScenario->add(area->name,  
                             std::make_unique<SingleScenarioCategory>(area->name, thermalMatrixProperties));
    }
    
    rules.add("Thermal", thermalScenario);
    ...
}

Doing this way, we move the dependency to the study from the scenario builder to categories properties (classes MatrixProperties).
In unit tests, since category properties classes have a common abstract parent, they can be easily mocked : their mock counterpart constructor does have to take the study as argument, and we can have their data members contain whatever we wish.

[sylvlecl]

I would propose to simply provide the (const) Study& as an argument to the 3 functions that you identified above:
apply, save and load.
Or better, more targetted arguments such as just the necessary subset of the study, or simply a kind of "validation function" as you have proposed in the discussions on internal design. With this last option, the definition of the validation function could go into the solver lib: the "scenario builder" lib becomes independant from the "study" module, and it's the role of the solver to ensure consistency between both.

Indeed the study has nothing to do in the data classes themselves, it needs only be available at the time of those processings.

[sylvlecl]

Actually, I think that the "apply" function would find a better place into the solver lib, because it's really a processing function that occurs during simulation.