I have an application and optimization is one of the modules.
- The user selects a couple of options (option 1, option 2,...), and then run optimizations.
- I also have a couple of optimization models. Some of them can only handle option 1 type optimization, and some can handle option 1 and option 2 (by passing different parameter values), and so on.
- Some optimization models are just variants of others, e.g, some more variables, different bounds, additional constraints. So, some of the codes are actually the same among these models.
- In the future, there may be other optimization models are complete new compared with existing ones.
Currently, I am thinking the following design:
- Build interfaces for each of the optimization options;
- Build abstract classes for some of the models that have a lot similarities.
- Build optimization models that inherit from this abstract class (I still found some codes are exactly the same among these concrete classes.).
- Build implementations of the interface by calling these optimization models.
I feel it is very confusing. By the end, I still have a lot of overlap among the optimization models (adding some common variables to the solver, set their bounds, etc). What is a better design that is suitable for this module?
Aucun commentaire:
Enregistrer un commentaire