Architecture Question

I'm writing a program that (currently) uses a console text field thing for "graphical output" (the actual graphics are not important to me and will be rewritten later when I actually have the patience to learn the Windows API) and, in my latest experiment, uses message passing between objects, including to the graphical interface. The message system was done so that the graphical interface could be drastically rewritten without changing too much of anything else. At any rate, the messages passed to the graphics control object are pointers to objects inheriting from a base message class that use virtual function and whatnot to determine what to do. The base message class has an abstract virtual (pure virtual?) function called "execute", and the graphics controller's message pump simply calls execute and passes a reference to the text field as an argument; the message's execute function then does the actual drawing. So, before I bombard you with code, the question is: Is this awesome OOP, or psychotic OOP? Any suggestions?

Exhibit A: The message receiver/processor base class (it's a template so I can be flexible about message types later), with all the implementations cut out for readability:

Code:

---

template <class MessageType>
class MessageReceiver {
public:
    // adds a message to this receiver's queue
    void fileMessage(MessageType message);

    // processes all messages
    // does nothing by default
    void processMessages(); // is this OK? it seems to work all right...
protected:

    // pops next message and returns it
    MessageType getNextMessage();

    // returns true if the message queue is not empty
    bool messagesWaiting() const;

    // queue to hold messages
    std::deque<MessageType> MessageQueue;
};

---

Exhibit B: The base graphics message class, the graphical controller class, and a sample derived graphical message type, in that order. The implementations of processMessages() and execute have been spliced in:

Code:

---

// graphics command message base class
class GraphConMessage {
public:
    virtual void execute(TextField & to) = 0;
};

// graphics controller class
// send it GraphConMessages, and it processes them
class GraphCon : public MessageReceiver<GraphConMessage *> {
public:
    void processMessages() {
          // pump message queue until it's empty
          while (messagesWaiting()) {
              GraphConMessage * message = getNextMessage();
              message->execute(field);
              delete message;
          };
    };

protected:
    TextField field;
};


class GraphConM_SETSPOT : public GraphConMessage {
public:
    void execute(TextField & to) {
          to.setSpot(x, y, s);
    };

    GraphConM_SETSPOT(const int _x, const int _y, const char _s);
private:
    int x, y;
    char s;
};

---

Exhibit C: A sample message transmission to a GraphCon:

Code:

---

    GraphCon * gfx = new GraphCon;

    // sends a message to place "!" at coords 20,20
    gfx->fileMessage(new GraphConM_SETSPOT(20,20,'!'));

    // has the GraphCon process all the messages in its queue
    gfx->processMessages();

    delete gfx;

---

Sorry to bombard you with so much code. It works, but I'm not sure whether I'm crazy or creative. Comments?

>Is this awesome OOP, or psychotic OOP?
Good OOP. :) Decouping the messages from the graphics is a good idea, as is decoupling any components of a system since it encourages flexibility, ease of extension, and scalability, and I don't see any obvious problems with your example implementation, though for complex messages you may find the execute() interface lacking. I can see a lot of specialized messages being defined to overcome that minor lack of flexibility, but that's not really a huge issue, and any workarounds would be just as awkward.