Design Patterns – Using Command Pattern and Dependency Injection Together

cdesign-patternsobject-oriented-design

I have many projects that have essentially the same high level requirement: test all hardware on a device. Each device can have a different communication protocol, requires different test equipment to exercise the device, etc. So, at a high level a test is essentially the following:

obtain handles to test equipment
apply stimulus to device
measure/detect/record something measurable
remove stimulus
store results
handle errors

I thus created an interface class ( CTestEquipment ) as every piece of test equipment can be a concrete class with a unique implementation. The device under test can be considered a piece of test equipment as well. I'm using Dependency Injection for the driver of the test equipment. This is to allow for easy changes from one driver to another and to keep the driver and the equipment somewhat decoupled. For instance, a power supply might use a GPIB driver, a VISA driver, or raw serial commands. Each project can choose which is applicable and change one line ( the driver instantiation ).

Next, I created classes to implement the Command pattern for the test equipment/device. So, CTestEquipment inherits from CCmdReceiver. A concrete command class calls the execute method which via the receiver calls the test equipment's tx/rx methods. Those methods call the underlying driver.

Questions/Problems:
How do I extract the received data from the command? Right now execute has no arguments and returns nothing. A concrete command might only transmit, only receive, or do both so the execute interface needs to either return a value even when there's no received data or some other way I need to be able to access it. CSetSerialNumber has no received data. CGetMode does.

Since the command is calling tx/rx which ultimately calls the driver's tx/rx how do I package the data to those calls since each driver could take something different? I've contemplated a CPacket interface and various concrete implementations but then how do I make sure passing a concrete class that doesn't match the driver is caught?

//--------------------------------------------------------------------------------------
// CCommand
//      Abstract interface that defines the execute method
//--------------------------------------------------------------------------------------
class CCommand
{
protected:
CCmdReceiver *      _rcvr_p;            // receiver interface

// Default Constructor
CCommand()
{}

public:
// Constructor
CCommand
    (
    CCmdReceiver *  r               // receiver interface
    ) :
   _rcvr_p      ( r )
{}

// Destructor
virtual ~CCommand()
{}

// Method to Execute the Command
virtual void execute() = 0;
};

//--------------------------------------------------------------------------------------
// CCmdReceiver
//      Abstract interface that defines the command action
//--------------------------------------------------------------------------------------
class CCmdReceiver
{
public:
virtual void flush() = 0;

virtual void rx( std::vector< unsigned char > & v ) = 0;

//virtual void tx( std::string const & s ) = 0;
virtual void tx( CPacket * p ) = 0;
};

/*------------------------------------------------------------------------------
Test equipment driver abstract base class
------------------------------------------------------------------------------*/
class CDriver
{
public:
/*--------------------------------------------------------------------------
Constructor
--------------------------------------------------------------------------*/
CDriver() :
    _is_open            ( false )
{}

/*--------------------------------------------------------------------------
Destructor
--------------------------------------------------------------------------*/
virtual ~CDriver()
{}

//protected:
/*--------------------------------------------------------------------------
Close the Driver
    Must be implemented in a derived class
--------------------------------------------------------------------------*/
virtual void close() = 0;

/*--------------------------------------------------------------------------
Get the Received Data
--------------------------------------------------------------------------*/
template< typename tVal >
tVal getRxData();

/*--------------------------------------------------------------------------
Determine if the Driver is Open
--------------------------------------------------------------------------*/
virtual bool isOpen()
{
return( _is_open );
}

/*--------------------------------------------------------------------------
Open the Driver
    Must be implemented in a derived class
--------------------------------------------------------------------------*/
virtual void open() = 0;

/*--------------------------------------------------------------------------
Receive Data
--------------------------------------------------------------------------*/
virtual void rx()
{}

/*--------------------------------------------------------------------------
Set Open/Closed Flag State
--------------------------------------------------------------------------*/
inline void setOpenState
    (
    bool const & open = true
    )
{
_is_open = open;
}

/*--------------------------------------------------------------------------
Transmit Data
--------------------------------------------------------------------------*/
virtual void tx
    (
    std::string const & cmd         // command to transmit
    )
{}

private:
bool    _is_open;           // flag to indicate if protocol is open
};

//--------------------------------------------------------------------------------------
// Abstract Test Equipment Class
//      Utilizes constructor DI for device driver
//      Utilizes RAII for open/close
//--------------------------------------------------------------------------------------
class CTestEquipment : public CCmdReceiver
{
public:
/// Constructor
CTestEquipment
    (
    boost::shared_ptr< CDriver > const &
                drvr        // device driver
    ) :
    _drvr           ( drvr ),
    _init_cnt           ( 0 )
{
_drvr->open();
incInitCnt();
}

/// Destructor
virtual ~CTestEquipment()
{
if( isInitialized() )
     {
     _drvr->close();
     }
}

/// Function to Access the Equipment's Driver
inline boost::shared_ptr< CDriver > const & accessDriver() const
{
return( _drvr );
}   // accessDriver()

/// Decrement the Initialization Count
inline void decInitCnt()
{
--_init_cnt;
}   // decInitCnt()

/// Get the Initialization Count
inline int getInitCnt() const
{
return( _init_cnt );
}   // getInitCnt()

/// Increment the Initialization Count
inline void incInitCnt()
{
++_init_cnt;
}   // incInitCnt()

/// Check if Initialization has Occurred
inline bool isInitialized() const
{
return( _init_cnt >= 1 );
}   // isInitialized()

/// Determine if the Driver is Open
inline bool isOpen() const
{
return( _drvr->isOpen() );
}   // isOpen() 

 protected:
/// Reset the Equipment
virtual void reset()
{
//_drvr->reset();
}

/// Function to Receive Data from the Equipment
inline void rx()
{
_drvr->rx();
}

/// Function to Set the Device to a Default State
virtual void setToDflts()
{}

/// Function to Transmit a Command to the Equipment
inline void tx( std::string const & cmd )
{
_drvr->tx( cmd );
}

/// Function to Transmit a Command, Receive the Response, and Return the Parsed    Value
template< typename tVal >
tVal txRx
    (
    std::string const & cmd         // command to transmit
        )
{
_drvr->tx( cmd );
_drvr->rx();

return( _drvr->getRxData< tVal >() );
}

protected:
boost::shared_ptr< CDriver > const &
        _drvr;              // device driver
int     _init_cnt;          // initialization count
};

class CGetMode : public CCommand
{
public:
CGetMode
    (
    CCmdReceiver *  rcvr            // command receiver
    );

void execute()
    {
    // G: what type is cmd?
    // G: what type is buffer?
    // G: how do we access buffer?
    _rcvr_p->flush();
    _rcvr_p->tx( cmd );
    _rcvr_p->rx( buffer );
    }
 };

//--------------------------------------------------------------------------------------
// CSetSerialNumber
//     Extends command interface. Implements the execute method and invokes it on a receiver.
//--------------------------------------------------------------------------------------
class CSetSerialNumber : public CCommand
{
public:
// Constructor
CSetSerialNumber
    (
    CCmdReceiver *  rcvr                // command receiver
    );

void execute()
    {
    // G: what type is cmd?
    _rcvr_p->tx( cmd );
    }
};

Best Answer

You need a data transfer protocol. It can be as simple as a string with comma-separated values, or as complex as some XML backed up by a schema. Whatever you decide, the receiver will have to be smart enough to decode it.

As an example, one of your commands could retrieve a comma-separated header:

TIME, ALTITUDE, TEMPERATURE, AIRSPEED, WHATEVER

This tells you not only the name of each signal, but how many signals there are. You can use this information to set up your decoder on the receiver side.

You could also use something like Protocol Buffers.

Related Solutions

C++ – the pattern for a safe interface in C++

The canonical way to create an interface in C++ is to give it a pure virtual destructor. This ensures that

No instances of the interface class itself can be created, because C++ does not allow you to create an instance of an abstract class. This takes care of the not constructible requirements (both default and copy).
Calling delete on a pointer to the interface does the right thing: it calls the destructor of the most-derived class for that instance.

just having a pure virtual destructor doesn't prevent assignment on a reference to the interface. If you need that to fail as well, then you must add a protected assignment operator to your interface.

Any C++ compiler should be able to handle a class/interface like this (all in one header file):

class MyInterface {
public:
  virtual ~MyInterface() = 0;
protected:
  MyInterface& operator=(const MyInterface&) { return *this; } // or = default for C++14
};

inline MyInterface::~MyInterface() {}

If you do have a compiler that chokes on this (which means it must be pre-C++98), then your option 2 (having protected constructors) is a good second-best.

Using boost::noncopyable is not advisable for this task, because it sends the message that all classes in the hierarchy should be non-copyable and it can thus create confusion for more experienced developers who wouldn't be familiar with your intentions for using it like this.

C++ – How to store various sized values in a vector

Firstly, command classes are decoupled from the medium and protocol. That means you can design the command classes for your own programming convenience, rather than having to design it to match exactly to the specifics of each protocol (which would be impossible, since different protocols may have different bit widths for the same command and field).

When I mention convenience, what I mean is that you can use the maximum bit width you'll ever need for each command's fields.

However, you may still need to have device- or protocol-specific validation code, since each device or protocol imposes its own limits to what values can be in those fields. Unless you don't plan to implement any validation at all.

When it comes to validation, there are several choices:

Not doing it at all, if you will be doing all of the programming yourself, and if it is a hobby project such that mistakes do not result in damages.
Validating it eagerly, i.e. in the command class. This may be difficult, since a command class might not know which device or protocol it will be sent to.
Validating it late, i.e. in the protocol class where the command values are being converted into bytes.

For example, even if a validation rule says that a particular field can only have a value in the range 0 - 100, it doesn't stop you from using a uint32_t or int32_t for that field in the command class.

To the second question of having an overloaded method that takes in various built-in number types and append the bytes to an internal byte vector, do notice the caveats.

In my opinion, if you only needs to work with the fundamental integer types, you don't need templates. Instead, you simply provide function overloads for each of the types, and you call the functions with a value of the appropriate type.

void CPacket::addData(uint32_t data) { ... }
void CPacket::addData(int32_t data) { ... }
void CPacket::addData(uint16_t data) { ... }
void CPacket::addData(int16_t data) { ... }
...

Regarding the code inside, there are several choices:

Type punning with union. This assumes that your code will work exclusively with one byte-endianness, thus not needing to consider the possibility of porting to a different byte-endianness.

union
{
    uint32_t value;
    uint8_t bytes[4];
} pun = { data };
// after that, add the bytes to the vector one-by-one, according to the byte endianness of the communication.

Explicitly extracting the bytes with endian-agnostic bitwise arithmetic: (see note on casting)

// only if value is unsigned. For signed value, it must first be cast to unsigned
uint8_t byte0 = (uint8_t)value;
uint8_t byte1 = (uint8_t)(value >> 8ul);
uint8_t byte2 = (uint8_t)(value >> 16ul);
uint8_t byte3 = (uint8_t)(value >> 24ul);

Best Answer

Related Solutions

C++ – the pattern for a safe interface in C++

C++ – How to store various sized values in a vector

Related Topic