【问题标题】:Which design pattern is most appropriate?哪种设计模式最合适?
【发布时间】:2011-02-27 00:48:26
【问题描述】:

我想创建一个可以使用四种算法之一的类(并且要使用的算法仅在运行时才知道)。我在想策略设计模式听起来很合适,但我的问题是每个算法都需要稍微不同的参数。使用策略,但将相关参数传入构造函数,会不会是一个糟糕的设计?

这是一个例子(为简单起见,假设只有两种可能的算法)...

class Foo
{
private:
   // At run-time the correct algorithm is used, e.g. a = new Algorithm1(1);
   AlgorithmInterface* a; 

};

class AlgorithmInterface
{
public:
   virtual void DoSomething() = 0;
};

class Algorithm1 : public AlgorithmInterface
{
public:
   Algorithm1( int i ) : value(i) {}
   virtual void DoSomething(){ // Does something with int value };
   int value;   
};

class Algorithm2 : public AlgorithmInterface
{
public:
   Algorithm2( bool b ) : value(b) {}
   virtual void DoSomething(){ // Do something with bool value };
   bool value;   
};

【问题讨论】:

  • 与其试图让你的代码适应一些预设的模式,不如设计它对你来说最清楚(希望对其他人最清楚)并且最容易维护。换句话说:设计模式很烂。如果找到了解决问题的优雅方法,请使用它;它是否违反了一些任意的设计模式是无关紧要的。
  • 另外,如果你再给我们一点(这些参数是如何传递的等等),我们可以给你一个更好的答案。但就像看起来一样,对我来说似乎是一个很好的解决方案。

标签: c++ inheritance design-patterns strategy-pattern


【解决方案1】:

这将是一个有效的设计,因为 Strategy 模式要求定义一个接口,并且实现它的任何类都是运行策略代码的有效候选者,无论它是如何构造的。

【讨论】:

    【解决方案2】:

    我认为这是正确的,如果您在创建新策略时拥有所需的所有参数,并且每个阅读代码的人都清楚您所做的事情。

    【讨论】:

      【解决方案3】:

      你对这种方法是正确的。是的,这就是策略模式的精髓……“独立于实现改变算法。”您可以给自己一个通用构造函数来传递初始化类所需的参数,例如作为对象数组。

      享受吧!

      【讨论】:

        【解决方案4】:

        当您想在运行时决定使用哪种算法时,策略模式很有用。

        【讨论】:

          【解决方案5】:

          您还可以使用包含键值对的内存块的单个接口来传递参数。这样,接口在任何当前和未来的算法之间都是通用的。每个算法实现都知道如何将键值对解码为其参数。

          【讨论】:

          • 这样会不会破坏策略模式的整个概念,因为调用策略的代码需要知道正在使用哪种策略才能知道要传递哪些键/值对?
          • 不,这只会影响 Strategy 类的实现。与其用独特的接口构建算法,不如采用统一的接口。应用程序界面不应该改变。对于少数算法来说,这样做的成本可能很高,但如果数量可以增长到几十个或更多,维护起来可能会更简单。
          • @Eric,我想这取决于您是否希望客户端始终提供相同的键-> 值对。当然,这会引出为什么需要键->值对的问题。
          【解决方案6】:

          恕我直言,您正面临挑战,因为您在具体算法的创建方面和算法的实际运行之间感到困惑。只要'DoSomething'接口不变,Strategy Pattern就可以使用。只是创建不同的具体算法会因您的情况而异,可以通过Factory Method 设计模式来处理。

          【讨论】:

            猜你喜欢
            • 1970-01-01
            • 1970-01-01
            • 2023-03-10
            • 1970-01-01
            • 2012-10-29
            • 2016-01-06
            • 1970-01-01
            • 1970-01-01
            相关资源
            最近更新 更多