Best design pattern for switching between hardware interfaces - c++

Question

I am seeking advice about whether or not my current approach makes sense. If not, I'd like a recommendation about some type of design pattern than can be used to replace my current intuition.
My premise is that I have a camera that requries a frame grabber card with either a CameraLink or CoaXPress cable interface to connect to a PC. All communication and data transfer between the camera and computer must be controlled using the frame grabber card, so the coupling between these two physical hardware objects is very tight.
My problem is that I want to create a "Camera" object (for a GUI) which has-a "FrameGrabber" card object that it uses to acquire data and send/receive commands and data. However, I have many different frame grabber cards of many different types. Lets call them CoaxGrabberA, CoaxGrabberB, LinkGrabberA, and LinkGrabberB. The CoaxGrabbers require a different set of parameters for initialization, setters, and getters than the LinkGrabbers.
As a result, I think I need to use two levels of inheritance, but from everything I've read, inheritance should be used very rarely, and composition should be favored. As such, I am extremely doubting my design decisions, and seek some type of better design. Here's an example of some half-baked code. It's a bit lengthy, but the important part is the concept that CoaxGrabberA, CoaxGrabberB, LinkGrabberA, and LinkGrabberB are grandchildren of FrameGrabber, which must be accessible to Camera. Everything else is to fill in the meat for details you may need.
My goal is to, at runtime, select whichever framegrabber (of any make/model/interface) that I want to use for my Camera object. Furthermore, I want to easily access all of the member functions that are unique to that grandchild framegrabber type to modify the behavior of the hardware at runtime.
My question is "is there a particular design pattern to match my problem that I don't know about, which would make my life easier than using my naive, intuitive approach"
//-----------------------------------------
// Parent Class
//=========================================
class FrameGrabber {
public:
virtual void sendCommandString(std::string cmd) = 0;
virtual void startAcquisition() = 0;
virtual void stopAcquisition() = 0;
};
//-----------------------------------------
// Children Classes
//=========================================
class CoaxGrabber : FrameGrabber {
public:
//functions unique to coax grabbers
virtual void setCommAddress(int commAddress) = 0;
virtual void setStatusPort(int statusPort) = 0;
//functions universal to all grabbers
virtual void sendCommandString(std::string cmd) = 0;
virtual void startAcquisition() = 0;
virtual void stopAcquisition() = 0;
protected:
int _commAddress;
int _statusPort;
};
class LinkGrabber : FrameGrabber {
public:
//functions unique to link grabbers
virtual void setBaudRate(int baudRate) = 0;
virtual void setNumChannels(int numChannels) = 0;
//functions universal to all grabbers
virtual void sendCommandString(std::string cmd) = 0;
virtual void startAcquisition() = 0;
virtual void stopAcquisition() = 0;
protected:
int _baudRate;
int _numChannels;
};
//-----------------------------------------
// Grandchildren Classes
//=========================================
class CoaxGrabberA : public CoaxGrabber {
//identical public members as CoaxGrabber
//different implementation using
//different low-level API, ex: BitFlow
}
class CoaxGrabberB : public CoaxGrabber {
//identical public members as CoaxGrabber
//different implementation using
//different low-level API, ex: Kaya
}
class LinkGrabberA : public LinkGrabber {
//identical public members as LinkGrabber
//different implementation using
//different low-level API, ex: NationalInstruments
}
class LinkGrabberB : public LinkGrabber {
//identical public members as LinkGrabber
//different implementation using
//different low-level API, ex: Imperx
}
//-----------------------------------------------------
// Finally, my Camera object, nothing too interesting here
//=====================================================
class Camera {
public:
Camera() {
_frameGrabber = NULL;
}
~Camera() {
delete _frameGrabber;
}
void setGrabber(FrameGrabber* newGrabber)
{
delete _frameGrabber;
_frameGrabber = newGrabber;
}
void startAcquisition() {
_frameGrabber.startAcquisiton();
}
void stopAcquisition() {
_frameGrabber.stopAcquisition();
}
int setSensitivity(int sens) {
_frameGrabber.sendCommandString("sens=" + std::to_string(sens));
}
private:
FrameGrabber* _frameGrabber;
};
//-----------------------------------------
// This is why I don't like my Camera object
// the actual end-user interface smells
//=========================================
class CameraGui : QMainWindow
{
public:
void setGrabberType(int type);
void setCoaxGrabberCommAddress(int address);
void setLinkGrabberBaudRate(int rate);
CameraSystem _myCamera;
CoaxGrabber* _myCoaxGrabber;
LinkGrabber* _myLinkGrabber;
};
//---------------------------------------------------------------
//This function smells to me, but I cannot think of any other way
//of course, int type will be enum in actual program.
//===============================================================
void CameraGui::setGrabberType(int type) {
switch (type) {
case 0:
delete _myCoaxGrabber;
_myCoaxGrabber = new CoaxGrabberA();
_myCamera.setGrabber(&_myCoaxGrabber);
break;
case 1:
delete _myCoaxGrabber;
_myCoaxGrabber = new CoaxGrabberB();
myCamera.setGrabber(&_myCoaxGrabber));
break;
case 2:
delete _myLinkGrabber;
_myLinkGrabber = new LinkGrabberA();
_myCamera.setGrabber(&_myLinkGrabber);
break;
case 3:
delete _myLinkGrabber;
_myLinkGrabber = new LinkGrabberB();
_myCamera.setGrabber(&_myLinkGrabber);
break;
}
}
//---------------------------------------------------------------
// this method of setting parameters also smells to me,
// since this data is linked to the Camera object, which
// will have no way of knowing whether the state of its
// framegrabber changed... furthermore, if I change framegrabbers,
// none of the parameter settings (state) will be remembered.
// the user will need to set them all over again.
// the only way I know to circumvent this is to allocate memory for
// every type of framegrabber, and broadcast all state changes to
// all applicable parent grabbers, which will reside in permanent
// memory until the application closes.
//===============================================================
void CameraGui::setCoaxGrabberCommAddress(int address) {
if(myCoaxGrabber != NULL) {
myCoaxGrabber->setCommAddress(address);
}
}
//likewise smell
void CameraGui::setLinkGrabberBaudRate(int rate) {
if(myLinkGrabber != NULL) {
myLinkGrabber->setBaudRate(rate);
}
}
Any and all advice will be greatly appreciated. Long story short, I know little about OO design patterns, but this feels like a solved problem and I feel like I'm reinventing the wheel. Is there a better, more established way to implement what I am trying to do?

Answer 1

Your design pattern is called "factory" and there is nothing wrong with inheritance (https://en.wikipedia.org/wiki/Factory_method_pattern)
The rule of thumb what we should use when choose between inheritance and aggregation:
if something reflect "is" relationship (e.g. CoaxGrabber is FrameGrabber) use inheritance.
if something reflect "has" relationship (e.g. CameraGui has FrameGrabber) use aggregation.
I would recommend using smart pointers (e.g. std::shared_ptr) instead of new and delete what is currently using this will make code more manageable and less error prone.
In this case:
class Camera {
public:
CameraSystem() {} // don't need explicit initialization
~CameraSystem() {} // resource in shared_ptr will be deleted automatically
void setGrabber(const std::shared_ptr<FrameGrabber>& newGrabber)
{
_frameGrabber = newGrabber;
}
void startAcquisition() {
_frameGrabber->startAcquisiton(); // note -> instead of .
}
// ....
private:
std::shared_ptr<FrameGrabber> _frameGrabber;
};
And in case of using the factory:
void CameraGui::setGrabberType(int type) {
_myCamera.setGrabber(GrabberFactory::createGrabber(type));
}
class GrabberFactory {
public:
std::shared_ptr<FrameGrabber> createGrabber(int type) {
switch (type) {
case GrabberTypeCoaxA: return {new CoaxGrabberA()};
case GrabberTypeCoaxB: return {new CoaxGrabberB()};
default: throw std::invalid_argument("Invalid grabber type");
}
}
};

Answer 2

As a result, I think I need to use two levels of inheritance, but from
everything I've read, inheritance should be used very rarely, and
composition should be favored.
I can't tell if it can be done without knowing more details, but if you can it seems that it would help making the design cleaner if you would explitely define a Port interface and aggregate the port within FrameGrabber rather than having multiple FrameGrabber implementations. That would favor composition over inheritance and become an implementation of the Strategy pattern.
After that if you wish every ports to have their own specific API then the port settings UI will obviously have to be more complex because it will need to know how to deal with different concrete ports. What would help is to implement various PortSettingsView with a respective controller or view-model for each kind of ports. E.g. BitflowCoaxPortSettingsView driven by BitflowCoaxPortSettingsViewModel, etc. If you aren't familiar with MVC-like architectures I suggest you to learn about them.
The UI would only have to instantiate the proper concrete PortSettingsView and port settings view-model based on the port type. By doing that the view and view-models will always know which kind of port they are configuring making it easy to deal with port-specific behaviors.
There may be other alternatives as well. Perhaps a more abstract approach should be used for configuring ports so that all ports can be configured through the same API. For instance you may use a key-value pair data structure to hold configurations. All ports could then implement something like a public void reconfigure(PortSettings settings) method. I can't tell if it's suitable or not for your problem.
Finally, remember that it's always a good idea to abstract complex creation processes away using a factory. For instance, rather than having a switch statement over the port type directly in the UI to instantiate the correct view and view-model you could delegate that task to a factory.