策略设计模式与简单的接口抽象？

Question

AFAIK，策略设计模式is pretty simple：

界面：

public interface IStrategy
    {
        object DoAlgorithm(object data);
    }

实现类：

lass ConcreteStrategyA : IStrategy
    {
        public object DoAlgorithm(object data)
        {
            var list = data as List<string>;
            list.Sort();
            return list;
        }
    }


 class ConcreteStrategyB : IStrategy
    {
        public object DoAlgorithm(object data)
        {
            var list = data as List<string>;
            list.Sort();
            list.Reverse();

            return list;
        }
    }

在 ctor 中获取 IStrategy 的上下文类：

class Context
    {

        private IStrategy _strategy;


        public Context(IStrategy strategy)
        {
            this._strategy = strategy;
        }

        public void SetStrategy(IStrategy strategy)
        {
            this._strategy = strategy;
        }

        public void DoSomeBusinessLogic()
        {
            ////
        }
    }

当然还有 Main 方法：

var context = new Context();
Console.WriteLine("Client: Strategy is set to normal sorting.");
context.SetStrategy(new ConcreteStrategyA());
context.DoSomeBusinessLogic();

问题：

好的，但是与以下内容相比有什么不同：

Istrategy context = new ConcreteStrategyA (); //or ConcreteStrategyB
Console.WriteLine("Client: Strategy is set to normal sorting.");
context.DoSomeBusinessLogic();

我错过了什么吗？为什么不只使用接口？

Answer 1

除了策略之外，您可能还需要做其他事情...例如，如果您需要添加日志记录或打印有关列表的统计信息 - 您可能不想将其纳入您的策略。您可能还希望动态添加或让用户选择策略，例如通过加载“插件”。

通常，您会使用策略来处理可能需要更改的更短寿命和易变的依赖关系，而接口将用于更大或更静态的功能。例如运行时与配置灵活性的区别。

要使用您的 List Sorter 示例，该策略可能会采用 IEnumerable 并对其进行排序，但您可能希望在上述 ListSorter 类中定义最终使用该策略的附加功能，例如采用不同的输入集合并呈现它们到排序策略，或者以某种方式规范化它们——这样你就可以解耦你的代码，因为请求列表排序的组件并不关心组件最终如何排序，排序代码不需要知道归一化等。当然，这在更大的应用程序中以及与其他技术结合使用时更有用，因此很难在像这样的简单示例中演示，但希望能给您一个想法。