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

[_Bers]

Пока что по простоте кода лидирует первая группа. Количество абстракций в их варианте меньше.

Далее заказчику захотелось что бы были времена года.
Что бы зимой волки сбивались в стаю, а летом распадались на пары.

-----------------
Ребятам из первой группы это оказалось целым испытанием на прочность их архитектуры.

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

Но во втором случае получается что зимний волк и весенний - это два принципиально разные типы, а значит разные объекты.
То есть, при смене года нужно будет выполнять подмену объектов: прибивать зимнего, а на его место сажать весеннего.
Это оказалось чревато.

Нельзя просто так сохранить ссылку на объект. Был зимний волк, его прибили и ссылка стала невалидной.
Уследить за подобного рода движениями было проблематично. То и дело, где-то что-то ломалось.

Хотелось что бы попроще - есть волк, вот он и есть волк. Не важно, зимний или весенний.
Набив шишки, они решили вернуться к варианту со стратегиями:

Итого: Интерфейс животного, овца, волк, интерфейс поведения волков, зимняя и весенняя стратегия волков.
-----------------

Ребята из второй группы просто разделили стратегию поведения волка на две стратегии: весеннию и зимнию.

Итого: один класс животного, 1 интерфейс стратегии, 2 стратегии для волков, и одна - для овцы.

[_Bers]

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

Далее заказчик захотел, что бы и волки и овцы реализовывали разные модели поведения, причем некоторые из них - одновременно.

Например, что бы по весне волком управляла и любовь, и жажда крови.
А если, например, животное ранено - то для него включалась дополнительная стратегия - "хочу выжить".

-----------------
Ребята из второй группы внесли модификацию в свой класс Animal:
Заменили там указатель стратегии, на динамический массив стратегий.
И теперь животным управляет не одна стратегия, а сразу все, которые были только в него установлены.

А поскольку, в этом варианте архитектуры нет формального деления на овец и волков (все - есть животное, с разным набором параметров),
То они предусмотрели механизм работы со стратегиями так, что бы из любой стратегии легко можно было получать доступ к животному-хозяину.
А так же расшаривать общие для нескольких стратегий данные, и тп нюансы.
( привет, компонентная система! )

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

Поскольку теперь все животные наделены "стратегическим поведением", то, они вынесли механизм стратегии в базовый интерфейс IAnimal
Теперь их вариант архитектуры стал очень похож на вариант второй группы.

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

[_Bers]

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

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

-----------------
Ребята из второй группы сделали всего несколько штук общих для множества животных стратегий.
А дальше только комбинировали их в разных пропорциях.

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

[_Bers]

Наконец фантазия заказчика истощилась. И он захотел создать животных мутантов.
Он захотел объединить в одном животном качества и волка и овцы....

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

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

[_Bers]

Резюмируя:

Главная задача полиморфизма - это реализовать идею: "закрыт для изменений, открыт для расширений".

Классические интерфейсы и прямое наследование удобно тогда, когда заранее и точно известен интерфейс будущих механизмов. И их поведение не изменяется в рантайме.

Если же необходимо в рантайме изменять поведение уже существующего экземпляра - стратегия, это самое простое и очевидное решение.

[Utkin]

Пример из поста #11 явно притянут за уши это будет стоить больших денег и за это нужно уволить системного аналитика. Как видно ошибка не в программировании, а в некорректном техническом задании. Нет виртуального заказчика, который может вертеть проектом по желанию левой пятки. Очевидно что оправдать ошибки проектирования таким паттерном не пройдут в большой конторе. Я бы выписал анальные кары за такое разгильдяйство.
Остальные посты аналогично. Если вы делаете прототип приложения, то все равно Вам придется пересматривать и структуры данных и поведение, а не наслаивать одни ошибки на другие.

[_Bers]

Сообщение от Utkin

Пример из поста #11 явно притянут за уши это будет стоить больших денег и за это нужно уволить системного аналитика. Как видно ошибка не в программировании, а в некорректном техническом задании. Нет виртуального заказчика, который может вертеть проектом по желанию левой пятки. Очевидно что оправдать ошибки проектирования таким паттерном не пройдут в большой конторе. Я бы выписал анальные кары за такое разгильдяйство.
Остальные посты аналогично. Если вы делаете прототип приложения, то все равно Вам придется пересматривать и структуры данных и поведение, а не наслаивать одни ошибки на другие.

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

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

На практике я много раз сталкивался с оо-архитектурами, которые оставляли впечатление такое, будто бы их разработчики делали ооп ради ооп.

Когда количество всевозможных классов зашкаливало даже для решения простых задач.

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

Когда менеджер чевотов сидит на менеджере чевотов и чевотами погоняет.

Когда мой коллега оптимистично изрекает: "нет такой проблемы, которую нельзя решить введением ещё одного слоя абстракции, кроме проблемы слишком большого количества абстракций".

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

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

Собственно в этом и заключается смысл использования паттерна стратегии, равно как и любого другого паттерна: простота и удобства программиста.

Я не хочу ни в чем вас убеждать, и ничего вам навязывать.

Если вам интересно - попробуйте сами реализовать волков, для которых можно легко и быстро настраивать поведение не используя стратегии.

Скорее всего вы придете опять таки к стратегиям в том или ином виде.
Либо вообще не сможете реализовать такую задачу.

[Utkin]

Я не против паттернов, но примеры про капризного заказчика совершенно не подходят это ошибки организации проекта.

[_Bers]

Сообщение от Utkin

Я не против паттернов, но примеры про капризного заказчика совершенно не подходят это ошибки организации проекта.

С паттернами есть любопытная особенность: пока не попадешь в ситуацию, где паттерн - как манна небесная, его профит не очевиден.

Поэтому и был нужен этот мысленный эксперимент: сравнить подходы с использованием и отсутствием паттерна. Что бы проиллюстрировать очевидный профит.

Что касается "ошибок организации проекта", я нахожу ваше мнение странным. Проект имеет свойство развиваться.
И нечто подобное имеет место быть в реальной жизни.

[Utkin]

Проект имеет свойство развиваться.
И нечто подобное имеет место быть в реальной жизни.

Его развитие должно быть предусмотрено и описано заранее. Иначе это опять косяк организации. Даже научные разработки в идеале должны предусматривать различные варианты событий. А если проект типовый (например, клиент-сервер-бд), то никаких развитий и фантазий там быть не должно. Все уже придумали и довольно давно.