I am looking for a design for my application, here are the players(classes) involved.
struct Transform {
// Uses a matrix to transform the position.
// Also acts acts as the state of a Dialog.
Position transform(Position p);
//other methods.
};
struct Dialog {
// There are multiple dialog for the user to transform the output.
Transform& t;
void ChangeTranformation(){t.rotate(360);}
}
struct Algorithm {
//gives us a position based on an implementation. For example this can return points on a circle or line.
Transform& t;
Position m_p;
Dialog& d;
Position GetCurrentPosition(){ return t.transform(m_p);}
//other methods.
}
Properties I need:
- Each algorithms has one dialog and each dialog can have many algorithms associated with it.
- When the user selects an algorithm a dialog associated with that algorithm is displayed.
- If the user selects a different algorithm then re-selects back the state is restored in the dialog.
Basically I want a good design pattern to maintain the state of the dialog given that many algorithms use it and they can be switched back and forth. Does anyone have any suggestions?
Here is a use case:
Dialog1 has a single edit box to control the radius.
Algorithm1 generates points on a unit circle.
Algorithm2 is the same as Algorithm1.
The user has selected Algorithm1 and entered 2 into the edit box. This will generate points on a circle of radius 2.
The user then selects Algorithm2 and enters 10 into the edit box of Dialog1. This will generate points on a circle of radius 10.
Finally Algorithm1 is selected again. The edit box of Dialog1 should show 2 and points on a circle of radius 2 should be generated.
11
You don’t need fancy patterns. You need to separate the model from the user interface. The algorithms and their current input data form the model.
The dialogs are part of the user interface. When an algorithm is selected, the corresponding dialog is displayed, showing the current data for the algorithm. If the user changes the data, that change is passed to the algorithm.
All you need is a one-to-one relationship between algorithms and their input data, and a many-to-one relationship between algorithms and dialogs.
2
Basically I want a good design pattern to maintain the state of the
dialog given that many algorithms use it and they can be switched back
and forth.
Sounds like a job for Memento.
The memento pattern is a software design pattern that provides the
ability to restore an object to its previous state…
You’re trying to associate the state of a Dialog with an Algorithm. As the current algorithm is being removed, have the current it request a memento from the dialog. The memento is an opaque (from the algorithm’s perspective) object that encodes the dialog’s state. When the newly selected algorithm is added to the window, it gives the memento that it had previously requested (if one exists) to the dialog, and the dialog uses it to configure itself.
That said, preserving the state of the dialog is doing things backward. The purpose of a dialog box is to let the user see, and perhaps modify, the data that the program operates on. In your case, it sounds like the algorithms are part of that. When the user changes something in the dialog box, that should cause a corresponding change in the current algorithm, and said change should be stored in someplace other than the controls of the dialog box. If you organize your program that way you can let the selection of the algorithm drive the content of the dialog. This is exactly how you’d do it if you use the Model-View-Controller paradigm (or one of it’s cousins). If the user changes something in the dialog, that change modifies the algorithm (i.e. the model). If the user selects a different algorithm, the current state of the new algorithm is used to set the values in the dialog.