Шаблон проектирования стратегии против простой абстракции интерфейса? - PullRequest
0 голосов
/ 19 мая 2019

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;
        }
    }

Контекстный класс, который получает IStrategy в ctor:

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();

Я что-то упустил?почему бы просто не использовать интерфейсы?

1 Ответ

2 голосов
/ 19 мая 2019

Возможно, вам придется заняться другими делами, кроме стратегии ... Например, если вам нужно добавить ведение журнала или распечатать статистику о вашем списке - вы, вероятно, не захотите включать это в свою стратегию. Вы также можете динамически добавлять или разрешать пользователю выбирать стратегии, например, загружая «плагины».

Как правило, вы будете использовать стратегию для более кратковременных и изменчивых зависимостей, которые, возможно, придется изменить, где в качестве интерфейса будет использоваться большая или более статическая функциональность. Разница, например, между временем выполнения и гибкостью конфигурации.

Чтобы использовать ваш пример сортировщика списка, стратегия может взять IEnumerable и отсортировать его, но вы можете захотеть определить дополнительные функциональные возможности в приведенном выше классе ListSorter, который, наконец, использует эту стратегию, например, взяв различные входные коллекции и представив их. стратегии сортировки или их нормализации - таким образом вы отделяете свой код, так как компоненту, запрашивающему список, нужно отсортировать, не имеет значения, как компонент заканчивает его сортировку, и код сортировки не должен знать о нормализация и т. д. Конечно, это более полезно в более крупных приложениях и в сочетании с другими методами, поэтому трудно продемонстрировать на таком тривиальном примере, как этот, но, надеюсь, даст вам представление.

...