Re: Command Pattern used in Frameworks

From: Daniel T. (postmaster_at_eathlink.net)
Date: 06/24/04 

Date: Thu, 24 Jun 2004 02:18:16 GMT

In article <ecb3ca5c.0406190139.4cd8a47c@posting.google.com>,
 postingcow@yahoo.com (Posting Cow) wrote:

>I am using the command pattern(as described in the GoF book) in a
>project, where I'm also using MFC as the window manager framework. The
>implementation follows the pattern very closely, with macroCommands
>and undo/redo mechanism just like in the book(it evolved naturally,
>then I changed the function names to fit the literature). I have found
>a problem in interfacing one of the Command classes which changes the
>state of the document being edited with MFC in a way that would make
>it portable to other frameworks later. Here's a code simplification of
>what I mean:
>
>class CMyDocument : public CDocument{ //the MFC document class
>public:
> std::list<int> theList;
>};
>
>class AddNumberCommand : public command{ //the GoF command class
> void execute(){
> CMyDocument* doc = GetActiveDocument(); //here is the hack
> doc->theList.push_back(2);
> }
>};
>
>What I would like is to make the command class unaware of any
>framework classes, so porting from one framework to another will not
>involve recompiling my library. Also, adding another member function
>to AddNumberCommand(like getNumberToAdd() for example) would break the
>undo/redo mechanism, which only knows about execute(), undo() and
>redo() (it would have to test all command derived classes to see if it
>is an AddNumberCommand from it's RTTI and call the extra function,
>which is not the solution I'm looking for).
>
>Does anybody know a clean way to solve this problem?

class CMyDocument : public CDocument {
   std::list<int> itsList;
public:
   static CMyDocument* activeDocument() {
      return GetActiveDocument();
   }

   void add(int i) {
      itsList.push_back(i);
   }
};

class AddNumberCommand : public Command {
public:
   void execute() {
      CMyDocument::activeDocument()->add(2);
   }
};

Now if you change to a different window system other than MFC, you only
need to change CMyDocument (which you would have had to change anyway,)
instead of both CMyDocument and AddNumberCommand.

Of course, this pattern assumes that there will always be one, and only
one, active document when the Command::execute message is sent. That may
or may not be a valid constraint.

One is also left to wonder; if I create an AddNumberCommand while one
document is active, then change the active document, then execute the
command, which document is supposed to change? Something you might want
to seriously think about before discounting RCM's idea...

Relevant Pages

  • Re: Command Pattern used in Frameworks
    ... where I'm also using MFC as the window manager framework. ... >and undo/redo mechanism just like in the book(it evolved naturally, ... >a problem in interfacing one of the Command classes which changes the ...
    (comp.object)
  • Command Pattern used in Frameworks
    ... I am using the command pattern(as described in the GoF book) in a ... where I'm also using MFC as the window manager framework. ... a problem in interfacing one of the Command classes which changes the ...
    (comp.object)
  • RE: Sending mail directly from program
    ... To implement a Send Mail command with MFC: ... This command ID is provided by the framework in AFXRES.H. ...
    (microsoft.public.vc.mfc)
  • Re: Future of MFC?
    ... for it to be easy to port Win16 API code to the new framework, ... Yes, you are right, that was one of the prime benefits of using MFC. ... compared to the Ribbon libraries available for .NET. ...
    (microsoft.public.vc.mfc)
  • Re: Report from MVP Summit
    ... framework into existing apps using C++/CLI). ... with MFC and native code. ... It's not just Microsoft that is leaving MFC but 3rd parties like component ... of C++ is to have more tools to grok millions lines of code (useless to me), ...
    (microsoft.public.vc.mfc)
Loading