Question

关于这个主题有很多信息。这更像是一个设计问题，但我会举例说明。

让我们说我真的希望传递一个配置用户政策的配置文件类。

struct ApplicationAllowedPolicy
{
public:
    bool hasAccess() { return true; }
}

struct ApplicationProhibitedPolicy
{
public:
    bool hasAccess() { return false; }
}

template<typename ApplicationPolicy>
class Profile : private ApplicationPolicy
{
    bool hasAccess() { return ApplicationPolicy::access(); }
}

int main()
{
    Profile<ApplicationAllowedPolicy> allowed;
    Profile<ApplicationProhibitedPolicy> prohibited;

    // do something with allowed & prohibited
}

以上内容都很精致，但我们假设有很多政策需要阅读.5看起来像一个真实的现实世界号码，尽管可能更多。然后，让我们假设此配置文件将应用于数百个实例，其中5个策略变化很大。要启动，策略行为只能在运行时知道（从文件，数据库读取，等等）。这很快变得不可扩展，除非我完全遗漏了什么。

我想过将非类型模板类作为策略。

template<int N>
struct ApplicationPolicy
{
    int policy = N;
};

Profile<ApplicationPolicy<1>> allowed;
Profile<ApplicationPolicy<0>> prohibited;

我认为这确实适用于我的情况，但我想知道这是否缺少基于政策的设计。我看到这方面的优点只是让Profile成为一个普通的结构，并根据需要将它的数据成员设置为true / false。

思想？

Answer 1

当类的行为根据策略发生重大变化时，基于策略的设计非常有用。例如，假设您希望在多线程和常规上下文中使用您的类。然后，您可以将其实现为线程策略：

class SingleThreadedPolicy { /* ... */ }; // lock() does nothing
class MultiThreadedPolicy { /* ... */ }; // lock() actually locks

template<class T, class ThreadingPolicy>
class Queue {
    ThreadingPolicy threadPol_;
    // ...
    T pop() {
       threadPol_.lock();
       // remove an element from the queue
       threadPol_.unlock();
       return element;
    }
};

现在，实现相同结果的另外两种方法是使用（多个？）继承或在对象中设置标志并编写大量ifs。如果您有多个策略（例如存储，所有权等），第一个选项会很快崩溃。第二个选项导致无法维护的代码。

因此，如果您的课程需要许多正交移动部件，基于策略的设计是一个不错的选择，并且它比其他方法更具可扩展性。

但是，您的示例似乎并不需要这种方法。访问似乎是不可或缺的：如果你打算在代码中调用hasAccess()，你可以安全地用布尔变量替换它。

Answer 2

如果要在运行时更改行为，请使用策略模式而不是基于策略的设计。

具有可变数据的C ++策略设计

2 个答案: