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

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

通常，您将对可能需要更改的更短寿命和易失性依赖项使用策略，因为接口将用于更大或更静态的功能。例如运行时与配置灵活性之间的区别。

要使用列表排序器的示例，该策略可以采用IEnumerable并对其进行排序，但是您可能希望在上述ListSorter类中定义其他功能，最终使用该策略，例如采用不同的输入集合并显示它们排序策略，或以某种方式对其进行归一化-通过这种方式，您可以将代码解耦，因为请求列表的组件无需关心组件最终如何对其进行排序，并且排序代码不需要了解规范化等。当然，这在大型应用程序中以及与其他技术结合使用时更有用，因此很难在这样的琐碎示例中进行演示，但希望能为您提供一个想法。

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

1 个答案: