Этот обзор Практических шаблонов проектирования Брэндона Сэвиджа в PHP будет включать мои собственные мнения и впечатления как о книге, так и об аспекте самопубликации. Большое спасибо Брэндону за предоставленную мне обзорную копию.
Шаблоны проектирования — это общие решения общих проблем.
… это концепции, а не чертежи; идеи, а не готовые проекты.
… они добавляют ясности в сложную ситуацию.
— Брэндон Сэвидж, Практические шаблоны проектирования в PHP
содержание
Начав с более легкой вступительной заметки, Брэндон объясняет необходимость в фреймворках, утверждает, что ООП не означает просто оборачивать вещи в классы, и подробно рассказывает, почему шаблоны проектирования кажутся трудными для изучения. Затем он продолжает небольшое введение в принципы SOLID и закладывает основу для более продвинутых концепций. Он объясняет, почему каждое правило SOLID важно и что оно означает. Учитывая, что SOLID является хорошо отработанным принципом разработки программного обеспечения, вполне естественно сравнивать его с каждым шаблоном, который будет описан в книге. Или, если быть более точным, оценить, насколько хорошо каждый шаблон соответствует принципам SOLID, при этом предоставляя разработчику предполагаемую функциональность.
Если я высказываю вопросы в терминологии модели Дрейфуса , он утверждает, что книга призвана превратить новичка в компетентного разработчика, не подвергая их ошибкам продвинутого новичка, хотя на самом деле такой подход к обучению не совсем возможен — это просто не так. процесс приобретения человеческих знаний работает .
Как может показаться не слишком очевидным из ToC, шаблоны, описанные в этой книге, по порядку:
- (Абстрактный) фабричный образец
- Синглтон
- Образец Строителя
- Образец Декоратора
- Шаблон адаптера
- Образец Моста
- Образец фасада
- Шаблон стратегии
- Образец Посредника
- Образец Наблюдателя
- Схема цепочки ответственности
- Шаблон итератора
- Композитный паттерн
- Шаблон MVC
- Модель модели предметной области
- Шаблон активной записи
- Шаблон переднего контроллера
С таким количеством шаблонов, которые покрыты (и большинство из них хорошо освещены), я был удивлен, увидев такое предложение, как « […] Например, шаблон реестра (не описанный в этой книге)… ». Почему нет? Шаблон реестра является популярным шаблоном, и его очень просто объяснить, даже если в настоящее время он точно не рекомендуется.
Шаблон за шаблоном, каждый объяснен хорошо, и большинство сопровождается примерами кода, демонстрирующими их потенциальную реализацию, хотя я действительно разбираюсь с примером фабричного шаблона с кешем.
Шаблон реализован на примере различных кэшей — APC и Memcache — и оба создаются через фабрику, которая внедряется в любой сервис, нуждающийся в компоненте кэша.
Это имеет смысл для меня, но я вижу менее опытных людей, которые задаются вопросом, зачем вообще нужен шаг Factory, а не просто напишите подсказку к самому интерфейсу кеша в конструкторе, требуя внедрения самого объекта кеша, а не его завод. В текущем примере представлен как интерфейс Factory, так и интерфейс Cache, и, по крайней мере, один кажется излишним. Это никогда не объяснялось доступным для разработчиков средним уровнем, и я боюсь, что это может запутать некоторых. Я также менее чем доволен объяснением паттерна «Мост» — его, кажется, не хватает, как будто его только поцарапали на поверхности, чтобы никогда не вернуться должным образом.
С другой стороны, мне очень понравилось объяснение Composite pattern и его демонстрация на очень интересных примерах Tree — автор строит составное дерево с произвольным числом уровней вложенных узлов, которое фантастически применимо к построению меню, представлению иерархии и многому другому — и я был особенно взволнован объяснением шаблона Decorator. Это было сделано очень доступным способом и на хороших, полезных примерах. Этот шаблон, в частности, был тем, который мне всегда было трудно объяснить людям совершенно неожиданно, когда меня об этом спрашивали, и я пока не нашел лучшего разбора, чем в этой книге.
Пренебрежение моделями
В одном из экземпляров книги Брэндон говорит, что модели — самые тяжелые из приложений MVC, содержащие всю бизнес-логику и код проверки. Это утверждение, которое для меня слишком абсолютное, чтобы принять его — из головы можно вспомнить пример, где это не так: Laravel. С выходом Laravel 5 и добавлением запросов на форму модели станут еще светлее.
Конечно, некоторые люди склонны вкладывать в модели все и кухонную раковину, но есть люди, которые также помещают такое же количество божьего кода в контроллеры. Мой опыт и предпочтения говорят о том, что все, что связано с фреймворком, должно быть очень легким (маленькие контроллеры, маленькие модели, маленькие представления или нет), а все, что связано со службами (сервисы, плагины, библиотеки, помощники), может быть настолько жирным, насколько это необходимо. До тех пор, пока они взаимодействуют между фреймворками. Это личное предпочтение, хотя, я полагаю. Еще одна вещь показалась мне странной, хотя:
« Создание хороших моделей — одна из самых сложных задач, стоящих перед любым разработчиком. Долгое время в документации Zend Framework говорилось, что не существует класса Zend_Model, поскольку создание модели является основной частью процесса разработки приложений. Чтобы создать Zend_Model, нужно предположить, что каждый может или хотел бы использовать одну и ту же структуру модели, что было бы невозможно. По той же причине я не включил ни одного кода в эту главу. »
Несмотря на то, что это имеет смысл, показание примера значения, шлюза и объекта хранения самым простым способом было бы невероятно полезно для людей, впервые знакомых с моделью доменной модели. Модель модели предметной области, на мой взгляд, была слишком пренебрежительной и слишком теоретической в этой книге.
Проклятие знаний
На протяжении всей книги Брэндон ссылается на продвинутые концепции (ORM, наследование, внедрение зависимостей) и сторонний контент, не ссылаясь на него (Gang of Four), предполагая, что читатель знаком со всем этим. В частности, «Банда четырех» упоминается несколько раз и может по меньшей мере использовать ссылку на шаблоны проектирования, иначе «новичок» и «продвинутый читатель-новичок» просто в замешательстве перебирают предложение.
В других случаях структура абзаца написана так, что это далеко за пределы уровня понимания для начинающего пользователя среднего уровня:
Это давний вопрос, с которым многие разработчики все время борются: если я работаю над инвертированием своих зависимостей, а не над созданием объектов внутри моих классов, как я могу создать зависимости, которые мне нужны во время выполнения, которые не обязательно могут быть введены?
Это не на том уровне, который потребляет читатель, которому понадобится эта книга, чтобы ознакомиться с закономерностями. Читатель, который полностью понимает это предложение, вероятно, уже полностью знаком со всеми закономерностями в книге, что ставит под сомнение реальную целевую аудиторию. Я полагаю, что это связано с тем, что мистер Сэвидж страдает от так называемого « проклятия знания ».
Википедия определяет это так:
Проклятие знания — это когнитивное искажение, которое приводит к тому, что лучше информированные стороны считают, что чрезвычайно трудно думать о проблемах с точки зрения менее информированных сторон.
Проклятие знания — это очень распространенное явление среди профессионалов, которые формально не обучены передавать то, что они знают, но также теряют силу со временем, опытом и обратной связью. Именно поэтому мы в SitePoint поощряем людей давать нам честные отзывы о наших публикациях, и именно поэтому мы стараемся упростить и упростить каждую новую публикацию. Никто не застрахован от проклятия — некоторые просто более подвержены его влиянию.
Чума самоиздания
В последние годы самопубликация, кажется, действительно взлетела. Те, кто не прибегают к Leanpub, идут полностью в одиночку, как Брэндон сделал с этой книгой. Хотя этот подход действительно ускоряет процесс и позволяет экспертам передавать качественный контент в руки заинтересованных сторон в угрожающе быстром темпе, он также позволяет избежать ошибок, плохого контента и опечаток.
Большинство проблем, с которыми сталкиваются другие авторы-самоиздатели, также, к сожалению, преследуют эту книгу. Не имея опытного редактора, кажется, не было никакого руководства по содержанию, форме или даже грамматической и синтаксической точности — что-то, что люди, которые являются родными для языка, часто путаются.
Думать, что носители языка не делают ошибок и, следовательно, не нуждаются в формальном редактировании, похоже на, например, компанию, основанную на Y, которая нанимает кого-то из страны X для корректуры их версии сайта на X-языке на единственной основе. из-за того, что корректором является носитель языка X. Вы действительно не хотели бы нанять меня для корректуры вашей хорватской версии веб-сайта, даже если это мой родной язык, но вам будет сложно найти лучшего редактора английского языка.
Вывод
Как опытный пользователь, я уже знал о большинстве, если не обо всех шаблонах, описанных в книге. Тем не менее, объяснения, которые я прошел, были хорошо сформулированы и доступны для среднего пользователя — хотя, на мой взгляд, не для более низкого уровня квалификации. Хотя содержание книги очень хорошее, а Брэндон отлично демонстрирует в коде то, что описывает теория, я чувствую, что книга в целом слишком сложна, чтобы новичок-разработчик не мог извлечь из нее что-то осязаемое.
Сообщество PHP, как мне кажется, страдает от своего рода синдрома «недостающего звена», когда у нас есть книги для начинающих («это эхо, это функция, это тег php») и промежуточный ++ книги, подобные этой, или что-нибудь, что выпустили Осетр, Джонс, Харджес и другие, но есть середина, которая не имеет качественного содержания и может быть завоевана только посредством старого доброго подхода «брось меня в огонь».
Тем не менее, если вы являетесь промежуточным разработчиком, который хочет изучать шаблоны и неуклюжие кивки на конференциях, где люди, стоящие вокруг вас, говорят о них, но вы ничего не понимаете — определенно получите эту книгу. Если вы новичок, я не могу рекомендовать вам купить это — не только пока. Сначала овладейте своим «эхом», узнайте, что такое Composer, а затем погрузите свои зубы в это.
На самом деле, если вы являетесь продвинутым новичком (начинающие должны начинать с самых основ), который, тем не менее, интересуется шаблонами, я приветствую вас и предлагаю вам ознакомиться со следующими ресурсами, прежде чем погрузиться в эту книгу:
- Элементы объектно-ориентированного PHP на Learnable
- Объектно-ориентированный PHP
- Применяется объектно-ориентированный PHP: две армии сражаются друг с другом
- Awesomeness от Alejandro Gervasio — прочитайте все, что этот человек когда-либо писал
- Композитор
- MVC
Что касается содержания, я бы дал книге 4/5, но, учитывая стремительную работу, которая, кажется, была близка к концу, опечатки и языковые ошибки (хотя, чтобы быть справедливым, есть опечатка Github репо, которая Я уже загрязнен исправлениями) и очевидным отсутствием профессионального руководства, а также некоторыми странностями, которые, как я лично считаю, будут встраивать неправильные значения в новичков, натыкающихся на эту книгу (начиная с имен классов с номерами в различных примерах кода), я заканчиваю окончательный счет на 3/5.
