mercredi 27 janvier 2016

Design pattern for an optimization module

I have an application and optimization is one of the modules.

  1. The user selects a couple of options (option 1, option 2,...), and then run optimizations.
  2. 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.
  3. 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.
  4. In the future, there may be other optimization models are complete new compared with existing ones.

Currently, I am thinking the following design:

  1. Build interfaces for each of the optimization options;
  2. Build abstract classes for some of the models that have a lot similarities.
  3. Build optimization models that inherit from this abstract class (I still found some codes are exactly the same among these concrete classes.).
  4. 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