CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Results 1 to 9 of 9
  1. #1
    Join Date
    Sep 2004
    Posts
    561

    Is memento a good design decision here?

    This might be a really stupid question. I'm just beginning to learn more about design patterns.

    Ok, let's say that I want to detect whether or not a user has made a change anywhere in the dialog box. If the user has made a change anywhere, then I must set the configuration. I cannot set the configuration in the user has *not* made any changes.

    This dialog box contains *many* different text fields, combo boxes, radio buttons. It seems to me that using memento would be a right approach for this problem? Or is there a better approach or alternative?

  2. #2
    Join Date
    Aug 2001
    Location
    Texas
    Posts
    645

    Re: Is memento a good design decision here?

    What is momento?

    I would use a set of variables to capture the settings in the dialog on entry.
    When the user exits, compare the saved values against the current. If
    different, then the user changed something.

  3. #3
    Join Date
    Sep 2004
    Posts
    561

    Re: Is memento a good design decision here?

    Ok... stupid question...
    Just want to make sure I'm understanding the pattern correctly.

    Memento - "Without violating encapsulation, capture and externalize an object's internal state so that the object can be restored to this state later"

  4. #4
    Join Date
    Apr 1999
    Location
    Altrincham, England
    Posts
    4,470

    Re: Is memento a good design decision here?

    Can you give some more details about how you intend to use this pattern in this instance? Do you intend to use a memento to compare the field values to look for differences, or do you have some other purpose in mind?
    Correct is better than fast. Simple is better than complex. Clear is better than cute. Safe is better than insecure.
    --
    Sutter and Alexandrescu, C++ Coding Standards

    Programs must be written for people to read, and only incidentally for machines to execute.

    --
    Harold Abelson and Gerald Jay Sussman

    The cheapest, fastest and most reliable components of a computer system are those that aren't there.
    -- Gordon Bell


  5. #5
    Join Date
    Nov 2002
    Location
    Foggy California
    Posts
    1,245

    Re: Is memento a good design decision here?

    Quote Originally Posted by Rigel
    Memento - "Without violating encapsulation, capture and externalize an object's internal state so that the object can be restored to this state later"
    Do you really need to externalize the internal state? Is the method you are working on really external to dialog?

    If the method is a member function of the dialog, then you don't need to externalize the data and thus memento would be a bad pattern.

    If the method is external to the dialog, then memento seems like it would fit, but then I would wonder if you are really saving yourself work by making this method a non-member.
    Kevin Hall

  6. #6
    Join Date
    Sep 2004
    Posts
    561

    Re: Is memento a good design decision here?

    Can you give some more details about how you intend to use this pattern in this instance? Do you intend to use a memento to compare the field values to look for differences, or do you have some other purpose in mind?
    Yes it would be used only to make a comparison and to look for differences. The class would consist of a function SetState and maybe have a function CompareState or something of that nature.

    Is this pattern an applicable identification of this situation? It seems that Memento is used for "rolling back/undo" but not for making comparisons such as this. But in both situations you are saving the internal state of an object.

  7. #7
    Join Date
    Apr 1999
    Location
    Altrincham, England
    Posts
    4,470

    Re: Is memento a good design decision here?

    I think it's novel use of Memento, and would probably work. It may be overkill, though - is there a reason why you can't just keep a "dirty" flag in the dialog class? You don't say what OS you're using, but Windows controls will notify you if they change, and you could use that notification to record that the dialog has changed.
    Correct is better than fast. Simple is better than complex. Clear is better than cute. Safe is better than insecure.
    --
    Sutter and Alexandrescu, C++ Coding Standards

    Programs must be written for people to read, and only incidentally for machines to execute.

    --
    Harold Abelson and Gerald Jay Sussman

    The cheapest, fastest and most reliable components of a computer system are those that aren't there.
    -- Gordon Bell


  8. #8
    Join Date
    May 2000
    Location
    KY, USA
    Posts
    18,652

    Re: Is memento a good design decision here?

    Quote Originally Posted by cvogt61457
    What is momento?

  9. #9
    Join Date
    Sep 2004
    Posts
    561

    Re: Is memento a good design decision here?

    I think it's novel use of Memento, and would probably work. It may be overkill, though - is there a reason why you can't just keep a "dirty" flag in the dialog class? You don't say what OS you're using, but Windows controls will notify you if they change, and you could use that notification to record that the dialog has changed.
    Thanks Graham.

    You are right, memento is overkill.
    I am using Windows ... I never realized that windows controls will notify me if they change. I'll look into this in more detail.

    Thanks!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  





Click Here to Expand Forum to Full Width

Featured