views:

82

answers:

2

Hello

I hope this is not something very trivial and obvious.
I have some similar programs that I am working at. In each program I have to implement future about saving projects. I came with following design :

Project
 -- Program1Project
 -- Program2Project

The base class Project :

class Project
{
 public:
   void NewProject();
   void SaveProejct();
   void OpenProject();
 protected:
  virtual void New();
  virtual void Save();
  virtual void Open();
};

The virtual functions are reimplemented in the derived classes cause only the specific program knows how ( which objects to save to disk ) to actually save the project.

Also part of saving new or opening a project is showing the SaveAs/Open dialog from which the user will select where to save/open the project. For example, the NewProject() is implemented in terms of the New method:

void Project::NewProject()
{
  1. // Show dialog for whether to save existing project
  2. // check whether the project was already saved
  3. // if yes, only overwrite the existing project
  4. // if no, show SaveAs Dialog
  5. // ...
  6. this->New();
}  

Line 1 to 5 is code that all of my programs need, i.e the flow and order in which the dialogs are created and checks are performed is the same.

I was thinking whether the actual code that creates the dialogs should be placed in the Project::New and Project::Open methods. After some thinking I decide that it is not good solution cause the Project class is model class, and model class should not create GUI. So, I was thinking maybe the best place to write the code from line 1 to line 5 , is in the Save/Open buttons event handlers of the specific program. But that means that I will have to duplicate it for each program .

So the question is how should I separate the creating of dialogs which will be the same for all of my programs from the actual saving/opening of the projects in way that do not require duplicating of code ?

+4  A: 

The GUI should refer to the model, not the model to the GUI, and that pretty much keeps the ties of the model free of the GUI. There's really no way to keep the GUI totally free of the model. At some point, you're going to have some sort of depedency, even if the implementation is hidden away from the GUI.

altCognito
+1: Further, we usually unit test the model before we start writing the GUI. This assures that model exists independently from the GUI. Then we add the GUI after the model is finished and unit tested.
S.Lott
+1  A: 

Hi. You could create a seperate class that acts as a controller between the model and the views. The controller could be a membe of the project for example and on line 1 you could call this->viewController->showDialog(callBackForYes, callBackForNo, callBackForCancel)

The viewController class could directly echo out the gui, or use view classes for different gui components.

Eino T
But the model should not know about the controller, i.e controller can calls methods on model, but model can't call methods on controller. Or , I am wrong ?