Question

I’m writing a tool which enables a user to interact with a bit of hardware by changing settings and then streaming information.

To do this I have a couple of threads running: EquipmentInterface and DataProcessor which are connected by a Queue.

The EquipmentInterface thread has methods to alter settings on the equipment (Rotate and Refocus for example) and the resulting information (CurrentAngle and CurrentFocalDistance) is added to the Queue. Once the settings are correct there are methods to StartStreaming and StopStreaming and once streaming starts, data from the equipment is packetised and added onto the queue.

All of the information placed on the queue derives from a single BaseMessage class which includes an indication of the message type. I then have derived message types for angles, focal distances, beginning and ending streaming and of course, the data itself.

The DataProcessor listens to the other end of the Queue and depending on the current angle / focal distance, processes the subsequent data.

Now, the thing is, I have a function in the data processor which uses a switch statement to type-check the messages coming in. Those messages are then down-casted to the appropriate type and passed to an appropriate handler. In reality, there’s more than just a DataProcessor listening to a single queue, but in fact multiple listeners on multiple queues (some store to disk, some display information on a gui). Every time I add some information I have to create a new BaseMessage derived class, add a new type to that base class and then update the switch statements in each of the consumers to cope with the new message.

Something about this architecture feels wrong to me and I’ve been reading a lot about down-casting recently. From what I’ve seen, the general consensus seems to be that what I’m doing is a bad code smell. I’ve seen a suggestion which use Boost, but they don’t look any cleaner than the switch statement to me (maybe I’m missing something?).

So my question is: Should I be trying to avoid the switch-statement / downcasting solution and if so, how?

My implementation is in C++/CLI so either .net or C++ solutions are what I’m after.

Edit – Based on the comments from iammilind and stfaanv, is this the sort of thing you’re suggesting:

class QueuedItem
{
public:
    QueuedItem() { }
    virtual ~QueuedItem() { }

};

class Angle : public QueuedItem
{
public:
    Angle() {}
    virtual ~Angle() { }
};

class FocalLength : public QueuedItem
{
public:
    FocalLength() {}
    virtual ~FocalLength() { }
private:

};


class EquipmentHandler
{
protected:
    virtual void ProcessAngle(Angle* angle) {}; 
    virtual void ProcessFocalLength(FocalLength* focalLength) {};   

public:
    void ProcessMessages(QueuedItem* item)
    {
        Angle* pAngle = dynamic_cast<Angle*>(item);
        if( pAngle != NULL )
        {
            ProcessAngle(pAngle);
        }
        FocalLength* pFocalLength = dynamic_cast<FocalLength*>(item);
        if( pFocalLength != NULL )
        {
            ProcessFocalLength(pFocalLength);
        }

    }
};

class MyDataProcessor : public EquipmentHandler
{
protected:
    virtual void ProcessAngle(Angle* angle) override { printf("Processing Angle"); }
    virtual void ProcessFocalLength(FocalLength* focalLength) override { printf("Processing FocalLength"); };   
};


int _tmain(int argc, _TCHAR* argv[])
{

    // Equipment interface thread...
    FocalLength* f = new FocalLength();
    QueuedItem* item = f; // This gets stuck onto the queue

    // ...DataProcessor thread (after dequeuing)
    QueuedItem* dequeuedItem = item;

    // Example of a DataProcessor implementation.
    // In reality, this would 
    MyDataProcessor dataProc;
    dataProc.ProcessMessages(dequeuedItem);

    return 0;
}

…and can it be simplified? The ProcessMessages feels a bit clunky but that’s the only way I could see to do it without a switch statement and some sort of enumerated message type identifier in the base class.

Answer 1

You could try a visitor design pattern: http://en.wikipedia.org/wiki/Visitor_pattern

Each DataProcessor would inherit from a BaseVisitor class, which defines virtual method for handling each type of Message. Basically these methods are just noop.

When you define a new message type you add a new virtual method with a noop implementation for this message type in the BaseVisitor. Then if a child DataProcessor class wants to process this message type you override the virtual method in this DataProcessor only. All other DataProcessorremain untouched.

    #include <iostream>


    class FocalLength;
    class Angle;
    class EquipmentVisitor;

    class QueuedItem
    {
    public:
            QueuedItem() { }
            virtual ~QueuedItem() { }

            virtual void AcceptVisitor(EquipmentVisitor& visitor) = 0;
    };

    class EquipmentVisitor
    {
    public:
            virtual ~EquipmentVisitor() {}

            virtual void Visit(FocalLength& item) {}
            virtual void Visit(Angle& item)       {}

            void ProcessMessages(QueuedItem* item)
            {
                    item->AcceptVisitor(*this);
            }
    };

    class Angle : public QueuedItem
    {
    public:
            Angle() {}
            virtual ~Angle() { }

            void AcceptVisitor(EquipmentVisitor& visitor) { visitor.Visit(*this); }
    };

    class FocalLength : public QueuedItem
    {
    public:
            FocalLength() {}
            virtual ~FocalLength() { }

            void AcceptVisitor(EquipmentVisitor& visitor) { visitor.Visit(*this); }
    private:

    };

    class MyDataProcessor : public EquipmentVisitor
    {
    public:
            virtual ~MyDataProcessor() {}

            void Visit(Angle& angle)             { std::cout << "Processing Angle" << std::endl; }
            void Visit(FocalLength& focalLength) { std::cout << "Processing FocalLength" << std::endl; }
    };


    int main(int argc, char const* argv[])
    {
            // Equipment interface thread...
            FocalLength* f    = new FocalLength();
            QueuedItem*  item = f; // This gets stuck onto the queue

            // ...DataProcessor thread (after dequeuing)
            QueuedItem* dequeuedItem = item;

            // Example of a DataProcessor implementation.
            // In reality, this would
            MyDataProcessor dataProc;
            dataProc.ProcessMessages(dequeuedItem);

            return 0;
    }