Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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:

  1. Each algorithms has one dialog and each dialog can have many algorithms associated with it.
  2. When the user selects an algorithm a dialog associated with that algorithm is displayed.
  3. 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.

share|improve this question
I'm not clear on what's going on here. Just use a reference if you need multiple access to a single datapoint. If you need snapshots in time, then the memento is fine for this. – Telastyn Nov 13 '12 at 18:54
I agree with @Telastyn. If you need undo, nesting transformations with a Decorator might come in handy as well. – neontapir Nov 13 '12 at 19:18
Actually, having read it again, I think Chuck's simply looking for the State pattern. But I don't have time to rewrite my answer, so ... deleted. – pdr Nov 13 '12 at 19:36
@neontapir I do not need to undo a state, I need to randomly change between state based on algorithms selected. Each algorithm has a specific transformation it need to apply to its output (e.g. rotate 10deg in the x axis). The transformation is determined by the dialog(it's stored in a edit box). If the user selects another algorithm they may get a different dialog or the same dialog with the new algorithms transformation in it. – ahenderson Nov 13 '12 at 19:37
@ahenderson You're doing a really bad job describing the problem at hand. Be more concrete. From what I understand, you don't need to change the position state itself, just apply transforms consecutively? – Telastyn Nov 13 '12 at 19:48

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.

share|improve this answer
agreed.. must watch out for "pattern forcing" – hanzolo Nov 13 '12 at 22:09
"model-view-controller" is often described as a design pattern, though it's arguable that it's more an architecture than a design pattern. Still, if you want a fancy pattern... – Brian Nov 13 '12 at 22:44

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.