О книге Джошуа Кериевски «Рефакторинг с использованием шаблонов»

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

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

Типичный троллинг паттернов головного мозга (оригинал) – Hello, World, Patterns!

public static void Main(String[] args)
{
    MessageBody mb = new MessageBody();
    mb.Configure("Hello World!");
    AbstractStrategyFactory asf = DefaultFactory.Instance;
    MessageStrategy strategy = asf.CreateStrategy(mb);
    mb.Send(strategy);
}

Ок, паттерны, как и любой другой инструмент легко использовать неправильно. Но при чем здесь рефакторинг? Ответ прост: паттерны и рефакторинг имеют отношение к дизайну, и оба эти понятия весьма популярны. Не удивительно, что в мире появился человек, одолевший Design Patterns «банды четырех» и Рефакторинг Фаулера и решил совместить эти две штуки в одной книге.

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

К моменту написания книги понятие “Emergent Design” еще не вошло в моду (хотя не уверен, насколько оно модно сейчас), но именно эта идея – последовательное улучшение дизайна, конечной целью которого являются конкретные паттерны проектирования – заложена в основу книги Джошуа Кериевски «Рефакторинг с использованием шаблонов».

Теперь давайте посмотрим на то, что из этого получилось.

Что понравилось?

ЦИТАТА
К сожалению, когда программисты смотрят на единственную диаграмму, сопровождающую каждый шаблон в книге Design Patterns, они часто приходят к выводу, что приведенная диаграмма и есть способ реализации шаблона. Они бы гораздо лучше разобрались в ситуации, если бы внимательно прочитали самое интересное - примечание к реализации. Многие программисты берут в руки книгу Design Patterns, всматриваются в структурную диаграмму шаблона и начинают кодировать. Полученный код в точности отражает диаграмму, а не реализацию шаблона, наиболее полно соответствующую решаемой задаче.

Прагматичный взгляд на дизайн и рефакторинг.

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

Полезные и поучительные примеры

Некоторые рефакторинги очень полезны, хотя и не всегда приводят к каким-либо паттернам. Compose Method, Introduce Polymorphic Creation with Factory Method, Inline Singleton, Encapsulate Classes with Factory и некоторые другие. Подобные примеры помогут понять назначение соответствующих паттернов проектирования и глубже понять контекст их применения.

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

Что не понравилось?

Формат описания

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

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

Отсутствие обобщения

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

Такая проблема очень актуальна для этой книги. Автор описывает пример рефакторинга своих приложений, при этом в десятке случаев показан рефакторинг библиотеки парсинга HTML. Да, это хороший пример, но многим читателям будет очень сложно после прочтения книги понять, а когда же в их приложении нужно применять Limit Instantiation with Singleton или Move Embellishment to Decorator.

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

Наивность примеров

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

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

Есть еще пара неудачных примеров: Replace Type Code with Class, Inline Singleton и Chain Constructors. Они либо привязаны к конкретной проблеме (Inline Singleton показан в контексте паттерна Состояние, в котором избавиться от синглтона легко, но это не так просто сделать в большинстве других случаев), или же к конкретной языковой возможности (Chain Constuctors решает конкретные проблемы языка Java).

Однотипность примеров

«Сквозной пример» - это очень полезный инструмент с педагогической точки зрения, когда одна и та же задача решается и развивается на протяжении всей книги. При его наличии не нужно каждый раз объяснять читателю контекст задачи. У автора не один, а два основных примера – библиотека работы с XML и библиотека разбора HTML, каждый из которых полезен, но далек от идеала. Проблема в том, что оба примера представляют собой библиотечные решения, причем достаточно специфичные, что опять-таки усложняет адаптацию рассмотренных техник для своих решаемых задач.

Тот же паттерн Composite отлично по подходит для унификации работы с XML, но довольно сложно применим в другом «бизнес-контексте».

Обилие ссылок на Рефакторинг Фаулера

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

В результате

Книга не понравилась. Если бы не подготовка цикла статей о паттернах проектирования, не факт, что я осилил бы эту книгу.

Идея у книги хорошая, но реализация, ИМХО, подкачала. Главная проблема в формате: рефакторинг к шаблонам проектирования подразумевает большее влияние на дизайн приложения, по сравнению с большинством типовых рефакторингов Фаулера. А значит тут полезен и другой формат: вместо утомительного описания шагов изменения кода я бы предпочел уделить большее внимание влиянию на дизайн и просто увеличить количество примеров. Пусть они были бы не столь подробными, но зато их разнообразие сделало бы их более применимыми на практике.

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

Оценка: 2/5

З.Ы. Перевод как обычно, читать можно, но приходится постоянно reverse engineer-ить его в оригинал, чтобы понять, что же хочет здесь сказать автор.

Дополнительные ссылки

• Джошуа Кериевски. Рефакторинг с использованием шаблонов
• Эрих Гамма и др. Паттерны проектирования
• Мартин Фаулер. Рефакторинг
• Programming Stuff. Культ карго в программировании
• Programming Stuff. GoF паттерны на платформе .NET