Thread: Architecture Question

  1. #1
    Registered User
    Join Date
    Mar 2005
    Posts
    28

    Question 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?

  2. #2
    Code Goddess Prelude's Avatar
    Join Date
    Sep 2001
    Posts
    9,897
    >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.
    My best code is written with the delete key.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Debugging question
    By o_0 in forum C Programming
    Replies: 9
    Last Post: 10-10-2004, 05:51 PM
  2. Question about pointers #2
    By maxhavoc in forum C++ Programming
    Replies: 28
    Last Post: 06-21-2004, 12:52 PM
  3. Question...
    By TechWins in forum A Brief History of Cprogramming.com
    Replies: 16
    Last Post: 07-28-2003, 09:47 PM
  4. Question about linked lists.
    By cheeisme123 in forum C++ Programming
    Replies: 6
    Last Post: 02-25-2003, 01:36 PM
  5. Question, question!
    By oskilian in forum A Brief History of Cprogramming.com
    Replies: 5
    Last Post: 12-24-2001, 01:47 AM