Принципы разработки программных пакетов : проектирование повторно используемых компонентов

Маттиас Нобак

Принципы разработки 
програмных пакетов 
Проектирование 
повторно используемых 
компонентов

Principles 
of Package Design 
Creating Reusable 
Software Components

Matthias Noback

Принципы разработки 
программных пакетов 
Проектирование 
повторно используемых 
компонентов

Маттиас Нобак

Москва, 2020

УДК 
004.971
ББК 
32.972
Н72

Маттиас Нобак
Н72 
Принципы разработки программных пакетов: Проектирование 
повторно используемых компонентов / пер. с анг. Д. А. Беликова. – 
М.: ДМК Пресс, 2020. – 274 с.: ил.

ISBN 978-5-97060-793-0

Существует масса литературы и онлайн-ресурсов, посвященных 
дизайну классов, но информацию о проектировании программных пакетов найти не так просто. Книга Маттиаса Нобака, профессионального 
PHP-разработчика, призвана восполнить этот пробел. В ней рассказывается о принципах повторного использования и распространения 
компонентов, также известных как пакеты, и предлагается ряд полезных техник по организации кода в группы любого размера. Вы узнаете 
о том, какие классы должны быть внутри пакета, как использовать 
принципы связности и зацепления, как облегчить поддержку пакета.
Издание адресовано программистам, использующим объектноориентированный язык для создания приложений. Представленные 
в книге примеры кода поясняют отдельные технические моменты 
и упрощают понимание материала.

УДК 004.971

ББК 32.972

All rights reserved. This work may not be translated or copied in whole or in 
part without the written permission of the author, except for brief excerpts in 
connection with reviews or scholarly analysis. Use in connection with any form 
of information storage and retrieval, electronic adaptation, or computer software 
is forbidden

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

ISBN 978-1-4842-4118-9 (анг.)                              © 2019 Matthias Noback
ISBN 978-5-97060-793-0 (рус.)                              ©  Оформление, издание, перевод, 
ДМК Пресс, 2020

Оглавление

Предисловие от издательства .......................................................................11
Об авторе ....................................................................................................................12
О техническом рецензенте ..............................................................................13
Благодарности .........................................................................................................14
Введение .....................................................................................................................16

ЧАСТЬ I. ПРОЕКТИРОВАНИЕ КЛАССОВ ............................................21

Глава 1 . Принцип единственной ответственности ............................25

Класс со множественными ответственностями ........................25
Ответственности порождают причины для изменения ...........27
Рефакторинг: использование взаимодействующих классов .....28
Преимущества единственной ответственности ........................29
Пакеты и принцип единственной ответственности .................30
Заключение ..................................................................................31

Глава 2. Принцип открытости/закрытости .............................................32

Класс, который закрыт для расширения ....................................32
Рефакторинг: абстрактная фабрика ...........................................35
Рефакторинг: делаем абстрактную фабрику  
открытой для расширения ....................................................39

Замена или декорирование фабрики кодировщика .................40

Делаем EncoderFactory открытым для расширения ................41

Рефакторинг: полиморфизм .......................................................44
Пакеты и принцип открытости/закрытости..............................47
Заключение ..................................................................................48

Глава 3. Принцип подстановки Барбары Лисков ...............................50

Нарушение: производный класс не имеет реализации 
всех методов ..........................................................................52

Протекающие абстракции ........................................................56

Нарушение: разные замены возвращают вещи  
разных типов .........................................................................57

Допустимы более конкретные типы возвращаемых  
значений ................................................................................61

Нарушение: производный класс менее снисходителен 
касательно аргументов метода.............................................62

Нарушение: тайное программирование более  
специфического типа ............................................................66

Пакеты и принцип подстановки Барбары Лисков ....................69
Заключение ..................................................................................70

Глава 4. Принцип разделения интерфейса ............................................72

Нарушение: многократные варианты использования .............72
Рефакторинг: отдельные интерфейсы и множественное 
наследование .........................................................................74

Нарушение: никакого интерфейса, просто класс ......................77

Неявные изменения в неявном интерфейсе ...........................78

Рефакторинг: добавление интерфейсов заголовка и роли .......79
Пакеты и принцип разделения интерфейса ..............................81
Заключение ..................................................................................82

Глава 5. Принцип инверсии зависимостей .............................................83

Пример инверсии зависимостей: генератор FizzBuzz ..............83
Делаем класс FizzBuzz открытым для расширения ...................85
Избавляемся от специфичности .................................................86
Нарушение: высокоуровневый класс зависит  
от низкоуровнего ...................................................................89

Рефакторинг: абстракции и конкретные реализации  
зависят от абстракций ...........................................................92

Нарушение: привязка к поставщику ..........................................96
Решение: добавляем абстракцию и удаляем  
зависимость с помощью композиции ...............................100

Пакеты и принцип инверсии зависимостей ...........................103

Зависимость от стороннего кода: всегда ли это плохо? ........104
Когда публиковать явный интерфейс класса.........................106
Если не все открытые методы предназначены 
для использования обычными клиентами ......................107

Если класс использует ввод/вывод .........................................108
Если класс зависит от стороннего кода ..................................109

6  
Оглавление

Если вы хотите ввести абстракцию для множества 
конкретных вещей ............................................................111

Если вы предвидите, что пользователь захочет  
заменить часть иерархии объектов ..................................112

Для всего остального: придерживайтесь  
финального класса ............................................................114

Заключение ................................................................................115

ЧАСТЬ II. РАЗРАБОТКА ПАКЕТОВ ..................................................... 117

Глава 6. Принцип эквивалентности повторного  
использования и выпуска.............................................................................. 127

Держите свой пакет в системе управления версиями ............129
Добавьте файл определений .....................................................129
Семантическое версионирование ............................................130
Проектирование для обратной совместимости ......................132

Практические правила ............................................................133
Ничего не выбрасывайте ........................................................134
Когда вы что-то переименовываете,  
добавьте посредника .........................................................134

Добавляйте параметры только в конце  
и со значением по умолчанию .........................................136

Методы не должны иметь скрытых побочных эффектов .....137
Версии зависимостей не должны быть очень строгими .......138
Используйте объекты вместо значений  
примитивного типа ...........................................................139

Используйте объекты для инкапсуляции состояния 
и поведения .......................................................................142

Используйте фабрики объектов .............................................144
И так далее… ............................................................................145

Добавьте метафайлы .................................................................146

Файл README и документация ..............................................146
Установка и настройка ............................................................147
Применение .............................................................................147
Точки расширения (не обязательно) ......................................147
Ограничения (не обязательно) ...............................................147
Лицензия ..................................................................................147

Оглавление  7

Журнал изменений (не обязательно) .....................................148
Примечания касательно обновлений (не обязательно) .......149
Руководство по содействию (не обязательно) .......................150

Контроль качества .....................................................................150

Качество с точки зрения пользователя ..................................150
Что нужно сделать человеку, отвечающему за поддержку 
пакета .................................................................................152

Статический анализ ................................................................152
Добавьте тесты .........................................................................152
Настройте непрерывную интеграцию ...................................153

Заключение ................................................................................154

Глава 7. Принцип совместного повторного использования ...... 156

Пласты функций ........................................................................158

Очевидное расслоение ............................................................158
Скрытое расслоение ................................................................160

Классы, которые можно использовать,  
только когда установлен... ..................................................162

Предлагаемый рефакторинг ...................................................166
Пакет должен быть «компонуемым» ......................................167
Чистые релизы .........................................................................169

Бонусные функции ....................................................................173

Предлагаемый рефакторинг ...................................................175

Наводящие вопросы ..................................................................177

Когда применять этот принцип ..............................................178
Когда нарушать принцип ........................................................179
Почему не следует нарушать этот принцип ..........................179

Заключение ................................................................................180

Глава 8. Принцип общей закрытости ...................................................... 181

Изменение в одной из зависимостей ......................................182

Assetic .......................................................................................183

Изменение на уровне приложения ..........................................185

FOSUserBundle..........................................................................186

Изменения, продиктованные бизнесом ..................................189

Sylius .........................................................................................190

Бизнес-логика ............................................................................191

8  
Оглавление

Треугольник принципов связности..........................................193
Заключение ................................................................................195

Глава 9. Принцип ацикличности зависимостей ................................ 196

Зацепление: выявление зависимостей ....................................196
Различные способы зацепления пакетов ................................197

Композиция .............................................................................198
Наследование ...........................................................................198
Реализация ...............................................................................199
Использование .........................................................................199
Инстанцирование ....................................................................199
Использование глобальной функции .....................................200
Что не следует учитывать: глобальное состояние .................201

Визуализация зависимостей ....................................................201
Принцип ацикличности зависимостей ....................................203
Проблемные циклы ...................................................................204
Решения, позволяющие разорвать циклы ...............................207

Псевдоциклы и избавление от них .........................................207
Реальные циклы и избавление от них....................................210
Инверсия зависимостей ..........................................................211
Инверсия управления .............................................................213
Посредник ................................................................................214
Цепочка обязанностей ............................................................217

Сочетание Посредника и Цепочки обязанностей:  
система событий ..................................................................218

Заключение ................................................................................223

Глава 10. Принцип устойчивых зависимостей .................................. 224

Устойчивость ..............................................................................225
Не каждый пакет может быть высокостабильным ..................228
Нестабильные пакеты должны зависеть только от более 
стабильных ...........................................................................229

Оценка устойчивости ................................................................230
Снижение нестабильности и повышение устойчивости ........231

Вопрос: следует ли учитывать все пакеты,  
какие есть во вселенной? ..................................................233

Нарушение: ваш стабильный пакет зависит от стороннего 
нестабильного пакета .........................................................234

Оглавление  9

Решение: используйте инверсию зависимостей .....................237
Пакет может быть как ответственным, так и наоборот ..........240
Заключение ................................................................................242

Глава 11. Принцип устойчивых абстракций ....................................243

Устойчивость и абстрактность ..................................................243
Как определить, является ли пакет абстрактным ...................246
А-метрика ..................................................................................246
Абстрактные вещи в стабильных пакетах ...............................247
Абстрактность возрастает по мере роста устойчивости .........248
Главная последовательность .....................................................249
Типы пакетов .............................................................................251

Странные пакеты .....................................................................252

Заключение ................................................................................254

Глава 12. Заключение ...............................................................................256

Создание пакетов – это сложно ................................................256

Повторное использование «в малом» ....................................256
Повторное использование «в большом» ................................257
Разнородность программного обеспечения ..........................258
Повторное использование компонентов возможно,  
но требует больше работы ................................................259

Создание пакетов – выполнимая задача .................................259

Уменьшение воздействия первого из трех правил ...............260
Уменьшение воздействия второго из трех правил ...............261

Создание пакетов – это легко? .................................................262

Приложение A. Полный вариант класса Page ................................... 263
Предметный указатель ................................................................................... 273

10  
Оглавление

Предисловие от издательства

Отзывы и пОжелания
Мы всегда рады отзывам наших читателей. Расскажите нам, что вы 
думаете об этой книге – что понравилось или, может быть, не понравилось. Отзывы важны для нас, чтобы выпускать книги, которые 
будут для вас максимально полезны.
Вы можете написать отзыв прямо на нашем сайте www.dmkpress.
com, зайдя на страницу книги, и оставить комментарий в разделе 
«Отзывы и рецен зии». Также можно послать письмо главному редактору по адресу dmkpress@gmail.com, при этом напишите название книги в теме письма.
Если есть тема, в которой вы квалифицированы, и вы заинтересованы в написании новой книги, заполните форму на нашем 
сайте по адресу http://dmkpress.com/authors/publish_book/ 
или напишите в издательство по адресу dmkpress@gmail.com.
СпиСОк ОпечатОк
Хотя мы приняли все возможные меры для того, чтобы удостовериться в качест ве наших текстов, ошибки все равно случаются. Если 
вы найдете ошибку в одной из наших книг – возможно, ошибку 
в тексте или в коде, – мы будем очень благодарны, если вы сообщите 
нам о ней. Сделав это, вы избавите других читателей от расстройств 
и поможете нам улучшить последующие версии этой книги.
Если вы найдете какие-либо ошибки в коде, пожалуйста, сообщите о них главному редактору по адресу dmkpress@gmail.com, 
и мы исправим это в следующих тиражах.
нарушение автОрСких прав
Пиратство в интернете по-прежнему остается насущной проблемой. Издательство «ДМК Пресс» очень серьезно относится 
к вопросам защиты авторских прав и лицензирования. Если вы 
столкнетесь в интернете с незаконно выполненной копией любой 
нашей книги, пожалуйста, сообщите нам адрес копии или вебсайта, чтобы мы могли применить санкции.
Пожалуйста, свяжитесь с нами по адресу электронной почты 
dmkpress@gmail.com со ссылкой на подозрительные материалы.
Мы высоко ценим любую помощь по защите наших авторов, помогающую нам предоставлять вам качественные материалы.

Об авторе

Маттиас Нобак – профессиональный PHPразработчик. Он является основателем 
компании Noback's Office, специализирующейся на веб-разработке, тренингах 
и консалтинге. Ранее он работал в качестве 
разработчика в компании Driebit (Амстердам) и IPPZ (Утрехт), а также в качестве 
технического директора (CTO) в компании 
Ibuildings (Утрехт). С 2011 года он ведет блог 
(matthiasnoback.nl), где пишет на темы, относящиеся к продвинутым аспектам разработки программного обеспечения. Более 
всего Маттиаса интересует архитектура 
программного обеспечения, унаследованный код, тестирование и дизайн объектов 
в ООП. Маттиас также является автором 
книг «Один год с Symfony« и «Микросервисы для всех». В Twitter Маттиас пишет под 
ником @matthiasnoback.

О техническом рецензенте

Росс Так (Ross Tuck) – инженер по разработке программного обеспечения и тренер. На конференциях по всему миру он рассказывает о разработке программного обеспечения, а также является 
участником подкастов, автором статей и время от времени вносит 
свой вклад в репозитории на GitHub. Будучи родом из США, сейчас 
он проживает в Нидерландах вместе супругой и котом. В Twitter он 
известен как @rosstuck.

Благодарности

В первую очередь хочу выразить благодарность нескольким людям.
Во-первых, Роберту Мартину (Robert C. Martin). Многие принципы проектирования, рассмотренные в этой книге, были рождены 
в результате его работы.
Также хочу поблагодарить тех, кто предоставил ценные замечания в процессе корректуры первой версии книги, а именно: 
Брайан Фентон (Brian Fenton), Кевин Арчер (Kevin Archer), Луис 
Кордова (Luis Cordova), Марк Бадолато (Mark Badolato), Маттис ван 
Ритшотен (Matthijs van Rietschoten), Рамон де ла Фуэнте (Ramon de 
la Fuente), Ричард Перез (Richard Perez), Рольф Бабийн (Rolf Babijn), 
Себастиан Сток (Sebastian Stok), Томас Стоун (Thomas Shone) и Питер Рем (Peter Rehm).
Одного из корректоров я хочу упомянуть отдельно – это Питер 
Бойер (Peter Bowyer), он был автором многих детальных предложений. Он также сделал одно блестящее предложение – сделать эту 
книгу, изначально ориентированную на PHP, интересной и полезной любому разработчику. И хотя эта книга не привязана к конкретному языку программирования, я многим обязан одному 
конкретному сообществу, к которому я принадлежу: сообществу 
PHP-разработчиков.
Спасибо вам всем за то, что вы такие классные – каждый день 
предоставляете отличные материалы для чтения, генерируете замечательные идеи, приглашаете по-дружески на различные мероприятия, пишите много хорошего кода. Огромное спасибо Россу 
(Ross Tuck), который выполнил тщательный технический обзор 
второй редакции этой книги. И хотя он добавил мне много работы, 
я очень рад, что он это сделал. Он сделал много рекомендаций по 
тому, как я мог бы сделать книгу более полезной и более понятной 
для широкого круга читателей с разными точками зрения и разным опытом в этой области.
Отдельное спасибо издательству Apress, в частности Шиве 
(Shiva), Лауре (Laura) и Рите (Rita) – за то, что взялись за работу 

над книгой «Принципы разработки пакетов», и за то, что предоставили возможность выпустить ее в значительно лучшей форме, 
в то же время делая ее доступной для значительно большего числа 
читателей.
И наконец, спасибо вам, Лайз (Lies), Лукас (Lucas) и Джулия 
(Julia). Спасибо вам, что позволили мне отвлечься от семейного 
бизнеса и написать эту книгу в одиночестве. И спасибо, что всегда 
обнимали меня, когда я возвращался.

Благодарности  15

Введение

В процессе написания я полагал что вы, читающие эту книгу, программисты и используете объектно-ориентированный язык для 
создания приложений. Это означает, что у вас есть некоторый 
опыт в создании классов, методов, интерфейсов и т. д. и вы так или 
иначе пытаетесь заставить все эти элементы корректно работать 
вместе. И хотя вы, вероятно, знаете, как это сделать, время от времени вы задаетесь вопросом: «А правильно ли я всё делаю?»
Это хороший и понятный вопрос. Будучи программистом, вы 
ежедневно вынуждены принимать множество решений – вполне 
естественно беспокоиться о том, принимаются ли правильные решения. Плохое решение сегодня может превратиться в большие 
объемы дополнительной работы позже.
К сожалению, нет простого способа понять, делаете ли вы что-то 
правильно. Лучшее, что можно сделать, – это следить за развитием 
событий и быть готовым изменить курс, если это будет необходимо. Но чтобы тренировать внимание и способность предсказывать, как будут развиваться события, нужно, помимо собственного 
опыта, также обращаться и к другим источникам. Например, можно читать книги по программированию или же перенимать опыт 
других программистов.
Когда я хочу выложить какой-то код в open source, полагая, что 
он может быть полезен другим разработчикам, я тоже задаюсь вопросом «а делаю ли я это правильно?». И я начал искать источники 
знаний, где мог бы получить ответ на свой вопрос. Что касается дизайна классов, существует огромное количество онлайн- и офлайнресурсов. Намного больше, чем ресурсов о дизайне программных 
пакетов. Я не смог найти много материала, который помог бы 
мне лучше создавать пакеты, за исключением нескольких разделов в книге (и никогда целой книги, посвященной этому вопросу!) 
и нескольких старых статей.
Одним из часто встречающихся источников был веб-сайт Роберта Мартина (Robert C. Martin’s) butunclebob.com, на котором есть 
несколько статей о принципах проектирования SOLID и две статьи 
о принципах проектирования компонентов. В этих статьях Роберт