【问题标题】:how to design policy-class-implementations that depends on each other如何设计相互依赖的策略类实现
【发布时间】:2018-05-28 14:40:39
【问题描述】:

我正在尝试学习基于策略的类设计。现在我有一个案例,即 2 个不同的策略类实现 相互依赖。这意味着,第二个策略实现(GLFWInputHandler)取决于特定的内部 第一个实现(GLFWVideoModeSetter)。也就是说,因为视频模式设置和输入处理在内部 使用 GLFW 框架实现。 InputHandler 需要一个具体的 glfwWindow,它由 VideoModeSetter 创建。

首先,这是一个最小的、可编译的示例 两个策略类实现之间没有依赖关系。 这里一切都很好。

struct GLFWVideoModeSetter { void setVideoMode() {} };

template <class VideoModeSettingPolicy>
struct VideoModeManager : public VideoModeSettingPolicy {};

struct GLFWInputHandler { bool handleKeys() { return true; } };

template <class InputHandlerPolicy>
struct InputHandlerManager : public InputHandlerPolicy { };

int main()
{
    VideoModeManager<GLFWVideoModeSetter> oVideoManager;
    oVideoManager.setVideoMode();

    InputHandlerManager<GLFWInputHandler> oInputHandlerManager;
    oInputHandlerManager.handleKeys();
    return 0;
}

现在我正在寻找一种解决方案来扩展上述代码,而不会失去基于策略的灵活性, 以便 GLFWInputHandler 和 GLFWVideoModeSetter 以某种方式连接,使 GLFWInputHandler 能够 获取glfwWindow。我的第一个解决方案是,将 GLFWInputHandler 模板化,然后专门化 InputHandlerManager,但感觉不正确 这样。您将如何处理这种依赖关系?

struct glfWindow {};

struct GLFWVideoModeSetter
{
    void setVideoMode() {}
    glfWindow *getGLFWWindow() { return new glfWindow(); }; //GLFWInputHandler depends on this -> glfWindow
};

template <class VideoModeSettingPolicy>
struct VideoModeManager : public VideoModeSettingPolicy {};

template <class T_GLFW_WINDOW_GETTER>
struct GLFWInputHandler
{
    GLFWInputHandler(T_GLFW_WINDOW_GETTER &refWindowGetter) : ptrWindowGetter(&refWindowGetter) {}
    bool handleKeys() { return true; }
private:
    T_GLFW_WINDOW_GETTER *ptrWindowGetter;
};

template <class InputHandlerPolicy>
struct InputHandlerManager : public InputHandlerPolicy {};

template <>
struct InputHandlerManager<GLFWInputHandler<VideoModeManager<GLFWVideoModeSetter>>> : public GLFWInputHandler<VideoModeManager<GLFWVideoModeSetter>>
{
    InputHandlerManager(VideoModeManager<GLFWVideoModeSetter> &refWGType) : GLFWInputHandler<VideoModeManager<GLFWVideoModeSetter>>(refWGType) {}
};


int main()
{
    VideoModeManager<GLFWVideoModeSetter> oVideoManager;
    oVideoManager.setVideoMode();

    InputHandlerManager<GLFWInputHandler<VideoModeManager<GLFWVideoModeSetter>>> oInputHandlerManager(oVideoManager);
    oInputHandlerManager.handleKeys();

    return 0;
}

【问题讨论】:

    标签: c++ templates dependencies policy


    【解决方案1】:

    难道任何输入处理程序都需要一个特定的窗口来发布输入吗?如果是这样,我宁愿推荐以下内容:

    首先,将输入处理程序保持为普通类。无论如何,我们都在 GLFW 框架内,直接获取 GLFWVideoModeSetter 没有问题:

    struct GLFWInputHandler
    {
        GLFWInputHandler(GLFWVideoModeSetter& windowGetter) : windowGetter(windowGetter) {}
        bool handleKeys() { return true; }
    private:
        GLFWVideoModeSetter& windowGetter; // why a pointer, by the way???
    };
    

    现在的问题是,您需要一个合适的 InputHandlerManager 构造函数。第一个变体:我们假设任何输入处理程序都需要特定的视频模式设置器(至少是某种显示获取器):

    template <class InputHandlerPolicy>
    struct InputHandlerManager : public InputHandlerPolicy
    {
        template<class VideoModeGetter>
        InputHandlerManager(VideoModeGetter& vmg)
            : InputHandlerPolicy(vmg)
        { };
    };
    

    用法:

    VideoModeManager<GLFWVideoModeSetter> vm;
    InputHandlerManager<GLFWInputHandler> ihm(vm); // can still pass directly as VMM inherits from the policy...
    

    如果您担心可能需要更大的灵活性,您可以使用可变参数模板方法拥有更通用的构造函数:

    template <class InputHandlerPolicy>
    struct InputHandlerManager : public InputHandlerPolicy
    {
        template<typename ... Parameters>
        InputHandlerManager(Parameters ... parameters)
            : InputHandlerPolicy(parameters ...)
        { };
    };
    

    在具体案例中的用法保持不变,但使用一些不同的策略,您可以提供不同的参数:

    VideoModeManager<XVideoModeSetter> vm;
    InputHandlerManager<XInputHandler> ihm; // does not need a parameter at all
    
    VideoModeManager<YVideoModeSetter> vm;
    InputHandlerManager<YInputHandler> ihm(vm, 7); // needs an additional parameter
    

    但不确定这是否符合基于策略的设计的精神:PBD 通常应该允许您使用不同策略的任意组合,但 GLFWInputHandler 始终依赖于 GLFW 窗口,因此依赖于 GLFW VMS,因此您在这种情况下总是建立成对的策略...

    获取键的部分从输入处理程序移动到视频模式设置器并将键作为参数传递给输入处理程序可能更合适,可能还提供一些回调(s /-object) 到 IH,以便它可以在 VMS 上引起适当的反应。可能 InputHandler 不再需要任何策略了。如果您需要策略,您可能希望能够更改对不同键的反应,但独立您从哪个框架获取它们...

    您可能希望拥有不同策略的反例:假设您有不同的数据提供者策略(来自文件、数据库、用户输入......)并且想要计算签名 - 所以您有另一个策略系列(md5 , sha, ...) 并且您可以将任何输入与任何哈希算法相结合。

    【讨论】:

    • 感谢您的努力!这对我很有帮助。不知道,您可以将可变参数模板与 ctor 结合使用。现在,我将使用 variadic 解决方案,同时理解,这可能不是最好的方法。我在实现中使用了一个指针,让类仍然是可复制的,但你可能是对的,说成员引用就足够了。
    猜你喜欢
    • 2013-05-29
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多