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

Question

我正在尝试学习基于策略的 class 设计。现在我遇到了这种情况，即 2 种不同的策略-class-实现相依为命。这意味着，第二个策略实现（GLFWInputHandler）取决于特定的内部结构第一个实现（GLFWVideoModeSetter）。也就是说，因为视频模式设置和输入处理是内部的使用 GLFW-Framework.The InputHandler 实现需要一个具体的 glfwWindow，它由 VideoModeSetter 创建。

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

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

难道 any 输入处理程序需要特定的 window 到 post 输入吗？如果是这样，我宁愿推荐以下内容：

首先，保持输入处理程序正常class。无论如何我们都在 GLFW 框架内，直接获取 GLFWVideoModeSetter 没有问题：

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

现在的问题是，您的 InputHandlerManager 需要一个合适的构造函数。第一种变体：我们假设任何输入处理程序都需要特定的视频模式 setter（至少某种显示 getter）：

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 window，因此一个 GLFW VMS，所以在这种情况下你总是构建成对的策略...

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

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

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

how to design policy-class-implementations that depends on each other

c++

policy

dependencies

templates