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

Пред. запись: GoF паттерны на платформе .NET
След. запись: Паттерн Шаблонный Метод

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

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

Подробнее – Strategy Pattern on Wiki

Мотивация

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

GoF паттерны на платформе .NET

След. запись: Паттерн Стратегия

Посты серии:

• Паттерн Стратегия
• Паттерн Шаблонный Метод
• RAII в C#. Локальный Метод Шаблона vs. IDisposable
• Паттерн Посредник

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

Так, когда в начале 90-х на арене программного мира появились паттерны проектирования, многие начали мечтать о том, что благодаря им даже бизнес-пользователи и 1С программисты смогут собирать приложение из готовых кирпичиков. Довольно быстро стало ясно, что этого не случится и начали искать другие подходы, включая программирование через конфигурацию, пламенно воспетую Хантом и Томасом в их «Программисте-прагматике». Затем появились IoC (или DI) контейнеры и начался новый этап создания «слабосвязанных приложений», разбираться с которыми стало еще сложнее, чем прежде благодаря замене «физической» (прямой) связи между компонентами на «логическую» (косвенную).

Ключевые концепции DDD

… и рецензия книги Эрика Эванса “Domain-Driven Design: Tackling Complexity in the Heart of Software”

Хороший дизайн приложения является главной основой любого приложения. Чрезмерная сложность дизайна приводит к увеличению стоимости изменений и некоторой «хаотичности» этого процесса. Чрезмерная простота – оставляет бреши в полученных моделях, в результате чего приложение может не выполнять тех функций, ради которых оно разрабатывается.

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

О фреймворках и свободе

“Множество переусложненных решений (overengineering) было принято во имя гибкости. Но дополнительные уровни абстракции и уровни косвенности гораздо чаще мешают, нежели помогают в этом деле. Посмотрите на дизайн систем, которые действительно вдохновляют программистов, занимающихся их разработкой, и как правило вы увидите нечто простое. Простого решения добиться не просто (simple is not easy).”

Эрик эванс "Domain-Driven Design: Tackling Complexity in the Heart of Software"

Обсуждая те или иные вопросы дизайна уже неоднократно поднимался вопрос гибкости vs. простоты решения. С одной стороны, гибкость очень привлекательна. Что может быть лучше, чем возможность на лету адаптировать приложение под изменившиеся требования? И хотя эта мысль очень заманчива, большинство опытных разработчиков знают, что она утопична, если она приходит в начале работы над проектом.

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

Microsoft Fakes. Тестирование поведения

DISCLAIMER: исходный код Verification Fakes можно найти на github, а скомпилированная версия доступна через nuget.org/packages/VerificationFakes.

В прошлой заметке мы рассмотрели примеры использования Microsoft Fakes для создания стабов – заглушек, возвращающих требуемые данные. Однако в некоторых случаях нам все же нужно проверить, что в определенных условиях тестируемый класс обращается к некоторой зависимости. Такой вид тестирования называется тестированием поведением и именно такой вид «подделок» каркасом Microsoft Fakes практически не поддерживается.

Microsoft Fakes. Тестирование состояния

Все приведенные примеры можно найти на github.

Microsoft Fakes – это очередной изоляционный фреймворк, который является логическим продолжением экспериментального проекта Microsoft Moles.

Все изоляционные фреймворки делятся на несколько категорий, в зависимости от времени генерации «подделок» и их типу:

По времени генерации:

• генерация на лету во время исполнения тестов;
• во время компиляции;

По типу генерируемых «подделок»:

• на основе полиморфизма, что позволяет «мокать» лишь полиморфные методы;
• на основе CLR Profiling API, что позволяет мокать невиртуальные методы, включая статические.

О пользе выбора

Мы очень часто сталкиваемся с дилеммой при разработке проекта или одной из его фич: что выбрать, подход А или подход Б? Что лучше, использовать WCF или веб-сервисы; Entity Framework или NHibernate; читать конфигурацию из файла конфигурации или из базы данных?

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

Поскольку иногда бывает сложным убедить собеседника в своей правоте мы можем прийти к заключению, что нужно найти компромиссное решение. Здесь мы ступаем на очень тонкий лед. Может показаться, что лучшим решением этой дилеммы будет создание гибкого решения, которое будет удовлетворять обоим подходам одновременно. Очевидно, что в этом случае мы не просто сможем переключаться от одного решения к другому: мы поддерживаем два решения сразу! Разве не прекрасно?