Наконец-то я смог
себя пересилить и написать статью, над которой давно думал. (Лень, подготовка к новой для себя области и постоянное
обучение не позволяли этого сделать.) Поделюсь с Вами мыслями
по поводу книги Мартина Фаулера “Patterns of Enterprise Application Architecture”.
На русском эта книга называется “Архитектура корпоративных программных
приложений”, если у Вас возникнет желание ее прочитать.
Как и во всех своих предыдущих рецензиях, выделю сначала плюсы и минусы книги, а затем перейду к более детальной субъективной критике.
Плюсы:
- Обилие примеров и описание паттернов.
- Перекрёстные ссылки с указанием страницы с описанием паттерна.
- Язык примеров C# и Java что делает их многим доступным для понимания.
Минусы:
- Некоторые паттерны описаны скудно в плане реализации.
- Примеры сильно устарели.
- Примеры, которые написаны на C#, полностью повторяют Java стиль
А
теперь обо всем этом более подробно. Хотелось бы сказать, что книга стоит того,
чтобы ее прочитать, хотя бы для того, чтобы структурировать свои знания. Я
считаю эту книгу классикой, которую можно поставить на уровне “Банды четырех”
(GOF) с их книгой “Design Patterns”, потому что эта книга дает базу и понятия,
которые присущие в проектировании enterprise приложений. Как минимум, термины с
этой книги вы можете использовать для общения с опытными разработчиками, и они
будут вас понимать.
Фаулер,
например, неплохо раскрывает такие паттерны, как Repository, Mapper, Active
Record, Unit of Work и другие. К сожалению, в мире разработки архитектурных
решений не так уж много книг, которые достойно описывают данную область без
лишней “воды”. Когда читаешь эту книгу, как минимум радует, что когда
встречается название паттерна, всегда есть ссылка на источник, где о нем можно
почитать. Мне это очень помогало при сравнении и анализе глав книги. Ну и так
как мой язык разработки – C#, а Java очень подобный к нему, эту книгу мне было
очень легко воспринимать. Если вы не знакомы с этими языками, примеры понять
будет посложнее.
А
теперь пройдемся по негативным моментам книги. Я уважаю Мартина Фаулера как
разработчика и архитектора, а также как автора книг, но хотелось бы обратить
внимание на нюансы, которые мне не понравились в книге. И первый такой момент
заключается в том, что в книге встречаются часто разные названия одного и того
же паттерна. Например, коллизия с названием паттерна Value Object и Data Transfer
Object.
Совпадение названий
На протяжении довольно долгого времени данное
типовое решение носило название объекта-значения. К сожалению, несколько лет
назад в сообществе J2EE [3] термин объект-значение (value object) стал
применяться для обозначения типового решения объект переноса данных (Data
Transfer Object, 419), что вызвало настоящую бурю среди разработчиков типовых
решений. Подобная путаница с названиями — далеко не редкость в нашей сфере
деятельности. Не так давно авторы книги [3] решили отказаться от использования
термина "объект-значение" и заменили его термином объект переноса
(transfer object). Я продолжаю использовать термин "объект-значение"
в том смысле, в котором он применяется в контексте данной книги. По крайней
мере, так я не вступаю в противоречие со своими предыдущими работами!
Сама идея того, что
автор всюду использует Value Object, вроде, сама по себе и ничего, но когда ты смотришь
примерь пример и понимаешь, что это классический в .NET DTO, в голове возникает много вопросов.
Взглянем на примеры книги. К сожалению,
очень много из них устарели много лет назад. Например, глава Presentation Patterns пестрит изобилием
кода для JSP, а код примеров на
C# лучше не читать, чтобы не поплохело. Другой пример – это глава о паттернах Object-Relational Structural Patten, в которых все примеры
приводились на ручном парсинге и выборке данных. Может быть, это и полезно для
базы, но когда есть такие ORM, как EntityFramework или NHibernate, думаешь, зачем сколько кода постоянно дублировать и
переписывать. Я не совсем понимал, почему так сложно приводить в примеры готовую
реализацию. Или, может, в Java нет готовой реализации
некоторых паттернов. Целая глава, которая посвящена Data Source Architectural Patterns, полностью реализована
в .Net Framework. Тот же Table Data Gateway – это типичная реализация DataSet в ADO .NET,
паттерн Row Data Gateway – типичная реализация Row в том же ADO .NET, то же самое – касательно Active Record и Data Mapper. Некоторые паттерны эволюционировали, и
примеры с книги не показывают той элегантности, с которой эти паттерны можно
использовать. На момент выхода книги, когда я прочитал несколько отзывов о ней,
она уже была с неактуальной информацией.
Так як книга 2002
року выпуска, не понимаю, почему в ней не раскрыты вопросы тестирования и Dependency Inversion, паттерны безопасности, почему нет банального Service Locator. Большинство примеров в книге написаны так, что
они не поддаются тестированию. Как говорят программисты, “на
коленке” написан код. То
есть, о части материала с книги можно много дискутировать с коллегами на работе
или просто с друзьями по интересам.
Мой самый нелюбимый
момент в книге – примеры на двух языках. Проблема не в самих примерах, они
в большинстве неплохие, но некоторые очень маленькие и тривиальные, что недостаточно для раскрытия сути. Плохо, что стиль Java примеров, переходит на стиль написания C#. То есть, все примеры на C# написаны в стиле именования Java. Но это мое субъективное мнение.
Итоги
Несмотря
на свой возраст, эта книга является незаменимой основой, и любому разработчику выше среднего уровня было
бы полезно ее прочитать. Реальное понимание идеи книги приходит, если вы
начинаете понимать, как эти идеи развивались с течением времени. Мартин Фаулер
пишет в основном по сути, и в этой книге немного “воды”, которую часто любят
лить архитекторы, когда начинают мыслить на страницах книги о высоком, не
передавая конкретной сути. Я отнес бы эту книгу в категорию “should read”, то есть
книгу, которую следовало бы прочесть. Моя оценка данной книги – 4 балла из 5
возможных.
