|Version 7 (modified by kmartin, 7 years ago) (diff)|
Here are some comments on Lou's notes. Lou's pdf file is at the bottom of the page. It also includes a summary of comments from Jun in an earlier email.
- I like Lou's idea of an OsiXForm that provides one portion of the API. In the attached code below, osiTest.cpp, there is an abstract class OsiXForm which implements Lou's thinking (I think). This purpose of this virtual class is to provide a template for all classes which implement a problem modification. In this code I am using the "Command" design pattern where a modification method is encapsulated as an object. Each modification method is encapsulated into an object in a class that inherits from the abstract OsiXForm class. I provide two trivial examples, DeleteConstraints and AddVariables. The abstract class OsiXForm has two pure virtual functions record() and modify(). The record() method keeps track in a static vector all of the modifications of a given object type (for example the DeleteConstraints object). Before the problem is solved the modify() is called to make the necessary modifications for each class.
- Lou also suggested a way to record all of the transformations. Using his terminology there is a class OsiXFormRec. This class also has a record() method, however, the record() method in the OsiXFormRec class records ALL of the modification objects of every type into a vector modObjects. Then the OsiXFormRec class also has a method callModClasses(). This method loops over the vector modObjects of ALL types of possible modifications and by polymorphism calls the right modification class record() method. So the effect is now for each class to have a recording of all modifications specific to that class. So for example, the AddVariables would now have a complete list of variables that it is supposed to add.
- I would like to avoid the terminology OsiModel. We are working with problem instances and not models.