DISCLAIMER: не проматывайте этот пост только из-за того, что обзор книг – это неинтересно. Здесь будет пяток интересных цитат и ряд других полезных мыслей!
Если спросить у десяти разработчиков о паттернах проектирования и о том, какая книга является лучшим источником информации по этой теме, то 9 из 10 назовут знаменитую книгу банды четырех и будут правы. GoF – является классическим каталогом паттернов в том виде, в котором он был описан Кристофером Александером 35 лет назад и все еще остается бесценным справочником для любого программиста.
Но, как и у любого каталога (или справочника), Эрих Гамма и др. сосредотачиваются на применимости паттернов, на связях конкретного паттерна с другими, они дают примеры использования в реальных проектах, но они не учат (точнее, не акцентируют на этом внимание) тому, какие принципы объектно-ориентированного программирования эти паттерны решают; где найти ту грань, когда от паттернов лучше отказаться и не предупреждают о недостатках их чрезмерного использования.
Короче говоря, GoF – это идеальный инструмент для «прокачанного» специалиста и далеко не идеальный источник для неокрепшего разума.
Цитата (основная суть паттернов проектирования): выделите переменные составляющие и инкапсулируйте их, чтобы позднее их можно было изменять или расширять без воздействия на постоянные составляющие.
В отличие от банды четырех Фриманы делают акцент на принципах ООП и показывают, какие проблемы могут возникнуть с дизайном системы и как их можно решить с помощью основных паттернов. Классический вопрос о разнице между наследованием и агрегацией обсасывается со всех сторон, причем не столько в контексте паттернов, сколько в контексте связности и гибкости дизайна.
Цитата: Прежде всего, при проектировании следует использовать самые простые решения. Вашей целью должна быть простота, а не «как бы применить паттерн в этой задаче». Не стоит думать, что без использования паттернов вас не будут считать грамотным специалистом. Другие разработчики по достоинству оценят простоту архитектуры.
Еще одной отличительной особенностью книги является способ подачи материала: 650 страниц книги можно одолеть за пару выходных, при этом не взорвется от перенапряжения; авторы целенаправленно вдалбливают самыми различными способами (картинки, цитаты, повторения ключевых концепций) самое важное, что должен читатель вынести после прочтения. Иногда, это начинает напрягать, но, опять-таки, «это не баг, это фича» данной книги, и если нужна дикая концентрация ООП-шной мысли на строку текста, то тут уж лучше обратиться к правильному источнику (например, к Мейеру).
Цитата: Если кто-то ходит, как утка, и крякает, как утка, то это и есть может быть утка индюшка с утиным адаптером...
Еще очень порадовали примеры паттернов (например, примеры декораторов ввода вывода в Java и декорирование напитков), хотя в некоторых примерах (например, при рассмотрении заместителей) дается слишком уж много специфических языковых конструкций.
Если говорить о других недостатках, то они относится к нашим переводчикам. Нет, с переводом все нормально, он на довольно высоком уровне и мне не приходилось лезть в оригинал, чтобы понять смысл предложения. Проблема в отсутствии оригинальных терминов. Все же немаловажной ролью паттернов является коммуникативная составляющая, а некоторые паттерны мы называем исключительно в оригинале, вот и приходится думать о том, что же такое заместитель, это proxy или нет. Не говоря уже за такие термины, как связность, когда только из контекста становится понятно, идет ли речь в книге о cohesion или coupling. Это не так часто напрягает, но было бы неплохо видеть перед глазами оригинальные названия.
ПРИМЕЧАНИЕ
Если интересна природа терминов cohesion и coupling или, вообще, интересна история паттернов проектирования, то вам сюда: Шаблоны проектирования. История успеха.
Цитата: В одной ситуации паттерны используются даже при наличии более простого решения: если вы ожидаете, что некоторые аспекты вашей системы будут изменяться. Только следите за тем, чтобы паттерны были ориентированы на реальные, а не на чисто теоретические изменения.
Последней отличительной особенностью книги является прагматический взгляд на ОО дизайн, простоту и применение паттернов в повседневной жизни. Многие из нас сталкивались с тем, что разработчик проходит следующие стадии отношения к паттернам:
1-я стадия: Ух-ты-Ух-ты-Ух-ты! Я узнал, что такое паттерны! Клева! Как бы мне их заюзать!
2-я стадия: Ух-ты! Я отрефакторил старый код и вместо десяти строк кода заиспользовал 7 паттернов! Я мегакрут!
3-я стадия: ух-ты. Ну, паттерны — это классная штука, но как-то уже нет особого желания впихивать их куда угодно. Чего-то потом и сам ноги ломаешь за всеми этими абстрактными фасадированными декораторами, завернутыми в синглтон.
4-я стадия: нет, паттерны – это хорошо, но прагматизм – рулит, да и вообще: а) думать еще никто не отменял; б) простое решение лучше сложного; г) паттерны хорошо, но принципы ООП зачастую и так дадут ответы на большую часть вопросов.
В результате страсть от полного щенячьего восторга постепенно сменяется прагматичным применением принципов и паттернов. Фриманы (да, это авторы сего талмуда) уделяют этому вопросу достаточно много внимания, начиная с 610 страницы. У меня, правда, есть опасение, что не все дочитают до этого места, а бросятся использовать паттерны налево и направо значительно раньше, в результате чего бесценный урок будет пропущен.
Цитата: В каких случаях паттерны следует исключать из архитектуры? Если ваша система стала чрезмерно сложной, а изначально запланированная гибкость оказалась излишней… Проще говоря, когда более простое решение предпочтительно (кстати, эта мысль подтверждается моим собственным опытом).
Если сложить все вышесказанное вместе, то мы получаем, что эту книгу нельзя использовать в качестве справочника (или каталога паттернов), в ней будет слишком много воды для опытного программиста и она не сможет заменить серьезную книгу по ООП. С другой стороны, это идеальный учебник базового уровня по паттернам и основам ООП, который даст основные сведения по этим темам и поможет устаканить существующий беспорядок в голове.
Оценка: 4 (идеальный учебник, но едва ли подойдет опытному специалисту).
Автор: SergeyT
