硬件接口切换的最佳设计模式

Question

我正在寻求关于我目前的做法是否有意义的建议。如果不是，我想要一个关于某种类型的设计模式的建议，可以用来代替我目前的直觉。

，我的前提是，我有一个相机，它需要一个带有CameraLink或CoaXPress电缆接口的帧抓取卡来连接到PC上。摄像机和计算机之间的所有通信和数据传输都必须使用帧采集卡来控制，因此这两个物理硬件对象之间的耦合非常紧密。

我的问题是，我想创建一个"Camera“对象(用于GUI)，它有一个"FrameGrabber”卡片对象，它用来获取数据以及发送/接收命令和数据。然而，我有许多不同的帧抓取卡的许多不同类型。让我们称它们为CoaxGrabberA、CoaxGrabberB、LinkGrabberA和LinkGrabberB。CoaxGrabbers需要一组与LinkGrabbers不同的参数来进行初始化、设置和获取。

因此，我认为我需要使用两个级别的继承，但从我所读到的所有内容来看，继承应该很少使用，而且组合应该受到青睐。因此，我非常怀疑我的设计决策，并寻求某种类型的更好的设计。下面是一些半生不熟的代码的例子。这有点长，但重要的是，CoaxGrabberA、CoaxGrabberB、LinkGrabberA和LinkGrabberB是FrameGrabber的孙子，相机必须可以访问它们。其他的一切都是为了得到你可能需要的细节。

我的目标是，在运行时，选择我想要用于相机对象的任何框架抓取器(任何make/model/接口)。此外，我想轻松地访问所有的成员函数，这些成员函数是那个外孙framegrabber类型所特有的，可以在运行时修改硬件的行为。

我的问题是：“是否有一种特殊的设计模式来匹配我不知道的问题，这将使我的生活比使用我天真、直观的方法更容易。”

//-----------------------------------------
// 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);
    }
}

如有任何建议，我们将不胜感激。长话短说，我对OO设计模式知之甚少，但这感觉像是一个解决了的问题，我觉得我在重新发明轮子。是否有更好、更可靠的方法来实现我正在努力做的事情？

Answer 1

您的设计模式称为“工厂”，继承没有任何问题(模式)。

在继承和聚合之间进行选择时，我们应该使用的经验法则：

• 如果某些内容反映了" is“关系(例如，CoaxGrabber是FrameGrabber)，则使用继承。
• 如果某些内容反映了“有”关系(例如，CameraGui有FrameGrabber)，则使用聚合。

我建议使用智能指针(例如std::shared_ptr)而不是新的和删除当前使用的指针，这将使代码更易于管理，更容易出错。

在这种情况下：

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;
};

在使用工厂时：

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

因此，我认为我需要使用两个级别的继承，但从我所读到的所有内容来看，继承应该很少使用，而且组合应该受到青睐。

在不了解更多细节的情况下，我无法判断是否可以这样做，但如果可以的话，如果您能够明确定义Port接口并在FrameGrabber中聚合端口，而不是有多个FrameGrabber实现，似乎会有助于使设计变得更简洁。这将有利于组合而不是继承，并成为战略模式的实现。

之后，如果希望每个端口都有自己的特定API，那么端口设置UI显然必须更加复杂，因为它需要知道如何处理不同的具体端口。对于每种端口来说，使用相应的控制器或视图模型来实现各种PortSettingsView是有帮助的。例如，BitflowCoaxPortSettingsView由BitflowCoaxPortSettingsViewModel驱动，等等。如果您不熟悉类似MVC的体系结构，我建议您了解它们。

UI只需根据端口类型实例化适当的具体PortSettingsView和端口设置视图模型。通过这样做，视图和视图模型将始终知道它们正在配置的是哪种端口，从而使处理特定于端口的行为变得更加容易。

也许还有其他的选择。也许应该使用更抽象的方法来配置端口，以便所有端口都可以通过相同的API进行配置。例如，您可以使用键值对数据结构来保存配置。然后，所有端口都可以实现类似于public void reconfigure(PortSettings settings)方法的东西。我不知道适合不适合你的问题。

最后，请记住，使用工厂抽象复杂的创建过程总是一个好主意。例如，与其在UI中的端口类型上直接使用开关语句来实例化正确的视图和视图模型，不如将该任务委托给工厂。