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

[sashonk]

день добрый.
не понимаю, в чем принципиальная разница между использованием данного паттерна и использовании обычной иерархии классов. к примеру, есть классы, реализующие алгоритмы архивации RARCompression, ZIPCompression, ARJCompression, являющиеся наследниками класса Compression, и определяют метод compress. В соответствии с парадигмой паттерна, мы
должны создать некий вспомогательный класс Compressor, который будет держать ссылку на абстрактный Compression и делегировать вызов compress.
утверждается, что Strategy предоставляет возможность замены одного алгоритма другим в процессе выполнения программы. хотелось бы увидеть на примере, как это можно делать и будет ли это проще, чем в том случае, когда мы работаем на с классом Compressor, а Compression. утверждается также, что Strategy позволяет скрыть детали реализации алгоритмов от клиента. но если Compression - интерфейс, чего еще надо скрывать?

[Utkin]

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

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

Иерархия классов всего лишь описание, паттерн это некоторый шаблон по которому строится код.

[buriat]

почитайте еще про Dependency Injection и Inversion of Control.

[Kostia]

Пишем свою стратегию выделения памяти для vector, а потом так:

vector<int, CMyMemoryAllocator> data;

Самый простой пример(взят из книги Александреску) это стратегия Creator<T> с методом Create который возвращает указатель на объект класса T. Можно определить несколько стратегий Creator:

template <class T>
struct NewCreator{...};

template <class T>
struct MallocCreator{...};

template <class T>
struct PrototypeCreator{...};

template <template <class> class CreationPolicy = NewCreator>
class WidgetManager : public CreationPolicy<Widget> {...};

typedef WidgetManager<MallocCreator> MyWidgetManager;

...

auto w = MyWidgetManager::Create();

И тут начинается крутотень, т.к. класс WidgetManager знает Creator, то он может создать с его помощью не только виджеты, но и гаджеты, и печеньки, и котлеты ...

Правда я не вижу смысла использовать стратегии если вы пишите что-то конкретное, а не гибкую библиотеку с кучей настроек типа своего GUI или framework'а

[Utkin]

И тут начинается крутотень,

Конечно, селектором так сделать нельзя, это да. Я уже молчу что такая крутотень не очевидна и потому будет первым источником ошибок. Код (даже Ваш собственный) в первую очередь должен быть понятным, а не крутым.

[Kostia]

Я уже молчу что такая крутотень не очевидна и потому будет первым источником ошибок.

Какого рода ошибок? Вас смутил шаблонный шаблонный параметр?

Код (даже Ваш собственный) в первую очередь должен быть понятным, а не крутым.

Автор дабы облегчить жизнь рядовому программисту заранее определил стратегию создания объекта по умолчанию. Рядовому Васи Пупкину осталось лишь:

Widget * widget1 = WidgetManager::Create();

И что тут может быть непонятного?

Хотя признаю, на втором курсе Александреску не осилил =(, только к концу третьего.

[Utkin]

И что тут может быть непонятного?

Какая печенька когда создастся. Проблемы всплывут при отладке кода. Когда неочевидная хитропопая стратегия будет создавать то одно, то другое по одному креатору.
В общем, на мой взгляд, идея спорная и, ИМХО, нет ни одного преимущества при использовании обычных там IF'ов или Case.

[Kostia]

Какая печенька когда создастся.

Зачем вам это знать? Всё что должен уметь Creator так это создавать объекты класса T. А WidgetManager должен создавать и возвращать указатель на Widget. Хотя Васи Пупкину достаточно знать только последнее. А уж как потом WidgetManager освобождает память и т.д. это касается уже только разработчика самой библиотеки.

[Utkin]

Зачем вам это знать? Всё что должен уметь Creator так это создавать объекты класса T. А WidgetManager должен создавать и возвращать указатель на Widget. Хотя Васи Пупкину достаточно знать только последнее. А уж как потом WidgetManager освобождает память и т.д. это касается уже только разработчика самой библиотеки.

Я про разработчика и разработку и говорю.

[_Bers]

Давайте сделаем мысленный эксперимент:

Две группы программистов параллельно развивают продукт: "полигон для животных".

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

-----------------
Ребята из первой группы выделили общее у животных и завели интерфейс
IAnimal

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

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

Повесили картинку волка - получился волк.
Повесили картинку овцы - получилась овца.

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

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