策略設計模式與簡單接口抽象？

Question

AFAIK，策略設計模式非常簡單 ：

介面

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類中定義其他功能，最終使用該策略，例如，采用不同的輸入集合並將其呈現給排序策略或以某種方式對其進行規范化-通過這種方式，您可以使代碼解耦，因為請求列表排序的組件並不關心組件最終如何對其進行排序，並且排序代碼無需了解規范化等信息。當然，這在較大的應用程序中以及與其他技術結合使用時更有用，因此很難在這樣的瑣碎示例中進行演示，但希望能給您一個想法。