Паттерн стратегия

Здесь я хотел бы рассказать о паттерне стратегии.

В качестве примера, рассмотрим следующий класс:

    abstract class Duck
    {
        public void quack()
        {
            Console.Out.WriteLine("Quack!");
        }

        public void swim()
        {
            Console.Out.WriteLine("Bulk!");
        }

        abstract public void display();
    }

     Это наш класс Утка, которая умеет крякать и плавать, при этом все утки, которые наследуют этот класс умеют тоже самое. Метод display у нас является абстрактным, так как каждая утка имеет свой образ и требует конкретной реализации.
Ниже я показал диаграмму классов (у нас две новых утки: MallarDuck и RedHeadDuck, которые наследуют абстрактный класс Duck):

Класс MallarDuck:

using System;

    class MallarDuck : Duck
    {
        public override void display()
        {
            Console.Out.WriteLine("I am Mallar Duck!");
        }
    }

Класс RedHeadDuck:

using System;
   class RedHeadDuck : Duck
    {
        public override void display()
        {
            Console.Out.WriteLine("I am Red Head Duck!");
        }
    }

Запускаем наш первый пример:

using System;

    class Program
    {
        static void Main(string[] args)
        {
            MallarDuck  MyDuckMallar = new MallarDuck();
            RedHeadDuck MyDuckRedHead = new RedHeadDuck();
            
            MyDuckMallar.display();
            MyDuckRedHead.display();
            
            MyDuckMallar.quack();
            MyDuckRedHead.quack();

            Console.In.ReadLine();

        }
    }

Результатом запуска будет:

Какие проблемы сразу видны?
    Если мы заходим дать возможность нашим уткам летать, то необходимо будет добавить в наш абстрактный класс Duck метод fly(), при этом его конкретную реализацию унаследуют все классы, т.е. даже те утки, которые не должны летать. Для них нам придется переписывать данный метод и делать его пустым (например деревянная утка не должна уметь летать). При добавлении других возможностей в будущем, каждый  раз придется реализовывать пустые методы.

Какой Выход?
    Возможно, стоит вынести метод fly() в интерфейс? Тогда мы достигним того, что деревянная утка не должна летать, так как она не будет реализовывать интерфейс метода fly().
Но тут возникает другая проблема: дублирование кода. Так как интерфейс не может содержать конкретную реализацию метода, то нам придется реализовывать метод fly() для каждого класса. При каких-либо изменениях, необходимо будет внести их в каждый класс.

Основным принципом проектирования является: Выделить части приложения, которые могут изменяться и отделить их от тех, которые являются постоянными. Иными словами нам нужно выделить изменяющийся код так, чтобы не изменять постоянную часть в дальнейшем.

Принцип проектирования: Программируйте на уровне интерфейсов.

Руководствуясь этими двумя принципами переделаем наш пример.
 Мы знаем, что метод fly() может быть не у всех субклассов класса Duck, поэтому нам необходимо выделить его в отдельный набор классов, так же как и метод кряканья quack().
Руководствуясь первый принципом мы должны создать интерфейс для методы fly()

Получаем следующую диаграмму классов:

Давайте посмотрим на изменившийся класс Duck:

    abstract class Duck
    {
        //переменные интерфейсов, 
        //через которые будет происходит делегирование действий
        protected IFlyBehavior flyBehavior;
        protected IQuackBehavior quackBehavior;

        //создаем динамическое изменение поведения уток
        public void setFlyBehavior(IFlyBehavior fb)
        {
            flyBehavior = fb;
        }

        public void setQuackBehavior(IQuackBehavior qb)
        {
            quackBehavior = qb;
        }

        public void performQuack()
        {
            quackBehavior.quak(); //делегируем
        }

        public void performFly()
        {
            flyBehavior.fly(); //делегируем
        }

        public void swim()
        {
            Console.Out.WriteLine("Bulk!");
        }

        abstract public void display();
    }

Мы вынесли методы полета и кряканья в интерфейсы, а также сделали набор классов, которые являются реализацией разных алгоритмов полета и кряканья наших уток. Далее мы объявили две переменных в абстрактном классе Duck()

  protected IFlyBehavior flyBehavior;
  protected IQuackBehavior quackBehavior;

Которые ссылаются на классы, реализующие данные методы. Т.е. мы можем присвоить любой алгоритм кряканья или полета. Вызов делегирование происходит через методы:

        public void performQuack()
        {
            quackBehavior.quak(); //делегируем
        }

        public void performFly()
        {
            flyBehavior.fly(); //делегируем
        }

С помощью двух сеттеров мы можем динамически на лету присваивать разные алгоритмы нашим классам. Метод display() мы оставили абстрактным, так как для каждой утки он будет разным, а метод swim() для всех будет одинаков. Ниже приведу описание остальных классов:

    //интерфейс метода Полета
    interface IFlyBehavior
    {
        void fly();
    }
   // интерфейс метода кряканья
    interface IQuackBehavior
    {
        void quak();
    }
  //класс, реализующий невозможность летать
  class FlyNoWay: IFlyBehavior
    {
        public void fly()
        {
            Console.Out.WriteLine("I can not fly!");
        }
    }
  //Класс, реализующий алгоритм полета ракеты
  class FlyRocket: IFlyBehavior
    {
        public void fly()
        {
            Console.Out.WriteLine("I fly as rocket!");
        }
    }
  //Класс, реализующий алгоритм обычного кряканья
  class Quack : IQuackBehavior
    {
        public void quak()
        {
            Console.Out.WriteLine("quack!");
        }
    }
  //Класс, реализующий алгоритм бесшумного кряканья
 class MuteQuack: IQuackBehavior
    {
        
        public void quak()
        {
            Console.Out.WriteLine("Empty Quack!");
        }
    }
}
  //Класс дикой утки 
  public MallarDuck()
        {
            quackBehavior = new Quack();
            flyBehavior = new FlyRocket();
        }

        public override void display()
        {
            Console.Out.WriteLine("I am Mallar Duck!");
        }
    }
  //Класс красноголовой утки
  class RedHeadDuck : Duck
    {
        public RedHeadDuck()
        {
            quackBehavior = new Quack();
            flyBehavior = new FlyRocket();
        }
        public override void display()
        {
            Console.Out.WriteLine("I am Red Head Duck!");
        }
    }

Давайте теперь сделаем класс деревянной утки, для этого сделаем класс-модель утки, которая по умолчанию не умеет ничего делать:

   class ModelDuck : Duck
    {
        public ModelDuck()
        {
            quackBehavior = new MuteQuack();
            flyBehavior = new FlyNoWay();
        }

        public override void display()
        {
            Console.Out.WriteLine("I am model!");
        }
    }

Теперь давайте вызовем все наши классы, а также посмотрим как можно динамически изменять алгоритмы:

class Program
    {
        static void Main(string[] args)
        {
            MallarDuck  MyDuckMallar = new MallarDuck();
            RedHeadDuck MyDuckRedHead = new RedHeadDuck();
           
            //Наша дикая утка
            MyDuckMallar.display();
            MyDuckMallar.performFly();
            MyDuckMallar.performQuack();
            
            //красноголовая утка
            MyDuckRedHead.display();
            MyDuckRedHead.performFly();
            MyDuckRedHead.performQuack();
            
            //модель утки, которой мы поменяли алгоритм 
            //кряканья и алгоритм полета
            ModelDuck myThreeDuck = new ModelDuck();
            myThreeDuck.display();
            myThreeDuck.performFly();
            myThreeDuck.performQuack();

            myThreeDuck.setFlyBehavior(new FlyRocket());
            myThreeDuck.setQuackBehavior(new Quack());

            myThreeDuck.performFly();
            myThreeDuck.performQuack();

            Console.In.ReadLine();

        }
    }

Вот это да! Мы смогли избавиться от дублировния кода, теперь мы можем независимо разрабатывать алгоритмы и присваивать их любым уткам, а также мы смогли уйти от наследования, которое принудительно добавляло все методы во все субклассы!

Подобные связи между двумя классами называются композицией, т.е. поведение не наследуется, а предоставляется правилами выбора.

Принцип проектирования: Отдавайте предпочтение композиции перед наследованием.

Композиция позволяет не только инкапсулировать семейство алгоритмов, но и изменять поведение во время выполнения.

Паттерн СТРАТЕГИЯ определяет семейство алгоритмов, инкапсулирует каждый из них и обеспечивает их взаимозаменяемость. Он позволяет модифицировать алгоритмы независимо от их использования на стороне клиента.