Question

我正在努力学习基于政策的课堂设计。现在我有了两种不同的策略类实现相互依赖。这意味着，第二个策略实现（GLFWInputHandler）依赖于特定的内部第一个实现（GLFWVideoModeSetter）。也就是说，因为视频模式设置和输入处理是内部的使用GLFW-Framework实现.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;
}

Answer 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，...）你可以将任何输入与任何哈希算法结合起来。

如何设计相互依赖的策略类实现

1 个答案: