РНР: объекты, шаблоны и методики программирования [Мэтт Зандстра] (pdf) читать онлайн

Влад и мир про Шенгальц: Черные ножи (Альтернативная история)

Читать не интересно. Стиль написания - тягомотина и небывальщина. Как вы представляете 16 летнего пацана за 180, худого, болезненного, с больным сердцем, недоедающего, работающего по 12 часов в цеху по сборке танков, при этом имеющий силы вставать пораньше и заниматься спортом и тренировкой. Тут и здоровый человек сдохнет. Как всегда автор пишет о чём не имеет представление. Я лично общался с рабочим на заводе Свердлова, производившего

подробнее ...

авиадвигатели во время войны. Так вот будучи не совершеннолетним после училища опоздал на 15 минут в первый день выхода на работу, получил 1 год Гулага. А тут ГГ с другом опаздывают и даже не приходят на работу на танкостроительный завод? Там не с кем не нянчились, особисты с НКВД на фронт не хотели даже в заградотряды и зверствовали по любому поводу и без. У него танки собирают на конвейере. Да такого и сейчас никто не додумался. Вы представляете вес танка и сколько корпусов должен тащить такой конвейер? Где вы видели в СССР краны, позволяющие сбрасывать груз с крюка по кнопке? Я был на многих заводах с кранбалками и не разу не видал такой конструкции. Сколько тон поднимает кран и какой величины и мощности должно быть реле, что бы сместить задвижку под такой нагрузкой? Более того инструкции техника безопасности по работе в цехах не предусматривают такой возможности в принципе. Да и сами подумайте, электро выбрасыватель на крюке, значит нужны провода с барабаном. А кабеля не любят перегибов и даже гибкие. Кто возьмётся в своём уме даже проектировать такое устройство на кранбалке в цеху. Перестрелка ГГ с 5 ворами вообще дебильная. Имея вальтер, стрельбу в упор, ГГ стреляет так медленно, что пьяные в хлам воры успевают гораздо больше, чем ГГ жмет пальцем на курок. Дважды выстрелить из обреза, опрокинуть стол, метнуть нож. И ГГ якобы был воином и остаётся отличным стрелком. Воры с обрезами в городе - это вообще анекдот и вышка при любых ситуациях в те годы. А человеченка в кастрюле при наличии кучи денег? У автора очень странное воображение. Я вообще то не представляю как можно в открытую держать воющую женщину в сарае зимой в населённом пункте? Зачем сжигать дом людоедов, если есть свидетель? Ну убил людоедов - хорошо. Сжёг дом с уликами - другая статья. Глупость во всём полная. "Сунул спичку в бак". Я люблю фантастику и фентази, но не дурацкую писанину. Стиль написания далёк от художественного, всё герои выражаются в одном стиле, больше похожий на официальный язык прожжённого офисного бюрократа. Одни и те же словарные обороты. Так пишут боты.

Рейтинг: 0 ( 0 за, 0 против).

Влад и мир про Владимиров: Ирландец 2 (Альтернативная история)

Написано хорошо. Но сама тема не моя. Становление мафиози! Не люблю ворьё. Вор на воре сидит и вором погоняет и о ворах книжки сочиняет! Любой вор всегда себя считает жертвой обстоятельств, мол не сам, а жизнь такая! А жизнь кругом такая, потому, что сам ты такой! С арифметикой у автора тоже всё печально, как и у ГГ. Простая задачка. Есть игроки, сдающие определённую сумму для участия в игре и получающие определённое количество фишек. Если в

подробнее ...

полуфинале на кону стояло 5000, то финалист выиграл 20 000, а в банке воры взяли чуть больше 7 тысяч. А где деньги? При этом игрок заявил, что его денег, которые надо вернуть 4000, а не на порядок меньше. Сравните с сумой полуфинала. Да уж если ГГ присутствовал на игре, то не мог знать сумму фишек для участия. ГГ полный лох.Тем более его как лоха разводят за чужие грехи, типо играл один, а отвечают свидетели. Тащить на ограбление женщину с открытым лицом? Сравним с дебилизмом террористов крокуса, которым спланировали идеально время нападения,но их заставили приехать на своей машине, стрелять с открытыми лицами, записывать на видео своих преступлений для следователя, уезжать на засвеченной машине по дальнему маршруту до границы, обеспечивая полную базу доказательств своих преступлений и все условия для поимки. Даже группу Игил организовали, взявшую на себя данное преступление. Я понимаю, что у нас народ поглупел, но не на столько же!? Если кто-то считает, что интернет не отслеживает трафик прохождения сообщения, то пусть ознакомится с протоколами данной связи. Если кто-то передаёт через чужой прокси сервер, то сравнить исходящящйю с чужого адреса с входящим на чужой адрес с вашего реального адреса технически не сложно для специалистов. Все официальные анонимные серверы и сайты "террористов" давно под контролем спецслужб, а скорей всего ими и организованы, как оффшорные зоны для лохов, поревевших в банковские тайны. А то что аффшорные зоны как правило своёй твёрдой валюты в золоте не имеют и мировой банковской сети связи - тоже. Украл, вывел рубли в доллары в оффшорную зону и ты на крючке у хозяев фантиков МВФ. Хочешь ими попользоваться - служи хозяевам МВФ. И так любой воришка или взяточник превращаеится агента МВФ. Как сейчас любят клеить ярлыки -иноогенты, а такими являются все банки в России и все, кто переводит рубли в иную валюту (вывоз капиталов и превращение фантиков МВФ в реальные деньги). Дебилизм в нашей стране зашкаливает! Например - Биткоины, являются деньгами, пока лохи готовы отдавать за них реальные деньги! Все равно, что я завтра начну в интернете толкать свои фантики, но кто мне даст без "крыши". Книги о том как отжимать деньги мне интересны с начала 90х лишь как опыт не быть жертвой. Потому я сравнительно легко отличаю схему реально рабочего развода мошенников, от выдуманного авторами. Мне конечно попадались дебилы по разводам в жизни, но они как правило сами становились жертвами своих разводов. Мошенничество = это актерское искусство на 99%, большая часть которого относится к пониманию психологии жертвы и контроля поведения. Нет универсальных способов разводов, действующих на всех. Меня как то пытались развести на деньги за вход с товаром на Казанский вокзал, а вместо этого я их с ходу огорошил, всучил им в руки груз и они добровольно бежали и грузили в пассажирский поезд за спасибо. При отходе поезда, они разве что не ржали в голос над собой с ответом на вопрос, а что это было. Всего то надо было срисовать их психопрофиль,выругаться матом, всучить им в руки сумки и крикнуть бежать за мной, не пытаясь их слушать и не давать им думать, подбадривая командами быстрей, опоздаем. А я действительно опаздывал и садился в двигающийся вагон с двумя системными блоками с мониторами. Браткам спасибо за помощь. И таких приключений у меня в Москве были почти раз в неделю до 1995 года. И не разу я никому ничего не платил и взяток не давал. Имея мозги и 2 годичный опыт нештаного КРСника, на улице всегда можно найти выход из любой ситуации. КРС - это проверка билетов и посажирского автотранспорта. Через год по реакции пассажира на вас, вы чувствуете не только безбилетника, но и примерно сколько денег у того в карманах. Вы представьте какой опыт приобретает продавец, мент или вор? При этом получив такой опыт, вы можете своей мимикой стать не видимым для опыта подобных лиц. Контролёры вас не замечают, кассиры по 3 раза пытаются вам сдать сдачу. Менты к вам не подходят, а воры не видят в вас жертву и т.д. Важен опыт работы с людьми и вы всегда увидите в толпе прохожих тех, кто ищет себе жертву. Как правило хищники друг друга не едят, если не требуется делить добычу. Строите рожу по ситуации и вас не трогают или не видят, а бывает и прогибаются под вас - опыт КРС по отъёму денег у не желающих платить разной категории людей - хороший опыт, если сумеешь вовремя бросить это адреналиновое занятие, так как развитие этой работы приводит часто к мошенничеству. Опыт хищника в меру полезен. Без меры - вас просто уничтожают конкуренты. Может по этому многие рассуждения и примеры авторов мне представляются глупостью и по жизни не работают даже на беглый взгляд на ситуацию, а это очень портит впечатление о книге. Вроде получил созвучие души читателя с ГГ, а тут ляп автора опускающий ГГ на два уровня ниже плинтуса вашего восприятия ГГ и пипец всем впечатлениям и все шишки автору.

Рейтинг: 0 ( 0 за, 0 против).

DXBCKT про Дамиров: Курсант: Назад в СССР (Детективная фантастика)

Месяца 3-4 назад прочел (а вернее прослушал в аудиоверсии) данную книгу - а руки (прокомментировать ее) все никак не доходили)) Ну а вот на выходных, появилось время - за сим, я наконец-таки сподобился это сделать))

С одной стороны - казалось бы вполне «знакомая и местами изьезженная» тема (чуть не сказал - пластинка)) С другой же, именно нюансы порой позволяют отличить очередной «шаблон», от действительно интересной вещи...

В начале

подробнее ...

(терпеливого читателя) ждет некая интрига в стиле фильма «Обратная сторона Луны» (битый жизнью опер и кровавый маньяк, случайная раборка и раз!!! и ты уже в прошлом)). Далее... ОЧЕНЬ ДОЛГАЯ (и местами яб таки сказал немного нудная) инфильтрация героя (который с большим для себя удивлением узнает, что стать рядовым бойцом милиции ему просто не светит — при том что «опыта у него как у дурака махорки»))

Далее начинается (ох как) не простая инфильтрация и поиски выхода «на нужное решение». Параллельно с этим — появляется некий «криминальный Дон» местного разлива (с которым у ГГ разумеется сразу начинаются «терки»))

Вообще-то сразу хочу предупредить — если Вы ищете чего-то «светлого» в стиле «Квинт Лециний» (Королюка) или «Спортсменки, комсомолки» (Арсеньева), то «это Вам не здесь»)) Нет... определенная атмосфера того времени разумеется «имеет место быть», однако (матерая) личность ГГ мгновенно перевешивает все эти «розовые нюни в стиле — снова в школу, УРА товариСчи!!!)) ГГ же «сходу» начинает путь вверх (что впрочем все же не влечет молниеносного взлета как в Поселягинском «Дитё»)), да и описание криминального мира (того времени) преподнесено явно на уровне.

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

В остальном — каждая новая часть напоминает «дело №» - в котором ГГ (в очередной раз) проявляет себя (приобретая авторитет и статус) решая ту или иную «задачу на повестке дня»

P.S Да и если есть выбор между аудиоверсией и книгой, советую именно аудиоверсию)) Книгу то я прочел дня за 2, а аудиоверсию слушал недели две)) А так и восприятие лучше и плотность изложения... А то прочитал так часть третью (в отсутсвии аудиоверсии на тот момент), а теперь хочу прослушать заново (уже по ней)) Но это все же - субьективно)) Как говорится — кому как))

Рейтинг: +1 ( 1 за, 0 против).

DXBCKT про Стариков: Геополитика: Как это делается (Политика и дипломатия)

Вообще-то если честно, то я даже не собирался брать эту книгу... Однако - отсутствие иного выбора и низкая цена (после 3 или 4-го захода в книжный) все таки "сделали свое черное дело" и книга была куплена))

Не собирался же ее брать изначально поскольку (давным давно до этого) после прочтения одной "явно неудавшейся" книги автора, навсегда зарекся это делать... Но потом до меня все-таки дошло что (это все же) не "очередная злободневная" (читай

подробнее ...

политизированная) тема, а просто экскурс по (давным давно напрочь, забытой мной) истории... а чисто исторические книги (у автора) получались всегда отменно. Так что я окончательно решил сделать исключение и купить данную книгу (о чем я впоследствии не пожалел). И да... поначалу мне (конечно) было несколько трудновато различать все эти "Бургундии" (и прочие давным-давно забытые лимитрофы), но потом "процесс все же пошел" и книга затянула не на шутку...

Вообще - пересказывать историю можно по разному. Можно сыпать сухими фактами и заставить читателя дремать (уже) на второй странице... А можно (как автор) излагать все вмолне доступно и весьма интересно. По стилю данных хроник мне это все сдорово напомнило Гумилева, с его "от Руси, до России" (хотя это сравнение все же весьма весьма субьективно)) В общем "окончательный вердикт" таков - если Вы все же "продеретесь сквозь начало и втянетесь", книга обязательно должна Вас порадовать...

И конечно (кто-то здесь) обязательно начнет "нудный бубнеж" про: "жонглирование фактами" и почти детективный стиль подачи материала... Но на то и нужна такая подача - ибо как еще заинтересовать "в подобных веСчах", не "узколобую профессуру" (сыпящую датами и ссылками на научные труды очередного "заслуженного и всепризнанного..."), а простого и нескушенного читателя (по типу меня) который что-то документальное читает от раз к разу, да и то "по большим праздникам"?)) За сим и откланиваюсь (блин вот же прицепилось))

P.s самое забавное что читая "походу пьесы" (параллельно) совсем другую веСчь (уже художественного плана, а именно цикл "Аз есмь Софья") как ни странно - смог разобраться в данной (географии) эпохи, как раз с помощью книги тов.Старикова))

Рейтинг: +1 ( 1 за, 0 против).

DXBCKT про Москаленко: Малой. Книга 3 (Боевая фантастика)

Третья часть делает еще более явный уклон в экзотерику и несмотря на все стсндартные шаблоны Eve-вселенной (базы знаний, нейросети и прочие девайсы) все сводится к очередной "ступени самосознания" и общения "в Астралях")) А уж почти каждодневные "глюки-подключения-беседы" с "проснувшейся планетой" (в виде галлюцинации - в образе симпатичной девчонки) так и вообще...))

В общем герою (лишь формально вникающему в разные железки и нейросети)

подробнее ...

Рейтинг: +1 ( 1 за, 0 против).

Все впечатления

РНР: объекты, шаблоны и методики программирования [Мэтт Зандстра] (pdf) читать онлайн

Книга в формате pdf! Изображения и текст могут не отображаться!

[Настройки текста]

[Cбросить фильтры]

PHP: объекты,
шаблоны и методики
программирования
Пятое издание

PHP Objects, Patterns,
and Practice

ив И n
Matt Zandstra

Apress

PHP: объекты,
шаблоны и методики
программирования
Пятое издание

Мэтт Зандстра

Москва • Санкт-Петербург
2019

ББК 32.973.26-018.2.75
3-27
УДК 681.3.07
ООО '‘Диалектика"
Перевод с английского И.В. Берштейна
Под редакцией канд. физ.-маг. наук С.Г. Тригуб

По общим вопросам обращайтесь в издательство “Диалектика" по адресу:
info@dialektika.com, http://www.dialektika.com

Зандстра, Мэтг.
3-27
РНР: объекты, шаблоны и методики программирования, 5-е изд. : Пер. с англ. — СПб. :
ООО “Диалектика", 2019. — 736 с. : ил. — Парал. тит. англ.
ISBN 978-5-907144-54-5 (рус.)
ББК 32.973.26-018.2.75
Все названия программных продуктов являются зарегистрированными торговыми марками соответ
ствующих фирм.
Никакая часть настоящего издания ни в каких целях не может быть воспроизведена в какой бы то
ни было форме и какими бы го ни было средствами, будь то электронные или механические, включая
фозхжопирование и запись на магнитный носитель, если на это нет письменного разрешения издательства
APress, Berkeley, СА.

Authorized Russian translation of the English edition of PHP: Objects, Patterns, and Practice, 5th Edition (ISBN
978-1-4842-1995-9), published by APress, Inc., Copyright © 2017 by Matt Zandstra.
This translation is published and sold by permission of APress, Inc., which owns or controls all rights to sell
the same.
All rights reserved. No part of this work may be reproduced or transmitted in any form or by any means,
electronic or mechanical, including photocopying, recording, or by any information storage or retrieval system,
without the prior written permission of the copyright owner and the publisher. Trademarked names may appear in
this book. Rather than use a trademark symbol with every occurrence of a trademarked name, we use the names only
in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark.

Научно-популярное издание

Мэтт Зандстра
РНР: объекты, шаблоны
и методики программирования
5-е издание
Подписано в печать 10.06.2019. Формат 70x100/16.
Гарнитура Times.
Усл. печ. л. 46,0. Уч.-изд. л. 36,8.
Тираж 500 экз. Заказ № 4893.
Отпечатано в АО “Первая Образцовая типография”
Филиаз “Чеховский Печатный Двор”
142300, Московская область, г. Чехов, ул. Полиграфистов, д. 1
Сайт: www.chpd.ru, E-mail: sales@chpd.ru, тел. 8 (499) 270-73-59
ООО “Диалектика”, 195027, Санкт-Петербург, Магнитогорская ул., д. 30, лит. А, пом. 848

ISBN 978-5-907144-54-5 (рус.)
ISBN 978-1-4842-1995-9 (англ.)

© ООО “Диалектика”, 2019
© 2017 by Matt Zandstra

Оглавление
Об авторе

15

Введение

19

Часть I. Введение

21

Глава 1. Проектирование и сопровождение приложений на РНР

23

Часть II. Объекты

35

Глава 2. РНР и объекты

Глава 5. Средства для работы с объектами

37
45
85
151

Глава 6. Объекты и проектирование

193

Часть III. Шаблоны

221

Глава 3. Основные положения об объектах
Глава 4. Расширенные средства

Глава 7. Назначение и применение проектных шаблонов
Глава 8. Некоторые принципы действия шаблонов
Глава 9. Формирование объектов
Глава 10. Шаблоны для программирования гибких объектов

Глава 11. Выполнение задач и представление результатов
Глава 12. Шаблоны корпоративных приложений

223
235
253
291
319
369

Глава 13. Шаблоны баз данных

433

Часть IV. Практика

489

Глава 14. Нормы надлежащей и порочной практики
Глава 15. Стандарты РНР

491
503

Глава 20. Виртуальная машина Vagrant

523
537
569
607
635

Глава 21. Непрерывная интеграция

649

Часть V. Заключение

679

Глава 22. Объекты, шаблоны и практика

681

Часть VI. Приложения

695

Приложение А. Дополнительные источники информации

697

Приложение Б. Простой синтаксический анализатор

703

Предметный указатель

729

Глава 16. Создание и использование компонентов РНР средствами Composer
Глава 17. Контроль версий средствами Git
Глава 18. Тестирование средствами PHPUnit
Глава 19. Автоматическое построение средствами Piling

Содержание
15
17
17

Об авторе

О техническом рецензенте
Благодарности

19
20

Введение

От издательства

Часть I. Введение

21

Глава 1. Проектирование и сопровождение приложений на РНР

Проблема
РНР и другие языки
Об этой книге
Объекты
Шаблоны
Практика
Что нового в пятом издании книги
Резюме

23
23
25
28
29
29
30
32
32

Часть II. Объекты

35

Глава 2. РНР и объекты

37
37
37
38
38
41
41
42
43

Неожиданный успех объектов в РНР
Вначале был PHP/F1
Синтаксические удобства в версии РНР 3
Версия РНР 4 и незаметная революция
Изменения приняты: РНР 5
Восполнение пробела: РНР 7
Дебаты сторонников и противников объектов
Резюме
Глава 3. Основные положения об объектах

Классы и объекты
Первый класс
Несколько первых объектов
Установка свойств в классе
Работа с методами
Создание метода-конструктора
Аргументы и типы
Простые типы данных
Уточнение типов объектов
Наследование
Проблема наследования
Использование наследования
Управление доступом к классам: модификаторы
Методы доступа
Семейство классов ShopProduct
Резюме

public, private

и

protected

45
45
45
46
47
51
52
54
54
59
64
65
70
77
79
80
83

Глава 4. Расширенные средства

Статические методы и свойства
Постоянные свойства
Абстрактные классы
Интерфейсы
Трейты
Проблема, которую позволяют решить трейты
Определение и применение трейтов
Применение нескольких трейтов
Сочетание трейтов с интерфейсами
Устранение конфликтов имен методов спомощью ключевого слова insteadof
Назначение псевдонимов переопределенным
методам трейта
Применение статических методов в трейтах
Доступ к свойствам базового класса
Определение абстрактных методов в трейтах
Изменение прав доступа к методам трейта
Позднее статическое связывание: ключевое слово static
Обработка ошибок
Исключения
Завершенные классы и методы
Внутренний класс Error
Работа с методами-перехватчиками
Определение методов-деструкторов
Копирование объектов с помощью метода__ clone ()
Определение строковых значений для объектов
Функции обратного вызова, анонимные функции и механизм замыканий
Анонимные классы
Резюме
Глава 5. Средства для работы с объектами

РНР и пакеты
Пакеты и пространства имен в РНР
Пути включения файлов
Автозагрузка
Функции для исследования классов и объектов
Поиск классов
Получение сведений об объекте или классе
Получение полностью уточненной строковой ссылки на класс
Получение сведений о методах
Получение сведений о свойствах
Получение сведений о наследовании
Вызов методов
Интерфейс Reflection API
Краткое введение в Reflection API
Время засучить рукава
Исследование класса
Исследование методов
Исследование аргументов методов
Применение интерфейса Reflection API
Резюме

85
86
90
91
93
96
96
98
99
100
101

102
103
104
105
106
107
112
114
123
125
126
134
135
139
140
147
149
151
151
152
160
163
167
169
170
171
172
174
174
175
177
177
178
181
183
185
187
192

Определение программного проекта
Объектно-ориентированное и процедурное программирование
Ответственность
Связность
Тесная связь
Ортогональность
Выбор классов
Полиморфизм
Инкапсуляция
Забудьте, как это делается
Четыре явных признака недоброкачественного кода
Дублирование кода
Класс, который слишком много знал
На все руки мастер
Условные операторы
Язык UML
Диаграммы классов
Диаграмма последовательностей
Резюме

193
193
194
199
200
200
201
201
203
205
206
207
207
208
208
208
209
209
217
219

Часть III. Шаблоны

221

Глава 7. Назначение и применение проектных шаблонов

223
224
227
227
227
228
228
228
229
230
230
230
230
231
231
232
232
232
233

Глава 6. Объекты и проектирование

Что такое проектные шаблоны
Краткий обзор проектных шаблонов
Название
Постановка задачи
Решение
Последствия
Формат “Банды четырех”
Причины для применения проектных шаблонов
Шаблоны определяют задачи
Шаблоны определяют решения
Шаблоны не зависят от языка программирования
Шаблоны определяют словарь
Шаблоны проверяются и тестируются
Шаблоны предназначены для совместной работы
Шаблоны способствуют удачным проектам
Шаблоны применяются в распространенных каркасах
РНР и проектные шаблоны
Резюме
Глава 8. Некоторые принципы действия шаблонов

Открытие шаблонов
Композиция и наследование
Проблема
Применение композиции
Развязка
Проблема
Ослабление связанности
Программируйте на основе интерфейса, а не его реализации

235
235
236
236
240
243
243
245
247

Меняющаяся концепция
Проблемы применения шаблонов
Шаблоны
Шаблоны для формирования объектов
Шаблоны для организации объектов и классов
Шаблоны, ориентированные на задачи
Промышленные шаблоны
Шаблоны баз данных
Резюме

249
250
250
251
251
251
251
251
251

Глава 9. Формирование объектов

253
253
259
260
260
263
263
263
267
269
270
270
271
274
276
276
277
281
283
283
284
288
289

Формирование объектов: задачи и решения
Шаблон Singleton
Проблема
Реализация
Выводы
Шаблон Factory Method
Проблема
Реализация
Выводы
Шаблон Abstract Factory
Проблема
Реализация
Выводы
Шаблон Prototype
Проблема
Реализация
Доведение до крайности: шаблон Service Locator
Блестящее одиночество: шаблон Dependency injection
Проблема
Реализация
Выводы
Резюме
Глава 10. Шаблоны для программирования гибких объектов

Структурирование классов для повышения гибкости объектов
Шаблон Composite
Проблема
Реализация
Выводы
Краткие выводы по шаблону Composite
Шаблон Decorator
Проблема
Реализация
Выводы
Шаблон Facade
Проблема
Реализация
Выводы
Резюме
Глава 11. Выполнение задач и представление результатов

Шаблон Interpreter
Проблема

291
291
292
292
295
300
304
305
305
308
313
313
314
315
316
317
319
319
320

Реализация
Трудности реализации шаблона interpreter
Шаблон Strategy
Проблема
Реализация
Шаблон Observer
Реализация
Шаблон Visitor
Проблема
Реализация
Трудности реализации шаблона visitor
Шаблон Command
Проблема
Реализация
Шаблон Null Object
Проблема
Реализация
Резюме

321
331
332
332
333
337
340
347
347
349
355
355
355
356
361
362
365
366

Глава 12. Шаблоны корпоративных приложений

369
370
370
371
374
374
3 81
382
395
410
417
421
421
427
431

Краткий обзор архитектуры
Шаблоны
Приложения и уровни
Нарушение правил с самого начала
Шаблон Registry
Уровень представления данных
Шаблон Front Controller
Шаблон Application Controller
Шаблон Page Controller
Шаблоны Template View И View Helper
Уровень логики приложения
Шаблон Transaction Script
Шаблон Domain Model
Резюме
Глава 13. Шаблоны баз данных

Уровень хранения данных
Шаблон Data Mapper
Проблема
Реализация
Результаты
Шаблон Identity Мар
Проблема
Реализация
Результаты
Шаблон Unit of Work
Проблема
Реализация
Результаты
Шаблон Lazy Load
Проблема
Реализация
Результаты
Шаблон Domain Object Factory
Проблема

433
433
434
434
435
452
453
453
454
458
458
458
459
463
464
464
465
467
467
468

Реализация
Результаты
Шаблон Identity Object
Проблема
Реализация
Результаты
Шаблоны Selection Factory и Update Factory
Проблема
Реализация
Результаты
Что теперь осталось от шаблона Data Mapper?
Резюме

468
469
471
472
472
479
479
480
480
484
485
488

Часть IV. Практика

489

Глава 14. Нормы надлежащей и порочной практики

491
492
492
495
496
497
498
499
500
501

Не кодом единым
Снова изобретаем колесо
Ведите себя хорошо
Дайте коду крылья
Стандарты
Технология Vagrant
Тестирование
Непрерывная интеграция
Резюме
Глава 15. Стандарты РНР

Зачем нужны стандарты
Рекомендованные стандарты РНР
Особенности рекомендованных стандартов PSR
На кого рассчитаны рекомендации стандартов PSR
Программирование в избранном стиле
Основные рекомендации стандарта PSR-1
по стилю программирования
Рекомендации стандарта PSR-2 по стилю программирования
Проверка и исправление исходного кода
Рекомендации стандарта PSR-4 по автозагрузке
Самые важные правила
Резюме
Глава 16. Создание и использование компонентов РНР средствами Composer

Назначение Composer
Установка Composer
Установка пакетов
Установка пакетов из командной строки
Версии пакетов
Поле require-dev
Composer и автозагрузка
Создание собственного пакета
Ввод сведений о пакете
Пакеты для конкретной платформы
Распространение пакетов через сайт Packagist
Работа с закрытыми пакетами
Резюме

503
503
504
505
506
506
507
510
514
517
518
521

523
524
524
525
526
527
528
529
530
530
531
532
535
536

Глава 17. Контроль версий средствами Git

Зачем нужен контроль версий
Установка Git
Использование онлайнового хранилища Git
Конфигурирование сервера Git
Создание удаленного хранилища
Подготовка хранилища для локальных пользователей
Предоставление доступа пользователям
Закрытие доступа к системной оболочке для пользователя
Начало проекта
Клонирование хранилища
Обновление и фиксация изменений
Добавление и удаление файлов и каталогов
Добавление файла
Удаление файла
Добавление каталога
Удаление каталогов
Отметка выпуска
Разветвление проекта
Резюме

git

Глава 18. Тестирование средствами PHPUnit

Функциональные и модульные тесты
Тестирование вручную
Общее представление о PHPUnit
Создание контрольного примера
Методы с утверждениями
Тестирование исключений
Выполнение наборов тестов
Ограничения
Имитации и заглушки
Тесты достигают своей цели, когда завершаются неудачно
Написание веб-тестов
Реорганизация кода веб-приложения для тестирования
Простые веб-тесты
Общее представление о Selenium
Предупреждения относительно тестирования
Резюме
Глава 19. Автоматическое построение средствами Phing

Назначение Phing
Получение и установка Phing
Создание документа построения
Целевые задания
Свойства
Типы
Задачи
Резюме
Глава 20. Виртуальная машина Vagrant

Задача
Простейшая установка
Выбор и установка образа операционной системы в Vagrant

537
538
539
540
542
542
543
543
544
545
550
550
555
555
556
557
558
558
559
567
569
570
571
573
574
577
578
579
580
583
587
590
591
594
596
603
606
607
608
609
610
612
615
623
629
634

635
635
637
637

Монтирование локальных каталогов на виртуальной машине Vagrant
Подготовка
Настройка веб-сервера
Настройка сервера баз данных MySQL
Определение имени хоста
Краткие итоги
Резюме

640
641
643
644
645
647
648

Глава 21. Непрерывная интеграция

Что такое непрерывная интеграция
Подготовка проекта к непрерывной интеграции
Установка сервера Jenkins
Установка модулей, подключаемых к серверу Jenkins
Установка открытого ключа доступа к системе Git
Установка проекта
Первое построение проекта
Настройка отчетов
Автоматический запуск процессов построения проектов
Резюме

649
649
652
664
666
666
668
672
672
674
678

Часть V. Заключение

679

Глава 22. Объекты, шаблоны и практика

Объекты
Выбор
Инкапсуляция и делегирование
Развязка
Повторное использование кода
Эстетика
Проектные шаблоны
Преимущества шаблонов
Шаблоны и принципы проектирования
Практика
Тестирование
Стандарты
Контроль версий
Автоматическое построение
Непрерывная интеграция
Что упущено из виду
Резюме

681
681
682
682
683
684
684
685
686
687
689
689
690
690
691
691
692
694

Часть VI. Приложения

695

Приложение А. Дополнительные источники информации

697
697
699
699

Литература
Статьи в Интернете
Сайты

Сканер
Синтаксический анализатор

703
703
712

Предметный указатель

729

Приложение Б. Простой синтаксический анализатор

Луизе, которая для меня важнее всего.

Об авторе
Мэтт Зандстра почти двадцать лет проработал веб-программистом, кон
сультантом по РНР и составителем технической документации. Он был стар
шим разработчиком в компании Yahoo! и работал в подразделениях компании в
Лондоне и в Силиконовой долине. В настоящее время он зарабатывает себе на
жизнь в качестве свободного консультанта и писателя.
До этой книги Мэтт написал книгу SAMS Teach Yourself РНР in 24 Hours,
3-е издание которой вышло под названием Освой самостоятельно РНР за
24 часа в русском переводе в ИД “Вильямс” в 2007 году, а также был одним
из авторов книги DHTML Unleashed (издательство SAMS Publishing, 1997 г.).
Он писал также статьи для Linux Magazine, Zend.com, IBM DeveloperWorks и
php\architect Magazine.
Мэтт изучает также литературу и пишет фантастические рассказы. Он по
лучил степень магистра в области писательского мастерства в Университетах
Манчестера и Восточной Англии. Мэтт постоянно проживает в Ливерпуле (Ве
ликобритания) с женой Луизой и двумя детьми, Холли и Джейком и часто разъ
езжает по разным уголкам Великобритании, изучая литературу и ведя самосто
ятельную трудовую деятельность.

О техническом рецензенте
Пол Трегоинг (Paul Tregoing) имеет почти двадцатилет
ний опыт разработки и сопровождения программного обе
спечения в самых разных условиях эксплуатации. В течение
пяти лет он работал старшим разработчиком в команде, от
вечавшей за главную страницу веб-сайта компании Yahoo!,
где и сформировал свой первый сценарий на РНР с помо
щью языка Perl. Ему довелось также работать в компаниях
Bloomberg, Schlumberger и даже в Британском управлении
по антарктическим исследованиям (British Antarctic Survey), где он имел удо
вольствие непосредственно общаться с тысячами пингвинов.
В настоящее время он работает внештатным инженером, выполняя мелкие и
крупные проекты по созданию многоуровневых веб-приложений для различных
клиентов на основе РНР, JavaScript и многих других технологий. Пол — нена
сытный читатель научно-фантастической и фэнтезийной литературы и не скры
вает своих честолюбивых намерений написать в этих жанрах что-нибудь свое
в ближайшем будущем. Он проживает в Кембридже (Великобритания) с женой
и детьми.

Благодарности
Как всегда, хочу выразить признательность всем, кто работал над этим изда
нием книги. Но я должен упомянуть и всех тех, кто работал над всеми преды
дущими изданиями.
Некоторые из основополагающих концепций этой книги были опробованы
мною на конференции в Брайтоне, где мы все собрались, чтобы познакомиться
с замечательными возможностями версии РНР 5. Выражаю благодарность орга
низатору конференции Энди Бадду (Andy Budd) и всему активному сообществу
разработчиков Брайтона. Благодарю также Джесси Вайт-Синис (Jessey WhiteCinis), которая познакомила меня на конференции с Мартином Штрайхером
(Martin Streicher) из издательства Apress.
Как и прежде, сотрудники издательства Apress оказывали мне неоценимую
поддержку, высказывали ценные замечания и обеспечивали всяческое содей
ствие. Мне очень повезло работать с ними, выгодно пользуясь их профессио
нальным опытом и знаниями.
Когда я предложил настоящее издание книги, то клятвенно обещал обновить
весь исходный код примеров в соответствии с последними нормами практики
программирования на РНР. И мне очень повезло, что у меня есть такой товарищ
и коллега, как Пол Трегоинг, который взялся рецензировать настоящее издание.
Он не только помог мне сдержать свое обещание, но и внес немало существен
ных корректив в исходный код примеров, чтобы устранить многочисленные на
рушения принятых норм практики, проявив, прежде всего, благородное чувство

18

ОБ АВТОРЕ

долга! Более того, настоящее издание выгодно отличается в лучшую сторону
благодаря знаниям, опыту, проницательности и вниманию Пола к деталям, за
что я искренне ему признателен!
Выражаю благодарность и безграничную любовь своей жене Луизе и детям
Холли и Джейку за то, что они периодически отвлекали меня от сложной рабо
ты, внося необходимую разрядку.
Благодарю Стивена Мецкера (Steven Metsker) за любезное разрешение реали
зовать на РНР упрощенную версию API синтаксического анализатора, который
он представил в своей книге Building Parsers in Java (издательство AddisonWesley Professional, 2001 г.).
Я обычно работаю под музыку и в предыдущих изданиях этой книги упомя
нул о великом диджее Джоне Пиле (John Peel), поборнике всего подпольного и
эклектичного в авангардной музыке. А в работе над этим изданием я пользо
вался фонограммой из программы современной музыки Late Junction (Поздний
переход), которую постоянно крутили на радиостанции ВВС Radio 3. Благодарю
их за нестандартный подход к подбору музыки.

20

й БЛАГОДАРНОСТИ

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

Наши электронные адреса:
E-mail: info@dialektika.com
WWW: http://www.dialektika.com

ЧАСТЬ I

Введение

ГЛАВА 1

Проектирование
и сопровождение
приложений на РНР
Версия РНР 5.0 была выпущена в июле 2004 года. В ней был внедрен целый
ряд радикальных усовершенствований, и самым главным среди них, вероятно,
стала коренным образом улучшенная поддержка объектно-ориентированного
программирования (ООП). Именно это обстоятельство и вызвало повышенный
интерес к объектам и методике ООП в среде разработчиков приложений на РНР.
На самом деле это был новый этап развития процесса, начавшегося благодаря
выпуску версии 4 языка РНР, в которой ООП впервые стало реальностью.
В этой главе будет рассмотрен ряд задач, для решения которых требуется
методика ООП. В ней вкратце изложена эволюция проектных шаблонов и свя
занных с ними норм практики программирования1. Кроме того, здесь будут обо
значены в общих чертах следующие темы, освещаемые в данной книге.
® Эволюция катастрофы. Проект не удался.
Проектирование и РНР. Каким образом методика ООП укоренилась в со
обществе разработчиков приложений на РНР.

» Эта книга. Объекты, шаблоны, практика программирования.

Проблема
Проблема в том, что РНР — очень простой язык. Он искушает вас по
пробовать реализовать свои идеи и радует хорошими результатами. Большую
часть написанного кода на РНР можно встроить непосредственно в разметку
1 Дополнительный материал к этой книге с исходным кодом примеров можно загрузить
по адресу https://link.springer.com/chapter/10. 1007%2F978-l-4842-1996-6_l.

24

ЧАСТЬ I

ВВЕДЕНИЕ

веб-страниц, потому что для этого в РНР предусмотрена соответствующая под
держка. Введя дополнительные функции (например, код доступа к базе данных)
в файлы, которые можно перенести с одной страницы на другую, вы не успеете
оглянуться, как получите рабочее веб-приложение.
И, тем не менее, вы уже стоите на пути к краху. Конечно, вы этого не осоз
наете, потому что ваш сайт выглядит потрясающе. Он прекрасно работает, за
казчики довольны, а пользователи тратят деньги.
Трудности возникают, когда вы возвращаетесь к исходному коду, чтобы на
чать новый этап разработки. Теперь ваша команда увеличилась, пользователей
стало больше, бюджет также вырос. Но, если не принять меры, все пойдет пра
хом. Образно говоря, все выглядит так, как будто ваш проект был отравлен.
Ваш новый программист изо всех сил старается понять код, который вам
кажется простым и естественным, хотя, возможно, местами слегка запутанным.
И этому новому программисту требуется больше времени, чем вы рассчитыва
ли, чтобы войти в курс дела и стать полноправным членом команды. На про
стое изменение, которое вы рассчитывали сделать за один день, уходит три
дня, потому что вы обнаруживаете, что в результате нужно обновить порядка
20 веб-страниц.
Один из программистов сохраняет свою версию файла поверх тех серьезных
изменений, которые вы внесли в тот же код немного раньше. Потеря обнару
живается только через три дня, к тому времени как вы изменили собственную
локальную копию файла. Еще один день уходит на то, чтобы разобраться в этом
беспорядке, а между тем, без дела сидит третий программист, который также
работал с этим файлом.
Ваше веб-приложение пользуется популярностью, и поэтому вам нужно пе
ренести его исходный код на новый сервер. Устанавливать на нем свой проект
приходится вручную, и в этот момент вы обнаруживаете, что пути к файлам,
имена баз данных и пароли жестко закодированы во многих исходных файлах.
Следовательно, вы останавливаете работу своего веб-сайта на время перено
са исходного кода, потому что не хотите затереть изменения в конфигурации,
которых требует такой перенос. Работа, которую планировалось выполнить за
два часа, в итоге растягивается на восемь часов, поскольку обнаружилось, что
кто-то умный задействовал модуль ModRewrite веб-сервера Apache, и теперь
для нормальной работы веб-приложения требуется, чтобы этот модуль функци
онировал на сервере и был правильно настроен.
В конечном счете вы успешно преодолеваете второй этап разработки. И пол
тора дня все идет хорошо. Первое сообщение об ошибке приходит в тот мо
мент, когда вы собираетесь уходить с работы домой. Еще через минуту звонит
заказчик с жалобой. Его сообщение об ошибке напоминает предыдущее, но в
результате более тщательного анализа обнаруживается, что это другая ошибка,
которая вызывает похожее поведение. Вы вспоминаете о простом изменении в
начале данного этапа, которое потребовало серьезно модифицировать осталь
ную часть проекта.

ГЛАВА 1 « ПРОЕКТИРОВАНИЕ И СОПРОВОЖДЕНИЕ ПРИЛОЖЕНИЙ НА РНР

25

И тогда вы понимаете, что модифицировано было не все. Это произошло
либо потому, что некоторые моменты были упущены в самом начале, либо по
тому, что изменения в проблемных файлах были затерты в процессе объедине
ния. В страшной спешке вы вносите изменения, необходимые для исправления
ошибок. Вы слишком спешите и не тестируете внесенные изменения. Ведь это
же простые операции копирования и вставки, что тут может случиться?
Придя на работу на следующее утро, вы выясняете, что модуль корзины для
покупок не работал всю ночь. Оказалось, что, внося вчера изменения в послед
нюю минуту, вы пропустили открывающие кавычки, в результате чего код стал
неработоспособным. И пока вы спали, потенциальные клиенты из других часо
вых поясов бодрствовали и были готовы потратить деньги в вашем интернет-ма
газине. Вы исправляете ошибку, успокаиваете заказчика и мобилизуете команду
на “пожарные” работы в течение еще одного дня.
Подобная история о ежедневных буднях программистов может показаться пре
увеличением, но все это мне случалось наблюдать неоднократно. Многие проек
ты на РНР начинались с малого, а затем превращались в настоящих монстров!
В данном проекте логика приложения содержится также на уровне представ
ления данных, и поэтому дублирование происходит уже в коде запросов к базе
данных, проверке аутентификации, обработке форм, причем этот код копируется
с одной страницы на другую. Всякий раз, когда требуется внести коррективы в
один из таких блоков кода, это приходится делать везде, где присутствует такой
код, иначе неминуемо возникнет ошибка.
Отсутствие документации затрудняет понимание исходного кода, а недоста
точность тестирования оставляет скрытые дефекты необнаруженными вплоть
до момента развертывания приложения. Изменение основного направления дея
тельности заказчика часто означает, что в результате модификации прикладной
код меняет свое первоначальное назначение и в конце концов начинает выпол
нять задачи, для которых он изначально вообще не был предназначен. А по
скольку такой код, как правило, разрабатывался и развивался в качестве единой
гремучей смеси, в которой было много чего намешано, то очень трудно, или
даже невозможно, перестроиться и переписать отдельные его фрагменты, чтобы
он соответствовал новой цели.
Но все это не так уж и плохо, если вы — независимый консультант по РНР.
Анализ и исправление подобных систем позволят вам покупать дорогие напитки
и наборы DVD в течение полугода или даже дольше. А если серьезно, то про
блемы подобного рода как раз и отличают удачную коммерческую деятельность
от неудачной.

РНР и другие языки
Феноменальная популярность языка РНР означает, что он был основательно
протестирован во всех сферах своего применения еще на начальном этапе свое
го развития. Как поясняется в следующей главе, язык РНР начинался как набор

26

ЧАСТЬ I

ВВЕДЕНИЕ

макрокоманд для управления персональными веб-страницами. С появлением
версии РНР 3, а в значительной степени — РНР 4, этот язык быстро стал попу
лярным и мощным инструментом для создания веб-сайтов крупных коммерче
ских компаний. Но во многих случаях область его применения ограничивалась
разработкой сценариев и средств управления проектами. В некоторых кругах
специалистов РНР заслужил несправедливую репутацию языка для любителей,
который больше приспособлен для задач представления данных.
Примерно в то же время, когда наступило новое тысячелетие, в других сооб
ществах программистов стали распространяться новые идеи. Интерес к объек
тно-ориентированному проектированию всколыхнул сообщество программиру
ющих на Java. Вам такой интерес может показаться излишним, поскольку Java
и так является объектно-ориентированным языком. Но ведь Java задает лишь
рациональное зерно, которым нужно еще научиться правильно пользоваться,
поскольку применение в программах классов и объектов само по себе не опре
деляет конкретный подход к проектированию.
Понятие проектного шаблона как способа описания задачи вместе с сутью ее
решения впервые обсуждалось еще в 1970-х годах. Первоначально эта идея воз
никла в области строительства и архитектуры, а не в вычислительной технике.
В начале 1990-х годов приверженцы ООП стали применять аналогичные мето
дики для определения и описания задач разработки программного обеспечения.
Основополагающая книга по проектным шаблонам, Design Patterns: Elements of
Reusable Object-Oriented Software1, опубликованная в 1995 году под авторством
“Банды четырех”, незаменима и по сей день. Шаблоны, которые в ней описаны,
обязательны для каждого, кто делает первые шаги в данной области. Именно
поэтому большинство шаблонов, описываемых в данной книге, взято из этого
фундаментального труда.
В интерфейсах API языка Java изначально применяются многие основные
шаблоны, но до конца 1990-х годов проектные шаблоны так и не были полно
стью осмыслены сообществом программистов. Книги по проектным шаблонам
быстро заполонили отделы компьютерной литературы в книжных магазинах, и
на форумах программистов появились первые признаки горячей полемики со
словами похвалы или неодобрения.
Возможно, вы думаете, что шаблоны — это эффективный способ передачи
специальных знаний ремесла или, наоборот, “мыльный пузырь” (какой точки
зрения придерживаюсь лично я, видно из названия данной книги). Каким бы
ни было ваше мнение, трудно отрицать, что подход к разработке программного
обеспечения, который поощряется в шаблонах, полезен сам по себе.
Не менее популярными для обсуждения стали и родственные темы. К их
числу относится методика экстремального программирования (extreme
Programming — ХР), одним из авторов которой является Кент Бек (Kent Beck)3.
2 Эрих Гамма, Ричард Хелм, Ральф Джонсон, Джон Влиссидес. Приемы объектно-ориен
тированного проектирования. Паттерны проектирования (пер. с англ., изд. “Питер”, 2007 г.).
3 Кент Бек. Экстремальное программирование (пер. с англ., изд. “Питер”, 2002 г.).

ГЛАВА 1 ® ПРОЕКТИРОВАНИЕ И СОПРОВОЖДЕНИЕ ПРИЛОЖЕНИЙ НА РНР

27

Экстремальное программирование — это подход к проектированию, который
направлен на гибкое, проектно-ориентированное, очень тщательное планирова
ние и выполнение. Один из главных его принципов настаивает на том, что те
стирование является ключевым фактором для успешного выполнения проекта.
Тесты должны быть автоматическими, выполняться часто, и желательно, чтобы
они были разработаны до написания самого кода.
Еще одно требование методики экстремального программирования состоит в
том, что проекты должны быть разбиты на небольшие (и даже мелкие) повторя
ющиеся стадии. А код и требования к нему должны постоянно анализироваться.
Архитектура и проект должны быть предметом постоянного совместного обсуж
дения, что ведет к частому пересмотру разрабатываемого кода.
Если методика экстремального программирования стала воинствующим
крылом в движении сторонников проектирования программного обеспечения,
то умеренная тенденция превосходно представлена в одной из лучших книг по
программированию, которую я когда-либо читал: The Pragmatic Programmer
(Andrew Hunt, David Thomas, издательство Addison-Wesley Professional, 1999 r.)4.
Некоторые считают, что методика экстремального программирования была
в какой-то степени культовым явлением, но за два десятилетия практики ООП
она достигла высочайшего уровня, а ее принципы широко использовались и
заимствовались. В особенности процесс реорганизации кода, называемый ре
факторингом. был использован в качестве мощного дополнения к шаблонам.
Рефакторинг развивался с 1980-х годов, но только в 1999 году он был включен
в каталог образцов рефакторинга, опубликованный Мартином Фаулером (Martin
Fowler) в книге Refactoring: Improving the Design of Existing Code5, и тем самым
определил данную область проектирования программного обеспечения.
С развитием и ростом популярности методики экстремального программи
рования и проектных шаблонов тестирование также стало злободневным во
просом. Особое значение автоматических тестов еще более усилилось с появле
нием мощной тестовой платформы JUnit, которая стала главным инструментом
в арсенале средств программирующих на Java. Основополагающая статья Test
Infected: Programmers Love Writing Tests (Kent Beck, Erich Gamma; http://
junit. source forge. ne t/doc/test inf ect ed/1 es t ing .htm) стала превос
ходным введением в этот предмет и до сих пор не потеряла своей актуальности.
Примерно в то же время вышла более эффективная версия РНР 4 с уси
ленной поддержкой объектов. Благодаря этим усовершенствованиям появилась
возможность создавать полностью объектно-ориентированные приложения.
Программисты воспользовались этой возможностью к некоторому удивлению
создателей ядра Zend Зеэва Сураски (Zeev Suraski) и Энди Гутманса (Andi
4 Эндрю Хант, Дэвид Томас. Программист-прагматик. Путь от подмастерья к мастеру
(пер. с англ., изд. “Лори”, 2012 г.).
5 Мартин Фаулер, Кент Бек, Джон Брант, Уильям Опдайк, Дон Робертс. Рефакторинг:
улучшение проекта существующего кода (пер. с англ., изд. “Диалектика”, 2017 г., ISBN 978-59909445-1-0).

28

ЧАСТЬ I

ВВЕДЕНИЕ

Gutmans), которые присоединились к Расмусу Лердорфу (Rasmus Lerdorf) для
разработки РНР. Как поясняется в следующей главе, поддержка объектов в РНР
оказалась далеко не идеальной, но при строгой дисциплине и аккуратном при
менении синтаксиса на РНР можно было все же писать объектно-ориентирован
ные программы.
Тем не менее неприятности, подобные описанной в начале этой главы, слу
чались часто. Культура проектирования была еще недостаточно развита, и в
книгах по РНР о ней едва ли упоминалось. Но в Интернете интерес к этому
предмету был очевиден. Леон Аткинсон (Leon Atkinson) написал статью о РНР и
проектных шаблонах для Zend в 2001 году, а Гарри Фойкс (Harry Fuecks) завел
в 2002 году журнал по адресу www.phppatterns. com (он уже давно прекратил
свое существование, хотя сайт по указанному адресу по-прежнему действует).
В конечном итоге стали появляться проекты на основе шаблонов (например,
BinaryCloud), а также инструментальные средства для автоматического тестиро
вания и документирования разрабатываемых приложений.
Выход первой бета-версии РНР 5 в 2003 году обеспечил будущее РНР в каче
стве языка для ООП. Процессор Zend 2 Engine обеспечил существенно улучшен
ную поддержку объектов. И, что не менее важно, его появление стало сигналом,
что объекты в частности и методика ООП вообще могут служить основанием
для любого проекта на РНР.
С годами версия РНР 5 продолжала развиваться и совершенствоваться. В ней
появились такие важные средства, как поддержка пространств имен и механиз
ма замыканий. За это время версия РНР 5 завоевала репутацию надежного и
самого лучшего средства для разработки серверных веб-приложений.
Эта тенденция была продолжена в версии РНР 7, выпущенной в декабре
2015 года. В частности, в этой версии поддерживаются объявления скалярных
и возвращаемых типов данных, внедрения которых многие годы настоятельно
требовали многие разработчики, о чем упоминалось в том числе и на страницах
предыдущих изданий данной книги. И если вы не знаете, что эти типы данных
означают и в чем их назначение, то у вас есть отличная возможность воспол
нить пробел в своих знаниях РНР, читая данную книгу дальше!

Об этой книге
Эта книга не является попыткой открыть что-то новое в области ООП, и
в этом отношении она просто “стоит на плечах гигантов”. Цель книги — ис
следовать в контексте РНР некоторые устоявшиеся принципы проектирова
ния и основные шаблоны (особенно те, которые упоминаются в книге Design
Patterns — классическом труде “Банды четырех”). В конце книги будет пред
принята попытка выйти за пределы строгих ограничений прикладного кода, что
бы рассмотреть инструментальные средства и методики, которые могут помочь
в работе над проектом. За исключением этого введения и краткого заключения,
данная книга разделена на три основные части: объекты (часть II), шаблоны
(часть 111) и практика (часть IV).

ГЛАВА 1 W ПРОЕКТИРОВАНИЕ И СОПРОВОЖДЕНИЕ ПРИЛОЖЕНИЙ НА РНР

29

Объекты
Эта часть начинается с краткого рассмотрения истории развития РНР и объ
ектов, где описывается их превращение из дополнительной возможности в вер
сии РНР 3 в основную, начиная с версии РНР 5. Вы можете быть опытным
программистом и свободно писать программы на РНР, но при этом очень мало
знать или почти ничего не знать об объектах. Именно по этой причине данная
книга начинается с самых основных принципов, чтобы объяснить, что такое
объекты, классы и наследование. Даже на этой начальной стадии в данной части
книги рассматриваются некоторые усовершенствования объектов, появившиеся
в версиях РНР 5 и РНР 7.
После изложения основ тема объектов будет рассмотрена более углубленно
в ходе исследования более развитых объектно-ориентированных возможностей
РНР. Отдельная глава в этой части книги посвящена инструментальным сред
ствам, которые предусмотрены в РНР для работы с объектами и классами.
Но знать, как объявить класс и как использовать его для создания экземпляра
объекта, еще недостаточно. Сначала необходимо выбрать правильно участни
ков для разрабатываемой системы и определить оптимальные способы их вза
имодействия. Описать и усвоить эти варианты выбора намного труднее, чем
простые факты об инструментальные средствах и синтаксисе объектов. Часть II
завершается введением в объектно-ориентированное проектирование на РНР.

Шаблоны
Шаблон описывает задачу, поставленную в проекте программного обеспе
чения, предоставляя саму суть решения. “Решение” здесь не является частью
кода, которую можно найти в справочнике, вырезать и вставить (хотя на самом
деле справочники — превосходные ресурсы для программистов). В проектном
шаблоне описывается подход, который можно использовать для решения по
ставленной задачи. К этому может прилагаться пример реализации, но он менее
важен, чем концепция, которую он призван иллюстрировать.
Часть III начинается с определения проектных шаблонов и описания их
структуры. В ней рассматриваются также некоторые причины их широкой рас
пространенности .
При создании шаблонов обычно выдвигаются некоторые основополагающие
принципы проектирования, которых стараются придерживаться в процессе раз
работки всего приложения. Уяснение этого факта поможет лучше понять при
чины создания шаблона, который затем можно применять при создании любой
программы. Некоторые из этих принципов обсуждаются в данной части книги,
где представлен также унифицированный язык моделирования (Unified Modeling
Language — UML) — платформенно-независимый способ описания классов и
их взаимодействия.
Несмотря на то что данная книга не является справочником по проектным ша
блонам, в ней все же рассматриваются некоторые из самых известных и полезных

30

ЧАСТЬ I Й ВВЕДЕНИЕ

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

Практика
Даже самое гармоничное архитектурное сооружение разрушится, если не об
ращаться с ним должным образом. В части IV представлены инструментальные
средства, с помощью которых можно создать структуру, способную обеспечить
удачное завершение проекта. Если в остальных частях этой книги речь идет о
практике проектирования и программирования, то в части IV — о практике со
провождения прикладного кода. Инструментальные средства, рассматриваемые в
этой части, позволяют создавать поддерживающую инфраструктуру проекта, по
могая обнаруживать ошибки по мере их проявления, способствуя сотрудничеству
программистов и обеспечивая простоту установки и ясность прикладного кода.
Ранее вкратце упоминалось об эффективности автоматических тестов.
А часть IV начинается со вступительной главы, где дается краткий обзор насущ
ных задач и решений в данной области разработки программного обеспечения.
Многие программисты поддаются искушению делать все самостоятельно.
А диспетчер зависимостей Composer совместно с главным хранилищем пакетов
Packagist обеспечивает доступ к тысячам пакетов с управляемыми зависимостя
ми, из которых легко составляются целые проекты. В этойчасти обсуждаются
достоинства и недостатки самостоятельной реализации в сравнении с разверты
ванием пакетов средствами Composer. Здесь, в частности, описывается приме
няемый в Composer механизм установки, упрощающий процесс развертывания
пакетов вплоть до выполнения единственной команды.
Код — продукт коллективного труда. С одной стороны, этот факт приносит
внутреннее удовлетворение, а с другой — может превратить все в сущий кош
мар. Система контроля версий Git дает группе программистов возможность рабо
тать совместно над одним и тем же кодом, не рискуя затереть результаты работы
друг друга. Она позволяет получать моментальные снимки проекта на любой
стадии его разработки, видеть, кто и какие изменения вносил, а также разбивать
проект на независимые ветки, которые затем можно объединить. В системе Git
сохраняется ежедневное состояние проекта.
Когда разработчики совместно работают над приложениями или библиоте
ками, они нередко вносят разные условные обозначения и стили оформления
кода в общий проект. И хотя в таком явлении нет ничего дурного, оно подры
вает основы организации взаимодействия. От понятий совместимости и соот
ветствия нередко бросает в дрожь, но непреложным является тот факт, что
творческая инициатива в Интернете опирается все же на стандарты. Соблюдая
определенные соглашения, можно свободно экспериментировать в невообрази
мо обширной “песочнице”. Поэтому в новой главе из этой части исследуются
стандарты РНР, польза от них для разработчиков и причины, по которым они
должны строго соблюдать соответствие стандартам.

32

ЧАСТЬ I ® ВВЕДЕНИЕ

которые совместно называются непрерывной интеграцией и призваны помочь
справиться с подобной задачей.

Что нового в пятом издании книги
РНР — это живой язык, и все его средства постоянно обновляются, изменя
ются и дополняются. Поэтому новое издание книги было тщательно пересмо
трено и основательно обновлено, чтобы описать все новые изменения и возмож
ности РНР.
В настоящем издании описываются новые языковые средства РНР, в том
числе анонимные классы и долгожданные уточнения скалярных аргументов, а
также возвращаемые типы данных. В соответствующих примерах используются
средства РНР 7 там, где это уместно, поэтому имейте в виду, что вам придется
выполнять исходный код в интерпретаторе РНР 7. В противном случае будьте
готовы к тому, чтобы изменить код и сделать его совместимым с предыдущей
версией РНР.
В предыдущие издания входила глава, посвященная хранилищу пакетов
PEAR. Но использование диспетчера Composer и хранилища пакетов Packagist
теперь стало нормой для разработки приложений на РНР, и поэтому упоми
наемую здесь главу пришлось полностью переписать. По сложившейся уже
традиции в каждом новом издании книги мне приходилось описывать новую
версию системы контроля версий. И мне приятно сообщить, что теперь (как
и в предыдущем издании) я остановился на системе контроля версий Git, хотя
мне пришлось проанализировать возможности других хранилищ типа GitHub,
поскольку разработчики все чаще пользуются ими. А упоминавшееся ранее ин
струментальное средство Vagrant представлено отдельно в новой главе.
В еще одной новой главе рассматриваются стандарты оформления кода на
РНР. Разделяя ценность соблюдения руководства по стилю, я переработал все
примеры исходного кода из данной книги в соответствии с рекомендациями
стандартов PSR-1 и PSR-2. Но выполнить это обязательство оказалось намного
труднее, чем мне казалось поначалу. И здесь на помощь мне пришел Пол Тре
гоинг, технический рецензент данной книги.

Резюме
Эта книга посвящена объектно-ориентированному проектированию и про
граммированию. В ней описываются средства для работы с кодом РНР, начиная
с приложений для совместной работы программистов и кончая утилитами для
развертывания кода.
Эти две темы раскрывают одну и ту же проблему под различными, но до
полняющими друг друга углами зрения. Основная цель состоит в том, чтобы
создавать системы, отвечающие заданным требованиям и обеспечивающие воз
можности совместной работы над проектами.

ГЛАВА 1 » ПРОЕКТИРОВАНИЕ И СОПРОВОЖДЕНИЕ ПРИЛОЖЕНИЙ НА РНР

33

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

ЧАСТЬ II

Объекты

ГЛАВА 2

РНР и объекты
Объекты не всегда были основной частью PHP-проекта. Более того, идея
реализовать объекты пришла в голову разработчикам РНР в виде запоздалой
мысли.
Но впоследствии эта идея доказала свою жизнеспособность. В этой главе
дается общее представление об объектах и описывается процесс разработки и
внедрения объектно-ориентированных средств в РНР. В частности, здесь рас
сматривается следующие вопросы.
PHP/FI 2.0. Это язык РНР, но не такой, каким мы его знаем.

РНР 3. Первое появление объектов.
РНР 4. Развитие объектно-ориентированных средств.
® РНР 5. Объекты в основе языка.
РНР 7. Восполнение пробела.

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

Вначале был PHP/FI
Своим происхождением язык РНР, каким мы его знаем сегодня, обязан двум
инструментальным средствам, которые разработал Расмус Лердорф на языке
Perl. Сокращение РНР обозначало Personal Homepage Tools (Средства для пер
сональной начальной страницы), a F1 — Form Interpreter (Интерпретатор форм).
Вместе они составляли набор макрокоманд для отправки SQL-запросов в базу
данных, обработки форм и управления процессом обмена данными.

ГЛАВА 2

РНР И ОБЪЕКТЫ

39

С точки зрения рассматриваемых нами объектов большим преимуществом
версии РНР 4 стала возможность переопределять родительские методы и полу
чать доступ к ним из дочерних классов. Но оставался и крупный недостаток.
Присвоение объекта переменной, передача его функции или возвращение его
из метода приводило к появлению копий этого объекта. Поэтому присвоение,
подобное следующему:
$my_obj = new User(’bob’);
$other = $my_obj;

приводило к появлению двух копий объекта типа User, а не двух ссылок на
один и тот же объект данного типа. В большинстве объектно-ориентированных
языков программирования используется более естественное присваивание по
ссылке, а не по значению, как здесь. Это означает передачу и присваивание
указателей на объекты, а не копирование самих объектов. Устанавливаемый по
умолчанию режим передачи по значению приводил к появлению в сценариях
множества скрытых ошибок, когда программисты модифицировали объект в од
ной части сценария и ожидали, что эти изменения отразятся на всех его копиях.
В данной книге представлено немало примеров, где сохраняется несколько ссы
лок на один и тот же объект.
К счастью, в программе на РНР можно было принудительно осуществить
передачу объекта по ссылке, но для этого нужно было использовать довольно
неуклюжую конструкцию. Ниже показано, каким образом осуществляется при
сваивание по ссылке.
$other =& $my_obj;
// переменные $other и $my_obj указывают
//на один и тот же объект

Передача объекта по ссылке происходит следующим образом:
function setSchool ( & $school ) {
// параметр $school теперь ссылается на сам объект,
// а не на его копию
}

А возвращается объект по ссылке таким образом:
function & getSchool ( ) {
// Возврат ссылки на объект, а не его копии
return $this->school;
}

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

40

ЧАСТЬ II

ОБЪЕКТЫ

Описание синтаксиса в целом и объектов в частности было расширено в ру
ководстве по РНР, и ООП стало превращаться в основную методику. Объекты
в РНР были приняты сообществом программистов небесспорно, и сообщения
типа “Зачем мне нужны эти объекты?” часто вызывали горячую полемику на
форумах и в списках рассылки. На сайте Zend размещались статьи, которые по
ощряли ООП на РНР, наряду со статьями, в которых звучали предостережения.
Но, несмотря на недостатки механизма передачи объектов по ссылке и горячую
полемику, многие программировавшие на РНР просто приняли новые возмож
ности, приправив свой код символами амперсандов в соответствующих местах.
Популярность объектно-ориентированной версии языка РНР стала расти. Вот
что Зеэв Сураски написал по этому поводу в своей статье на сайте DevX.com
(http://www.devx.com/webdev/Article/10007/0/page/l ).

Одним из крутых и неожиданных поворотов в истории развития
РНР стало зарождение и постепенное превращение ООП в самую
популярную парадигму для растущего числа стандартных прило
жений на РНР, несмотря на очень ограниченные функциональные
возможности, многие недостатки и ограничения. Эта, в общем,
неожиданная тенденция застала РНР в неблагоприятной ситуа
ции. Стало очевидным, что объекты ведут себя как [ассоциатив
ные] массивы, а не так, как объекты в других объектно-ориенти
рованных языках.
Как отмечалось в предыдущей главе, интерес к объектно-ориентированному
проектированию стал очевиден из растущего числа публикаций статей на сай
тах и в форумах в Интернете. В официальном хранилище PEAR программного
обеспечения РНР также была принята методика ООП.
Оглядываясь в прошлое, можно подумать, что введение в РНР поддержки
средств ООП стало результатом вынужденной капитуляции перед лицом неиз
бежности. Но не следует забывать, что методика ООП получила широкое рас
пространение только в середине 1990-х годов, хотя она существует с 1960-х.
Язык Java, весьма способствовавший популяризации методики ООП, был вы
пущен только в 1995 году, а язык С+ появился как расширение процедурного
языка С в 1979 году. И лишь после длительного периода эволюции он совер
шил большой скачок только в 1990-х годах. В 1994 году вышла версия 5 языка
Perl. Это была еще одна революция для бывшего процедурного языка, что дало
возможность пользователям перейти к понятию объектов (хотя некоторые утвер
ждают, что поддержка объектно-ориентированных возможностей в Perl напо
минает дополнения, сделанные задним числом). Для небольшого процедурного
языка поддержка объектов в РНР была разработана на удивление быстро, что
продемонстрировало оперативный отклик на требования пользователей.

ГЛАВА 2

РНР И ОБЪЕКТЫ

41

Изменения приняты: РНР 5
В версии РНР 5 уже была явно выражена поддержка объектов и ООП. Но это
еще не означало, что объекты стали единственным средством для программиро
вания на РНР (кстати, и в данной книге это совсем не утверждается). Тем не ме
нее объекты были признаны эффективными и важными средствами разработки
корпоративных приложений, а в РНР предусмотрена их полная и всесторонняя
поддержка.
Безусловно, одним из самых важных следствий усовершенствований в вер
сии РНР 5 явилось принятие этого языка в качестве основного в крупных
интернет-компаниях. Например, такие компании, как Yahoo! и Facebook, ста
ли интенсивно пользоваться РНР для создания своих программных платформ.
С появлением версии 5 РНР стал одним из стандартных языков для разработки
корпоративных веб-приложений в Интернете.
Объекты из дополнительной возможности превратились в основу языка. И ве
роятно, самым важным изменением стал принятый по умолчанию механизм пере
дачи объектов по ссылке, а не по значению. Но это было только начало. На про
тяжении всей данной книги, и особенно в этой ее части, описывается немало
других изменений, расширяющих и усиливающих поддержку объектов в РНР,
включая закрытые и защищенные методы и свойства, ключевое слово static,
пространства имен, уточнения типов, называемые теперь объявлениями типов, а
также исключения. Версия РНР 5 существует около 12 лет, и новые важные сред
ства внедрялись в ней постепенно.
Например, в версии РНР 5.3 были введены пространства имен. Это позволило
создавать именованные области видимости для классов и функций, в результате
чего снизилась вероятность дублирования имен при включении компонентов в
библиотеки и расширении системы. Кроме того, пространства имен избавляют
от неприятной необходимости соблюдать неудобные соглашения об именах, как
в приведенном ниже примере.
class megaquiz_util_Conf
{
}

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

Восполнение пробела: РНР 7
Программисты всегда требуют большего. И многим поклонникам проект
ных шаблонов по-прежнему не хватало в РНР двух основных средств: объявле
ний скалярных типов аргументов и уточнений типов возвращаемых значений.

42

ЧАСТЬ II

ОБЪЕКТЫ

В версии РНР 5 можно было строго ограничить тип аргумента, передаваемого
функции или методу, при условии, что это был объект, массив, а в дальнейшем
и вызываемый код. Но ограничить тип скалярных величин, таких как целые
числа, символьные строки и числа с плавающей точкой, было нельзя. Более
того, если требовалось объявить тип, возвращаемый методом или функцией,
сделать это вообще никак не удавалось.
Как поясняется далее в книге, объявление метода применяется в объек
тно-ориентированном проектировании в качестве своего рода контракта. Мето
ду требуются определенные входные данные, а он, в свою очередь, обязуется
возвратить данные определенного типа. В версии 5 программирующим на РНР
приходилось задействовать комментарии, условные обозначения и ручной кон
троль типов, чтобы обеспечить во многих случаях контракты подобного рода.
Ниже приведена выдержка из предыдущего издания данной книги.
...среди разработчиков новой версии РНР так и не было достиг
нуто соглашения по поводу поддержки уточнений для возвраща
емых типов данных. Это позволило бы определять в методе или
объявлении функции тип возвращаемого объекта. Данное средство
должно быть со временем реализовано в движке РНР. Уточнение
типов возвращаемых объектов позволило бы еще больше усовер
шенствовать в РНР поддержку шаблонных принципов программи
рования наподобие программирования на основе интерфейса, а не
его реализации. Как только эта возможность будет реализована, я
надеюсь, что включу ее описание в новое издание книги.

И вот — этот час настал! В версии РНР 7 были введены объявления скалярных
типов данных (scalar type declarations), называвшиеся ранее уточнениями типов
(type hints), а также объявления возвращаемых типов данных. Их применение
будет наглядно продемонстрировано на многих примерах в настоящем издании
книги. В версии РНР 7 были введены и другие полезные средства, в том чис
ле анонимные классы и некоторые улучшения, касающиеся пространств имен.

Дебаты сторонников и противников объектов
Объекты и объектно-ориентированное проектирование, похоже, разжигают
страсти среди программистов. Многие прекрасные программисты годами пи
сали отличные программы, не пользуясь объектами, и РНР продолжает быть
великолепной платформой для процедурного веб-программирования.
В данной книге повсюду демонстрируется пристрастие автора к ООП, по
скольку оно отражает его мировоззрение, “пораженное” привязанностью к объ
ектам. А поскольку данная книга посвящена объектам и является введением
в объектно-ориентированное проектирование, то нет ничего удивительного,
что главное внимание в ней уделяется объектно-ориентированным методикам.

ГЛАВА 2

РНР И ОБЪЕКТЫ

43

Но в то же время в книге нигде не утверждается, что объекты — это единствен
но правильный путь к успеху в программировании на РНР.
Выбор РНР в качестве объектно-ориентированного языка является делом
личных предпочтений каждого разработчика. В какой-то степени справедливо,
что вполне приемлемые для эксплуатации системы можно по-прежнему создать
с помощью функций и глобального кода. Некоторые замечательные инструмен
тальные средства (например, WordPress) по-прежнему строятся на основе проце
дурной архитектуры, хотя в настоящее время в них могут обширно применяться
объекты. Но в то же время программировать на РНР становится все труднее,
пренебрегая поддержкой объектов в этом языке. И не в последнюю очередь это
объясняется тем, что сторонние библиотеки, используемые в проектах, чаще
всего оказываются объектно-ориентированными.
Читая данную книгу, все же стоит иметь в виду знаменитый девиз Perl: “Лю
бую задачу можно решить несколькими способами”. Это особенно верно для
небольших программ, когда важнее быстро получить рабочий код и запустить
его, чем создавать структуру, которая сможет эффективно и безболезненно вы
расти в крупную систему (такого рода наспех разрабатываемые проекты назы
ваются “спайками” (spikes)).
Код — это гибкая среда. Самое главное — понять, когда быстрое испытание
идеи станет основанием для дальнейшего развития, и вовремя остановиться,
прежде чем проектные решения вам будет диктовать громадный объем кода.
И если вы решили выбрать проектно-ориентированный подход при работе над
своим проектом, то можно надеяться, что эта книга станет для вас хорошей от
правной точкой и поможет приступить к созданию объектно-ориентированных
архитектур.

Резюме
В этой краткой главе объекты были рассмотрены в контексте языка РНР. Бу
дущее РНР во многом связано с объектно-ориентированным проектированием.
В ряде последующих глав представлено текущее состояние поддержки объектов
в РНР и обсуждаются некоторые вопросы проектирования.

ГЛАВА 3

Основные положения
об объектах
В данной книге основное внимание уделяется объектам и классам, поскольку
с появлением версии 5 более десяти лет назад они стали основными элементами
языка РНР. В этой главе будет заложен прочный фундамент для дальнейшей ра
боты с объектами, описаны подходы к проектированию на основе исследования
объектно-ориентированных языковых средств РНР. Если объектно-ориентиро
ванное программирование — новая для вас область, постарайтесь очень внима
тельно прочитать эту главу.
В этой главе рассматриваются следующие вопросы.
Классы и объекты. Объявление классов и создание экземпляров объектов.
$ Методы-конструкторы. Автоматизация установки начальных значений
объектов.

Элементарные типы и классы. Почему тип имеет особое значение.

& Наследование. Зачем нужно наследование и как его использовать.

Видимость. Упрощение интерфейсов объектов и защита методов и свойств
от вмешательства извне.

Классы и объекты
Первым препятствием для понимания ООП служит странная и удивительная
связь между классом и объектом. Для многих людей именно эта связь стано
вится первым моментом откровения, первой искрой интереса к ООП. Поэтому
давайте уделим должное внимание самим основам.

Первый класс
Классы часто описывают с помощью объектов. И это весьма любопытно,
потому что объекты часто описывают с помощью классов. Такое хождение по

46

ЧАСТЬ II

ОБЪЕКТЫ

кругу может сильно затруднить первые шаги в ООП. Именно классы определя
ют объекты, и поэтому начать следует с определения классов.
Короче говоря, класс — это шаблон кода, применяемый для создания объ
ектов. Класс объявляется с помощью ключевого слова class и произвольного
имени класса. В именах классов может использоваться любое сочетание букв и
цифр, но они не должны начинаться с цифры. Код, связанный с классом, дол
жен быть заключен в фигурные скобки. Объединим эти элементы вместе, чтобы
создать класс следующим образом:
// Листинг 03.01

class ShopProduct
{
// Тело класса
}

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

Несколько первых объектов
Если класс — это шаблон для создания объектов, то объект — это данные,
которые структурируются по шаблону, определенному в классе. И в этом случае
говорят, что объект — это экземпляр класса. Его тип определяется классом.
Итак, воспользуемся классом ShopProduct как шаблоном для создания объ
ектов типа ShopProduct. Для этого нам потребуется оператор new, за которым
указывается имя класса, как показано ниже.
// Листинг 03.02

$productl = new ShopProduct();
$product2 = new ShopProduct() ;

После оператора new указывается имя класса в качестве его единственного
операнда. В итоге создается экземпляр этого класса; в данном примере — объ
ект типа ShopProduct.
Мы воспользовались классом ShopProduct как шаблоном для создания
двух объектов типа ShopProduct. И хотя функционально объекты $productl
и $product2 идентичны (т.е. пусты), тем не менее, это два разных объекта од
ного типа, созданные с помощью одного класса.
Если вам все еще непонятно, обратимся к аналогии. Представьте, что
класс — это форма для отливки, с помощью которой изготавливают пластмас
совые утки, а объекты — отливаемые утки. Тип создаваемых объектов опреде
ляется формой отливки. Утки выглядят одинаковыми во всех отношениях, но

ГЛАВА 3

ОСНОВНЫЕ ПОЛОЖЕНИЯ ОБ ОБЪЕКТАХ

47

все-таки это разные предметы. Иными словами, это разные экземпляры одного
и того же типа. У отдельных уток могут быть даже разные серийные номера,
подтверждающие их индивидуальность. Каждому объекту, создаваемому в сце
нарии на РНР, присваивается также идентификатор, однозначный в течение вре
мени существования объекта. Это означает, что в РНР идентификаторы объектов
повторно используются даже в пределах одного и того же процесса, где выпол
няется сценарий. Эту особенность можно продемонстрировать, выведя объекты
$productl и $product2 на печать следующим образом:
// Листинг 03.03
var_dump($productl);
var_dump($product2);

В результате вызовов приведенной выше функции на экран будет выведена
следующая информация:
object(ShopProduct)#1 (0) {
}
object(ShopProduct)#2 (0) {
}

НА ЗАМЕТКУ. В версиях РНР 4 и РНР 5 (до версии 5.1 включительно) объекты можно

выводить на печать непосредственно. В итоге объект будет приведен к символьной
строке, содержащей его идентификатор. Но, начиная с версии РНР 5.2, такая воз
можность больше не поддерживается, и любая попытка интерпретировать объект как
символьную строку приведет к ошибке, если только в классе этого объекта не будет
определен метод__ toStringO Методы будут рассмотрены далее в этой главе, а
метод toStringO — в главе 4.
Передав объекты функции var dump (), можно извлечь полезные сведения
о них, включая внутренний идентификатор каждого объекта, указанный после
символа ' #'. Чтобы сделать рассматриваемые здесь объекты более интересны
ми, придется немного изменить определение класса ShopProduct, добавив в
него специальные поля данных, называемые свойствами.

Установка свойств в классе
В классах можно определять специальные переменные, которые называются
свойствами. Свойство, называемое также переменной-членом, содержит данные,
которые могут меняться в разных объектах. Так, для объектов типа ShopProduct
требуется возможность изменять поля, содержащие название товара и его цену.
1 Обратите внимание на то, что имя метода начинается с двух знаков подчеркивания. —
Примеч. ред.

48

ЧАСТЬ II Ж ОБЪЕКТЫ

Определение свойства в классе похоже на определение обычной переменной,
за исключением того, что в операторе объявления перед именем свойства сле
дует указать одно из ключевых слов, характеризующих область его видимости:
public, protected или private.
НА ЗАМЕТКУ. Область видимости определяет контекст функции или класса, где можно

пользоваться данной переменной (свойством или методом, о чем пойдет речь далее
в этой главе). Так, у переменной, определенной в теле функции, имеется локальная
область видимости, а у переменной, определенной за пределами функции, — гло
бальная область видимости. Как правило, доступ к данным, находящимся в более
локальных областях видимости, чем текущая область, получить нельзя. Поэтому,
определив переменную в теле функции, вряд ли удастся впоследствии получить к
ней доступ за пределами этой функции. Объекты в этом смысле более “проницае
мы”, и к некоторым объектным переменным можно иногда получать доступ из друго
го контекста. Как поясняется далее, порядок доступа к переменным из конкретного
контекста определяется ключевыми словами public, protected и private.

Мы еще вернемся к обсуждению области видимости и определяющим ее
ключевым словам далее в этой главе. А до тех пор определим некоторые свой
ства с помощью ключевого слова public.
// Листинг 03.04

class ShopProduct
{
public $title
public $producerMainName
public $producerFirstName
public $price
}

=
=
=
=

’’Стандартный товар”;
"Фамилия автора";
"Имя автора";
0;

Как видите, мы определили четыре свойства, присвоив каждому из них стан
дартное значение. Теперь любым объектам, экземпляры которых получаются
с помощью класса ShopProduct, будут присваиваться стандартные данные.
А ключевое слово public, присутствующее в объявлении каждого свойства,
обеспечит доступ к этому свойству за пределами контекста его объекта.
К переменным свойств можно обращаться с помощью операции, обозначае
мой знаками ’ -> ’, указав имя объектной переменной и имя свойства, как по
казано ниже.
// Листинг 03.05

Sproductl = new ShopProduct();
print $productl->title;

В результате выполнения приведенных выше строк кода будет выведено сле
дующее:
Стандартный товар

ГЛАВА 3

ОСНОВНЫЕ ПОЛОЖЕНИЯ ОБ ОБЪЕКТАХ

49

Свойства объектов были определены как public, и поэтому их значения
можно прочитать, присвоить им новые значения, заменив тем самым набор
стандартных значений, устанавливаемых в классе по умолчанию.
// Листинг 03.06

$productl = new ShopProduct ();
$product2 = new ShopProduct();
$productl->title = ’’Собачье сердце”;
$product2->title = ’’Ревизор”;

Объявляя и устанавливая свойство $title в классе ShopProduct, мы га
рантируем, что при создании любого объекта типа ShopProduct это свойство
будет присутствовать и его значение будет заранее определено. Это означает,
что в том коде, где используется данный класс, можно будет работать с любы
ми объектами типа ShopProduct. Но поскольку свойство $title можно легко
переопределить, то его значение может меняться в зависимости от конкретного
объекта.
НА ЗАМЕТКУ. Код, в котором используется класс, функция или метод, обычно называет

ся клиентом класса, функции или метода или просто клиентским кодом. Этот термин
будет часто встречаться в последующих главах.
На самом деле в РНР необязательно объявлять все свойства в классе. Свой
ства можно динамически добавлять в объект следующим образом:
// Листинг 03.07
$productl->arbitraryAddition = "Дополнительный параметр";

Следует, однако, иметь в виду, что такой способ назначения свойств для объ
ектов считается неудачной нормой практики в ООП и почти никогда не при
меняется. А почему такая норма практики считается неудачной? Дело в том,
что при создании класса вы определяете конкретный тип данных. Тем самым
вы сообщаете всем, что ваш класс (и любой объект, который является его эк
земпляром) содержит определенный набор полей и функций. Если в классе
ShopProduct определяется свойство $title, то в любом коде, манипулирую
щем объектами типа ShopProduct, предполагается, что свойство $title опре
делено. Но подобной гарантии в отношении свойств, устанавливаемых динами
чески, дать нельзя.
Созданные нами объекты пока еще производят довольно тягостное впечатле
ние. Когда нам потребуется манипулировать свойствами объекта, это придется
делать за пределами данного объекта. Следовательно, нужно каким-то обра
зом устанавливать и получать значения свойств объекта. Установка нескольких
свойств в целом ряде объектов очень быстро становится довольно хлопотным
делом, как показано ниже.

50

ЧАСТЬ II Й ОБЪЕКТЫ

// Листинг 03.08
$productl->title
$productl->producerMainName
$productl->producerFirstName
$productl->price

=
=
=
=

п
"Собачье
сердце";
п
"Булгаков";
II
"Михаил";
5.99;

Здесь снова используется класс ShopProduct и все стандартные значения
его свойств переопределяются одно за другим до тех пор, пока не будут заданы
все сведения о товаре. А теперь, когда у нас имеются некоторые данные, к ним
можно обратиться следующим образом:
// Листинг 03.09

print "Автор: {$productl->producerFirstName} "
. "{$productl->producerMainName}\n";

Выполнение данного фрагмента кода приведет к следующему результату:
Автор: Михаил Булгаков

У такого подхода к определению значений свойств имеется ряд недостатков.
В языке РНР допускается определять свойства динамически, и поэтому вы не
получите предупреждения, если забудете имя свойства, или сделаете в нем опе
чатку. Например, вместо следующей строки кода:
$productl->producerMainName = "Булгаков";

можно случайно ввести такую строку:
$productl->producerSecondName = "Булгаков";

С точки зрения интерпретатора РНР этот код совершенно корректен, поэто
му никакого предупреждения об ошибке мы не получим. Но когда понадобится
распечатать имя автора, мы получим неожиданные результаты.
Еще одно затруднение состоит в том, что мы слишком “нестрого” определили
свой класс, в котором совсем не обязательно нужно указывать название книги,
цену или фамилию автора. Клиентский код может быть уверен, что эти свойства
существуют, но зачастую их исходно устанавливаемые стандартные значения
вряд ли будут его устраивать. В идеале следовало бы побуждать всякого, кто
создает экземпляры объекта типа ShopProduct, задавать вполне осмысленные
значения его свойств.
И, наконец, нам придется приложить немало усилий, чтобы сделать то, что,
вероятнее всего, придется делать очень часто. Как было показано выше, распе
чатать полное имя автора — дело весьма хлопотное. И было бы неплохо, если
бы объект делал это вместо нас. Все эти затруднения можно разрешить, если
снабдить объект типа ShopProduct собственным набором функций, чтобы поль
зоваться ими для манипулирования данными свойств в контексте самого объекта.

ГЛАВА 3 « ОСНОВНЫЕ ПОЛОЖЕНИЯ ОБ ОБЪЕКТАХ

51

Работа с методами
Если свойства позволяют объектам сохранять данные, то методы —выпол
нять конкретные задачи. Методы — это специальные функции, объявляемые
в классе. Как и следовало ожидать, объявление метода напоминает объявление
функции. После ключевого слова function указывается имя метода, а вслед за
ним — необязательный список переменных-аргументов в круглых скобках. Тело
метода заключается в фигурные скобки, как показано ниже.
public function myMethod($argument, Sanother)
{
// ...
}

В отличие от функций, методы следует объявлять в теле класса. При этом
можно указывать также ряд спецификаторов, в том числе ключевое слово, опре
деляющее область видимости метода. Как и свойства, методы можно опреде
лять как public, protected или private. Объявляя метод как public, мы тем
самым обеспечиваем возможность его вызова за пределами текущего объекта.
Если в определении метода опустить ключевое слово, определяющее область
его видимости, то метод будет объявлен неявно как public. К модификаторам
методов мы еще вернемся далее в этой главе.
// Листинг 03.10
class ShopProduct
{
public $title
public $producerMainName
public $producerFirstName
public $price

=
=
=
=

"Стандартный товар";
"Фамилия автора";
"Имя автора";
0;

public function getProducer()

return $this->producerFirstName . " "
. $this->producerMainName;
}
}

Зачастую метод вызывается с помощью объектной переменной, после кото
рой указываются знаки
и имя метода. При вызове метода следует указы
вать круглые скобки, как и при вызове функции (даже если методу вообще не
передаются аргументы).
// Листинг 03.11
$productl = new ShopProduct();
$productl->title
$productl->producerMainName

Собачье сердце";
Булгаков";

52

ЧАСТЬ II ® ОБЪЕКТЫ

$productl->producerFirstName = "Михаил”;
$productl->price
= 5.99;

print ’’Автор: { $productl->getProducer () }\n";

Выполнение данного фрагмента кода приведет к следующему результату:
Автор: Михаил Булгаков

Итак, мы ввели метод getProducer() в класс ShopProduct. Обратите вни
мание на то, что этот метод был определен как открытый (public), а следова
тельно, его можно вызывать за пределами класса ShopProduct.
В теле метода getProducer () мы воспользовались новым средством —
псевдопеременной $this. С ее помощью реализуется механизм доступа к эк
земпляру объекта из кода класса. Чтобы легче уяснить принцип действия такого
механизма, попробуйте заменить выражение $this “текущим экземпляром объ
екта”. Например, оператор
$this->producerFirstName

означает:
Свойство $producerFirstName текущего экземпляра объекта

Таким образом, метод getProducer () объединяет и возвращает значения
свойств $producerFirstName и $producerMainName, избавляя нас от лишних
хлопот всякий раз, когда требуется распечатать полное имя автора.
Хотя нам удалось немного усовершенствовать наш класс, ему по-прежнему
присуща излишняя гибкость. Мы все еще рассчитываем на то, что програм
мист будет изменять стандартные значения свойств объекта типа ShopProduct.
Но это затруднительно в двух отношениях. Во-первых, потребуется пять строк
кода, чтобы должным образом инициализировать объект типа ShopProduct, и
ни один программист не поблагодарит нас за это. И во-вторых, мы никак не
можем гарантировать, что какое-нибудь свойство будет определено при инициа
лизации объекта типа ShopProduct. Поэтому нам потребуется метод, который
будет вызываться автоматически при создании экземпляра объекта из его класса.

Создание метода-конструктора
Метод-конструктор вызывается при создании объекта. Он служит для на
стройки экземпляра объекта, установки определенных значений его свойств и
выполнения всей подготовительной работы к применению объекта.
НА ЗАМЕТКУ. До версии РНР 5 имя метода-конструктора совпадало с именем класса, к

которому оно относилось. Так, в качестве конструктора класса ShopProduct можно
было пользоваться методом ShopProduct (). Теперь такой синтаксис вообще не ра
ботает и считается устаревшим, начиная с версии РНР 7. Поэтому метод-конструктор
следует называть как constructo.

ГЛАВА 3

ОСНОВНЫЕ ПОЛОЖЕНИЯ ОБ ОБЪЕКТАХ

53

Обратите внимание на то, что имя метода-конструктора начинается с двух
символов подчеркивания. Это правило именования распространяется и на мно
гие другие специальные методы в классах РНР. Теперь определим конструктор
для класса ShopProduct следующим образом:
// Листинг 03.12
class ShopProduct
{
public $title;
public $producerMainName;
public $producerFirstName;
public $price = 0;
public function __ construct(
$title,
$firstName,
$mainName,
$price
) {
$this->title = $title;
$this->producerFirstName = $firstName;
$this->producerMainName = $mainName;
$this->price = $price;
}

public function getProducer()
{
return $this->producerFirstName . " ”
. $this->producerMainName;
}
}

И снова мы вводим в класс новые функциональные возможности, стараясь
сэкономить время и силы программиста и избавить его от необходимости ду
блировать код, работающий с классом ShopProduct. Метод__ construct ()
автоматически вызывается при создании объекта с помощью оператора new, как
показано ниже.
// Листинг 03.13
$productl = new ShopProduct(
"Собачье сердце",
"Михаил",
"Булгаков",
5.99
) ;

print "Автор: {$productl->getProducer()}\п";

Выполнение данного фрагмента кода приведет к следующему результату:
Автор: Михаил Булгаков

54

ЧАСТЬ II Й ОБЪЕКТЫ

Значения всех перечисленных аргументов передаются конструктору. В дан
ном примере конструктору передается название книги, Ф.И.О. автора и цена.
Для присвоения значений соответствующим свойствам объекта в методе-кон
структоре применяется псевдопеременная $this.
НА ЗАМЕТКУ. Теперь получать экземпляры и пользоваться объектом типа ShopProduct стало

безопаснее и легче. Ведь получение экземпляров и установка значений свойств выполняются
в одном операторе. При написании любого кода, где используется объект типа ShopProduct,
можно быть уверенным, что все свойства этого объекта будут инициализированы.

Очень важным аспектом ООП является предсказуемость. Чтобы сделать объ
ект безопасным, достаточно, например, воспроизвести предсказуемые типы дан
ных, хранящиеся в его свойствах. При этом можно гарантировать, что в свойстве
$name, например, всегда будут находиться только символьные данные. Но как
этого добиться, если данные для инициализации свойств поступают в виде пара
метров из вне класса? В следующем разделе мы изучим механизм, который мож
но использовать для явного определения типов объектов при объявлении методов.

Аргументы и типы
Типы определяют порядок оперирования данными в сценариях. Например,
строковый тип используется для хранения и отображения символьных данных,
а также для выполнения операций над такими данными с помощью строковых
функций. Целые числа применяются в математических выражениях, булевы зна
чения — в логических выражениях и т.д. Эти категории называются элемен
тарными. или простыми типами данных (primitive types). Имя класса также
определяет тип данных, но на более высоком уровне. Поэтому объект класса
ShopProduct относится как к простому типу object, так и к типу самого клас
са ShopProduct. В этом разделе мы рассмотрим обе разновидности типов дан
ных по отношению к методам класса.
При определении метода и функции не требуется, чтобы аргумент относился
к конкретному типу. Но в этом одновременно заключается преимущество и не
достаток. С одной стороны, принадлежность аргумента к любому типу данных
доставляет немало удобств. Благодаря этому можно создавать методы, которые
будут гибко реагировать на данные различных типов и приспосабливать свои
функциональные возможности к меняющимся обстоятельствам. Но, с другой
стороны, такая гибкость может стать причиной неопределенности в коде, когда
в теле метода ожидается один тип аргумента, а передается другой.

Простые типы данных
РНР является слабо типизированным языком, а это означает, что объявлять
тип данных, который должен храниться в переменной, не нужно. Так, в пре
делах одной и той же области видимости переменная $ number может содер
жать как числовое значение 2, так и символьную строку ’’two” (“два”). В таких

ГЛАВА 3 < ОСНОВНЫЕ ПОЛОЖЕНИЯ ОБ ОБЪЕКТАХ

55

строго типизированных языках программирования, как С или Java, вы обязаны
определить тип переменной до присваивания ей значения, и, конечно, это зна
чение должно быть указанного типа.
Но это совсем не означает, что в РНР отсутствует понятие типа. Каждое зна
чение, которое можно присвоить переменной, имеет свой тип данных. В РНР
тип значения переменной можно определить с помощью одной из функций для
проверки типов. В табл. 3.1 перечислены простые типы данных, существующие
в РНР, а также соответствующие им проверочные функции. Каждой функции
передается переменная или значение, а она возвращает значение true (“исти
на”), если аргумент относится к соответствующему типу данных. Проверка типа
переменной особенно важна при обработке аргументов в методе или функции.
Таблица 3.1. Простые типы данных в РНР и их проверочные функции

Проверочная функция
is_bool()

Тип
Boolean

Описание

is integer!)

Integer

Целое число; является псевдонимом функций
is int() His long!)

is_double()

Double

Число с плавающей (десятичной) точкой; являет
ся псевдонимом функции is_float()

is string!)

String

Символьные данные

is object!)

Object

Объект

is array!)

Array

Массив

is_resource()

Resource

Дескриптор, используемый для идентификации и
работы с такими внешними ресурсами, как базы
данных или файлы

is null!)

Null

Неопределенное значение

Одно из двух логических значений: true или
false (истина или ложь)

Пример использования простых типов данных

Имейте в виду, что вы должны внимательно следить за типами данных в
своем коде. Рассмотрим пример одного из многих затруднений, с которыми вы
можете столкнуться, используя типы данных.
Допустим, требуется извлечь параметры конфигурации из XML-файла. Эле
мент разметки XML-документа сообщает приложению,
следует ли пытаться преобразовывать IP-адреса в доменные имена. Следует за
метить, что такое преобразование полезно, хотя и является относительно мед
ленной операцией. Ниже приведен фрагмент кода XML для данного примера.

false

56

ЧАСТЬ II ж ОБЪЕКТЫ

Приложение извлекает символьную строку ’’false" и передает ее в качестве
параметра методу outputAddresses (), который выводит информацию об 1Р-адресах. Ниже приведено определение метода outputAddresses ().
// Листинг 03.15
class AddressManager
{
private $addresses = [”209.131.36.159”, "216.58.213.174"];
public function outputAddresses($resolve)
{
foreach ($this->addresses as $address) {
print $address;
if ($resolve) {
print " (".gethostbyaddr($address).")";
}
print ”\n";
}
}

}

Разумеется, в класс AddressManager можно внести ряд улучшений. В част
ности, жестко кодировать IP-адреса в виде массива непосредственно в классе
не очень удобно. Тем не менее метод outputAddresses () циклически обходит
массив IP-адресов и выводит его элементы по очереди. Если значениеаргумен
та $resolve равно true, то данный метод выводит не только IP-адреса, но и
соответствующие им доменные имена.
Ниже приведен один из возможных вариантов применения класса Address
Manager вместе с дескриптором settings в элементе XML-разметки файла кон
фигурации. Попробуйте обнаружить ошибку в приведенном ниже фрагменте кода.
// Листинг 03.16
$settings = simplexml_load_file(__ DIR__ ."/resolve.xml");
$manager = new AddressManager ();
$manager->outputAddresses( (string) $settings->resolvedomains);

В этом фрагменте кода для получения значения из элемента разметки
resolvedomains применяется интерфейс SimpleXML API. В рассматриваемом
здесь примере нам известно, что это значение представляет собой текстовый
элемент "false", и поэтому оно приводится к строковому типу, поскольку
именно так рекомендуется поступать в документации по SimpleXML API.
Но анализируемый здесь код поведет себя совсем не так, как мы того ожи
дали. Передавая символьную строку "false" методу outputAddresses (), мы
не знаем, какой именно тип аргумента используется в этом методе по умолча
нию. Данный метод ожидает получить логическое значение аргумента (true
или false). При выполнении условного оператора символьная строка "false"
на самом деле преобразуется в логическое значение true. Дело в том, что при

ГЛАВА 3 > ОСНОВНЫЕ ПОЛОЖЕНИЯ ОБ ОБЪЕКТАХ

57

выполнении проверки интерпретатор РНР с готовностью преобразует непустое
строковое значение в логическое значение true. Поэтому следующий фрагмент
кода:
if ( ’’false" ) {
// ...
}

равнозначен такому фрагменту кода:
if ( true ) {
// ...
}

Исправить этот недостаток можно по-разному. Во-первых, можно сделать
метод outputAddresses () менее требовательным, чтобы он распознавал сим
вольную строку и применял некоторые основные правила для ее преобразова
ния в логический эквивалент:
// Листинг 03.17

public function outputAddresses($resolve)
{
if (is_string($resolve)) {
$resolve = (preg_match(”/A(false|no|off)$/i", $resolve))
? false : true;
}
// ...
}

Но с точки зрения проектирования существуют достаточно веские основания
избегать приведенного выше решения. Вообще говоря, при проектировании ме
тодов или функций лучше предусматривать для них строгий интерфейс, исклю
чающий двусмысленность, вместо неясного и нетребовательного интерфейса.
Подобные решения так или иначе вызывают путаницу и порождают ошибки.
Во-вторых, можно оставить метод outputAddresses () без изменений, до
полнив его комментариями с четкими инструкциями, что аргумент $resolve
должен содержать логическое значение. Такой подход позволяет предупредить
программиста, что нужно внимательно читать инструкции, а иначе пенять на
себя.
у*★
* Вывести список адресов.
* Если переменная $resolve содержит истинное
* значение (true), то адрес преобразуется в
* эквивалентное имя хоста.
* @param $resolve Boolean Преобразовать адрес?
*/
function outputAddresses( $resolve ) {
// ...

58

ЧАСТЬ II Ж ОБЪЕКТЫ

Это вполне разумное решение, если вы точно уверены в том, что програм
мисты, пользующиеся вашим классом, добросовестно прочтут документацию к
нему. И наконец, в-третьих, можно сделать метод outputAddresses () строгим
в отношении типа данных аргумента $ resolve. Для таких простых типов дан
ных, как логические значения, до выпуска версии РНР 7 это можно было сде
лать лишь одним способом: написать код для проверки входных данных и пред
принять соответствующее действие, если они не отвечают требуемому типу:
function outputAddresses($resolve)
{

if (1 is_bool($resolve)) {
// принять решительные меры
}

//...
}

Такой подход вынуждает клиентский код предоставить корректный тип дан
ных для аргумента $ resolve.
НА ЗАМЕТКУ. В следующем далее разделе “Уточнение типов объектов” описывается на

много более совершенный способ наложения ограничений на типы аргументов, пере
даваемых методам и функциям.
Преобразование строкового аргумента внутри метода — более дружественный подход
с точки зрения клиента, но, вероятно, он может вызвать другие проблемы. Обеспечивая
механизм преобразования в методе, мы предугадываем контекст его использования
и намерение клиента. С другой стороны, соблюдая логический тип данных, мы пре
доставляем клиенту право выбора: преобразовывать ли символьные строки в логиче
ские значения и решить, какое слово должно соответствовать логическому значению
true или false. А между тем метод outputAddresses () разрабатывался с целью
решить конкретную задачу. Такой акцент на выполнении конкретной задачи при наме
ренном игнорировании более широкого контекста является важным принципом ООП,
к которому мы будем еще не раз возвращаться в данной книге.
На самом деле стратегии обращения с типами аргументов зависят от степени
серьезности возможных ошибок. Большинство значений простых типов данных
в РНР автоматически приводятся к нужному типу в зависимости от конкрет
ного контекста. Так, если числа, присутствующие в символьных строках, ис
пользуются в математических выражениях, они автоматически преобразуются в
эквивалентные целые значения или же значения с плавающей точкой. В итоге
прикладной код может быть нетребовательным к ошибкам несоответствия ти
пов данных. Но если в качестве одного из аргументов метода предполагается
массив, то следует проявить большую, чем обычно, внимательность. Передача
значения, не являющегося массивом, одной из функций обработки массивов в
РНР не приведет ни к чему хорошему и вызовет ряд ошибок в разрабатывае
мом методе. Поэтому вам придется найти нечто среднее между проверкой типа,

ГЛАВА 3

ОСНОВНЫЕ ПОЛОЖЕНИЯ ОБ ОБЪЕКТАХ

59

преобразованием одного типа данных в другой и опорой на понятную доку
ментацию, которую вы обязаны предоставить независимо от выбранного вами
способа.
Каким бы способом вы ни решали подобного рода затруднения в своем коде,
можете быть уверены лишь в одном: тип аргумента всегда имеет особое зна
чение! Это значение становится еще более весомым в связи с тем, что РНР не
является строго типизированным языком. Здесь нельзя полагаться на компиля
тор в вопросах предотвращения ошибок, связанных с нарушением типов дан
ных. Поэтому вы должны предусмотреть возможные последствия того, что типы
аргументов окажутся не такими, как предполагалось. Не стоит надеяться, что
программисты клиентского кода угадают ход ваших мыслей. Вы должны всег
да учитывать, что в разрабатываемые вами методы будут передаваться входные
данные некорректного типа.

Уточнение типов объектов
Как упоминалось ранее, переменная аргумента может иметь любой простой
тип данных, но по умолчанию ее тип не оговаривается, и поэтому она может со
держать объект любого типа. С одной стороны, такая гибкость удобна, а с дру
гой — она может стать причиной осложнений при определении метода.
Рассмотрим в качестве примера метод, предназначенный для работы с объ
ектом типа ShopProduct.
// Листинг 03.18
class ShopProductWriter
{
public function write($shopProduct)
{
$str = $shopProduct->title .
"
. $shopProduct->getProducer()
. ’’ (" . $shopProduct->price . ")\n”;
print $str;
}
}

Мы можем протестировать работу этого класса следующим образом:
// Листинг 03.19

$productl = new ShopProduct("Собачье сердце",
"Михаил", "Булгаков", 5.99);
$writer = new ShopProductWriter();
$writer->write($productl);

В итоге получим следующий результат:
Собачье сердце: Михаил Булгаков (5.99)

60

ЧАСТЬ II ж ОБЪЕКТЫ

Класс ShopProductWriter содержит единственный метод write (). Методу
write () передается объект типа ShopProduct. Свойства и методы последнего
используются в нем для создания и вывода результирующей строки с описани
ем товара. Мы используем имя переменной аргумента $ShopProduct как на
поминание программисту, что методу $write () следует передать объект типа
ShopProduct, хотя соблюдать это требование необязательно. Это означает, что
программист может передать методу $write () некорректный объект или вооб
ще данные простого типа и ничего об этом не узнать до момента обращения к
аргументу $ShopProduct. К тому времени в нашем коде уже могут быть вы
полнены какие-либо действия, поскольку предполагалось, что методу write ()
был передан настоящий объект типа ShopProduct.
НА ЗАМЕТКУ. В связи с изложенным выше у вас может возникнуть вопрос: почему мы

не ввели метод write () непосредственно в класс ShopProduct? Все дело в ответ
ственности. Класс ShopProduct отвечает за хранение данных о товаре, а класс Shop
Productwriter — за вывод этих данных. По мере чтения этой главы вы начнете по
степенно понимать, в чем польза такого разделения ответственности.
Дня решения упомянутой выше проблемы в РНР 5 были добавлены объявле
ния типов классов, называвшиеся уточнениями типов аргументов. Чтобы доба
вить объявление типа класса к аргументу метода, достаточно указать перед ним
имя класса. Поэтому в метод write () можно внести следующие коррективы:
// Листинг 03.20

public function write(ShopProduct $shopProduct)
{
// ...
}

Теперь методу write () можно передавать аргумент $shopProduct, содер
жащий только объект типа ShopProduct. В следующем фрагменте кода пред
принимается попытка “перехитрить” метод write (), передав ему объект дру
гого типа:
// Листинг 03.21
class Wrong
{
}

$writer = new ShopProductWriter() ;
$writer->write(new Wrong());

Метод write () содержит объявление типа класса, и поэтому передача ему
объекта типа Wrong приведет к неустранимой ошибке, как показано ниже.

ГЛАВА 3 Ж ОСНОВНЫЕ ПОЛОЖЕНИЯ ОБ ОБЪЕКТАХ

61

TypeError: Argument 1 passed to ShopProductWriter:: write () must be an instance of
ShopProduct, instance of Wrong given, called in Runner.php on ...2

Теперь, вызывая метод write (), совсем не обязательно проверять тип пере
даваемого ему аргумента. Это делает сигнатуру метода намного более понятной
для программиста клиентского кода. Он сразу же увидит требования, предъяв
ляемые к вызову метода write (). Ему не нужно будет беспокоиться по поводу
скрытых ошибок, возникающих в результате несоответствия типа аргумента,
поскольку объявление типа класса соблюдается строго.
Несмотря на то что автоматическая проверка типов данных служит превос
ходным средством для предотвращения ошибок, важно понимать, что объявления
типов классов проверяются во время выполнения программы. Это означает, что
проверяемое объявление типа класса сообщит об ошибке только тогда, когда ме
тоду будет передан нежелательный объект. И если вызов метода write () глубоко
скрыт в условном операторе, который выполняется только на Рождество, то вам
придется поработать на праздники, если вы тщательно не проверите свой код.
Имея теперь в своем распоряжении объявления скалярных типов, можно на
ложить некоторые ограничения на класс ShopProduct следующим образом:
// Листинг 03.22
class ShopProduct
{
public $title;
public $producerMainName;
public $producerFirstName;
public $price = 0;
public function __ construct(
string $title,
string $firstName,
string $mainName,
float $price
) {
$this->title = $title;
$this->producerFirstName = $firstName;
$this->producerMainName = $mainName;
$this->price = $price;
}

// ...

}

Укрепив подобным образом метод-конструктор, можно гарантировать, что
аргументы $title, $firstName, $mainName будут всегда содержать строковые
2 Ошибка нарушения типа данных: аргумент 1, переданный методу ShopProduct
Writer: :write (), должен быть экземпляром класса ShopProduct, а переданный экзем
пляр класса Wrong некорректен, вызвано из исходного файла Runner.php ...

62

ЧАСТЬ II

Ж

ОБЪЕКТЫ

данные, тогда как аргумент $price — числовое значение с плавающей точкой.
В этом можно убедиться, попытавшись получить экземпляр класса ShopProduct
с неверными данными:
// Листинг 03.23
// Не сработает!
$product = new ShopProduct("Название", "Имя", "Фамилия",

[]);

В данном случае предпринимается попытка получить экземпляр класса
ShopProduct. Конструктору этого класса передаются три символьные строки и
пустой массив вместо требующегося числового значения с плавающей точкой,
что в конечном итоге приведет к неудачному исходу. Благодаря объявлениям
типов данных интерпретатор РНР не допустит такого, выдав следующее сооб
щение об ошибке:
TypeError: Argument 4 passed to ShopProductWriter:: write () must be of the type
float, array given, called in ..,3

По умолчанию интерпретатор PHP выполнит там, где это возможно, неяв
ное приведение значений аргументов к требующимся типам данных. И это ха
рактерный пример упоминавшегося ранее противоречия между безопасностью
и гибкостью прикладного кода. Так, в новой реализации класса ShopProduct
символьная строка будет автоматически преобразована в числовое значение с
плавающей точкой, и поэтому следующая попытка получить экземпляр данно
го класса, где символьная строка ”4.22” преобразуется внутренним образом в
числовое значение 4.22, не вызовет проблем:
// Листинг 03.24
$product = new ShopProduct("Название", "Имя", "Фамилия", "4.22");

Все это, конечно, замечательно, но вернемся к затруднению, возникшему в
связи с применением класса AddressManager, где символьная строка "false”
негласно преобразовывалась в логическое значение. По умолчанию это преобра
зование будет происходить по-прежнему, если применить объявление логическо
го типа данных в методе AddressManager: :outputAddresses () следующим
образом:
// Листинг 03.25
public function outputAddresses(bool $resolve)
{
// ...
}

3 Ошибка нарушения типа данных: аргумент 4, переданный методу ShopProduct
Writer: :write(), должен быть числовым типом с плавающей точкой, а переданный мас
сив некорректен, вызвано из ...

ГЛАВА 3

ОСНОВНЫЕ ПОЛОЖЕНИЯ ОБ ОБЪЕКТАХ

63

А теперь рассмотрим следующий вызов, где методу outputAddresses () пе
редается символьная строка:
// Листинг 03.26
$manager->outputAddresses ("false");

Вследствие неявного приведения типов этот вызов функционально равнозна
чен вызову данного метода с логическим значением true.
Объявления скалярных типов данных можно сделать строгими, хотя только
на уровне отдельных исходных файлов. В следующем примере кода устанавли
ваются строгие объявления типов данных, а метод outputAddresses () снова
вызывается с символьной строкой:
// Листинг 03.27

declare(strict_types=l);
$manager->outputAddresses ("false");

Этот вызов приведет к появлению следующей ошибки типа ТуреЕггог из-за
строгих объявлений типов данных:
ТуреЕггог: Argument 4 passed to AddressManager::outputAddresses() must be of
the type boolean, string given, called in ...4

НА ЗАМЕТКУ. Объявление strict_types применяется к тому исходному файлу, откуда делает

ся вызов, а не к исходному файлу, где реализована функция или метод. Поэтому соблюдение
строгости такого объявления возлагается на клиентский код.

Иногда аргумент требуется сделать необязательным и, тем не менее, нало
жить ограничение на его тип, если он все же указывается. Для этого достаточно
указать стандартное значение аргумента, устанавливаемое по умолчанию, как
показано ниже.
// Листинг 03.28

class ConfReader
{
public function getValues(array $default = null)
$values = [];

// Выполнить действия для получения новых значений
// Объединить полученные значения со стандартными
// (результат всегда будет находиться в массиве)
4 Ошибка нарушения типа данных: аргумент 4, переданный методу AddressManager
: : outputAddresses (), должен быть логическим типом, а переданная символьная строка
некорректна, вызвано из ...

64

ЧАСТЬ II ж ОБЪЕКТЫ
$values = array_merge($default,
return $values;

$values);

}

}

Объявления типов, которые поддерживаются в РНР, перечислены в табл. 3.2.
Таблица 3.2. Объявления типов данных в РНР

Объявляемый
тип данных

Версия, начиная с
которой поддерживается

Описание

array

5.1

Массив. По умолчанию может быть
пустым значением или массивом

int

7.0

Целое значение. По умолчанию мо
жет быть пустым или целым значе
нием

float

7.0

Числовое значение с плавающей (де
сятичной) точкой. Допускается целое
значение, даже если активизирован
строгий режим. По умолчанию может
быть пустым, целым или числовым
значением с плавающей точкой

callable

5.4

Вызываемый код (например, аноним
ная функция). По умолчанию может
быть пустым значением

bool

7.0

Логическое значение. По умолчанию
может быть пустым или логическим
значением

string

5.0

Символьные данные. По умолчанию
может быть пустым или строковым
значением

self

5.0

Ссылка на содержащий класс

[тип класса]

5.0

Тип класса или интерфейса. По умол
чанию может быть пустым значением

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

Наследование
Наследование — это механизм, посредством которого один или несколько
классов можно получить из некоторого базового класса. Класс, унаследованный
от другого класса, называется его подклассом. Эта связь обычно описывается
с помощью терминов родительский и дочерний. В частности, дочерний класс

ГЛАВА 3 ■» ОСНОВНЫЕ ПОЛОЖЕНИЯ ОБ ОБЪЕКТАХ

65

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

Проблема наследования
Вернемся к классу ShopProduct, который в настоящий момент является до
статочно обобщенным. С его помощью можно манипулировать самыми разными
товарами, как показано ниже.
// Листинг 03.29
$productl = new ShopProduct(

$product2 = new ShopProduct(

print "Автор: "
print "Исполнитель:

"

Собачье сердце",
'Михаил", "Булгаков",

5.99 );

Классическая музыка. Лучшее",
’Антонио", "Вивальди", 10.99 )

.$productl->getProducer()
.$product2->getProducer()

"\п";
"\п";

Выполнение данного фрагмента кода приведет к следующему результату:
Автор: Михаил Булгаков
Исполнитель: Антонио Вивальди

Как видите, разделение имени автора на две части очень хорошо подходит
как при работе с книгами, так и с компакт-дисками. В этом случае мы можем
отсортировать товары по фамилии автора (т.е. по полю, содержащему строковые
значения ’’Булгаков’1 и ’’Вивальди”), а не по имени, в котором содержатся
менее определенные строковые значения ’’Михаил” и ’’Антонио". Лень — это
отличная стратегия проектирования, поэтому на данной стадии разработки не
стоит особенно беспокоиться об употреблении класса ShopProduct для описа
ния более чем одного вида товара.
Но если добавить в рассматриваемом здесь примере несколько новых требо
ваний, то дело сразу же усложнится. Допустим, требуется отобразить данные,
характерные только для книг или компакт-дисков. Скажем, для компакт-дисков
желательно вывести общую продолжительность звучания, а для книг — количе
ство страниц. Безусловно, могут быть и другие отличия, но даже эти наглядно
показывают суть возникшей проблемы.
Как же расширить данный пример, чтобы учесть все эти изменения? На ум
сразу приходят два варианта. Во-первых, можно расположить все данные в клас
се ShopProduct, а во-вторых, разделить класс ShopProduct на два отдельных
класса. Рассмотрим сначала первый вариант. Ниже показано, как объединить все
данные о книгах и компакт-дисках в одном классе.

66

ЧАСТЬ II * ОБЪЕКТЫ

// Листинг 03.30

class ShopProduct
{

public
public
public
public
public
public

$numPages;
$playLength;
$title;
$producerMainName;
$producerFirstName;
$price;

public function __ construct(
string $title,
string $firstName,
string $mainName,
float $price,
int $numPages = 0,
int $playLength = 0
)

{

$this->title = $title;
$this->producerFirstName = $firstName;
$this->producerMainName = $mainName;
$this->price = $price;
$this->numPages = $numPages;
$this->playLength = SplayLength;
}
public function getNumberOfPages()
{

return $this->numPages;
}

public function getPlayLength()
{

return $this->playLength;
}

public function getProducer()
{

return $this->producerFirstName
. $this->producerMainName;

.

"

”

}
}

Чтобы продемонстрировать проявляющиеся противоречивые силы, в дан
ном примере были использованы методы доступа к свойствам $numPages и
$playLength. В итоге объект, экземпляр которого создается с помощью при
веденного выше класса, будет всегда содержать избыточные методы. Кроме
того, экземпляр объекта, описывающего компакт-диск, приходится создавать с
помощью лишнего аргумента конструктора. Таким образом, для компакт-диска
будут сохраняться данные и функциональные возможности класса, относящие
ся к книгам (количество страниц), а для книг — данные о продолжительности
звучания компакт-диска. С этим пока еще можно как-то мириться. Но что, если

ГЛАВА 3 О ОСНОВНЫЕ ПОЛОЖЕНИЯ ОБ ОБЪЕКТАХ

67

добавить больше видов товаров, причем каждый из них с собственными ме
тодами обработки, а затем ввести дополнительные методы для каждого вида
товара? В конечном счете класс окажется слишком сложным и трудным для
применения.
Поэтому принудительное объединение полей, относящихся к разным това
рам, в один класс приведет к созданию слишком громоздких объектов с лишни
ми свойствами и методами.
Но этим рассматриваемая здесь проблема не ограничивается. Функциональ
ные возможности данного класса также вызывают серьезные трудности. Пред
ставьте метод, выводящий краткие сведения о товаре. Допустим, что сведения
о товаре требуются отделу продаж для указания в виде одной итоговой стро
кой в счете-фактуре. Они хотят, чтобы мы включили в нее время звучания ком
пакт-диска и количество страниц книги. Таким образом, нам придется реализо
вать этот метод отдельно для каждого вида товара. Чтобы отслеживать формат
объекта, можно воспользоваться специальным признаком, как демонстрируется
в следующем примере:
// Листинг 03.31

public function getSummaryLine ()
{

$base
= "{$this->title} ( {$this->producerMainName},
$base .= "{$this->producerFirstName} )";
if ($this->type == 'book') {
$base .=
{$this->numPages} стр.";
} elseif ($this->type == 'cd') {
$base .=
Время звучания - {$this->playLength}";
}
return $base;

}

Значение свойства $type устанавливается в конструкторе при создании объ
екта типа ShopProduct. Для этого нужно проанализировать значение аргумента
$numPages. Если он содержит число больше нуля, то это книга, иначе — ком
пакт-диск. В итоге класс ShopProduct стал еще более сложным, чем нужно. По
мере добавления дополнительных отличий в форматы или ввода новых форма
тов нам будет все труднее справляться с реализацией функциональных возмож
ностей данного класса. Поэтому для решения рассматриваемой здесь проблемы,
по-видимому, придется выбрать другой подход.
В связи с тем что класс ShopProduct начинает напоминать “два класса в
одном”, нам придется это признать и создать два типа вместо одного. Ниже
показано, как это можно сделать.
// Листинг 03.32
class CdProduct
{
public $playLength;

68

ЧАСТЬ II ® ОБЪЕКТЫ

public
public
public
public

$title;
$producerMainName;
$producerFirstName;
$price;

public function __ construct(
string $title,
string $firstName,
string $mainName,
float $price,
int $playLength
{

)

$this->title = $title;
$this->producerFirstName = $firstName;
$this->producerMainName = $mainName;
$this->price = $price;
$this->playLength = $playLength;
}

public function getPlayLength()
{

return $this->playLength;

}
public function getSummaryLine()
{

$base = "{$this->title} ( {$this->producerMainName},
$base .= "{$this->producerFirstName} )”;
$base . = ": Время звучания - {$this->playLength}";
return $base;

}
public function getProducer()
{

return $this->producerFirstName
. $this->producerMainName;

}

// Листинг 03.33

class BookProduct
{
public SnumPages;
public $title;
public $producerMainName;
public $producerFirstName;
public Sprice;

public function __ construct(
string $title,
string $firstName,
string SmainName,
float $price,
int $numPages

)

{

.

"

"

ГЛАВА 3 * ОСНОВНЫЕ ПОЛОЖЕНИЯ ОБ ОБЪЕКТАХ

69

$this->title = $title;
$this->producerFirstName = $firstName;
$this->producerMainName = $mainName;
$this->price = $price;
$this->numPages = $numPages;

}
public function getNumberOfPages()

{

return $this->numPages;
}
public function getSummaryLine()

{
$base = ”{$this->title} ( {$this->producerMainName},
$base .= ”{$this->producerFirstName} ) ";
$base .=
{$this->numPages} стр.";
return $base;

}
public function getProducer()

{
return $this->producerFirstName
. $this->producerMainName;

.

"

"

}
}

Мы постарались справиться с упомянутой выше сложностью, хотя для этого
пришлось кое-чем пожертвовать. Теперь метод getSummaryLine () можно со
здать для каждого вида товара, даже не проверяя значение специального при
знака. И ни один из приведенных выше классов больше не содержит поля или
методы, не имеющие к нему никакого отношения.
А жертва состояла в дублировании кода. Методы getProducer () абсолютно
одинаковы в обоих классах. Конструктор каждого из этих классов одинаково
устанавливает ряд сходных свойств. И это еще один признак дурного тона, ко
торого следует всячески избегать в программировании.
Если требуется, чтобы методы getProducer () действовали одинаково в ка
ждом классе, любые изменения, внесенные в одну реализацию, должны быть
внесены и в другую. Но так мы очень скоро нарушим согласованность обоих
классов.
Даже если мы уверены, что можем справиться с дублированием, на этом
наши хлопоты не закончатся. Ведь у нас теперь имеются два типа, а не один.
Вспомните класс ShopProductWriter. Его метод write () предназначен
для работы с одним типом ShopProduct. Как же исправить это положение,
чтобы все работало, как прежде? Мы можем удалить объявление типа класса из
сигнатуры метода, но тогда нам остается лишь надеяться, что методу write ()
будет передан объект правильного типа. Для проверки типа мы можем ввести в
тело метода собственный код, как показано ниже.

70

ЧАСТЬ II М ОБЪЕКТЫ

// Листинг 03.34

class ShopProductWriter
{
public function write($shopProduct)

{
(

if

!
!

)

($shopProduct instanceof CdProduct
)
($shopProduct instanceof BookProduct)

&&

{

die("Передан неверный тип данных ");
}
$str = "{$shopProduct->title}: "
$shopProduct->getProducer()
. " ({$shopProduct->price})\n";
print $str;
}
}

Обратите внимание, что в данном примере используется выражение с уча
стием оператора instanceof. Вместо него подставляется логическое значение
true, если объект, расположенный слева от оператора instanceof относится
к типу, указанному справа. И снова мы были вынуждены ввести новый уро
вень сложности. Ведь нам нужно не только проверять аргумент $ShopProduct
на соответствие двум типам в методе write (), но и надеяться, что в каждом
типе будут поддерживаться те же самые поля и методы, что и в другом. Согла
ситесь, что иметь дело только с одним типом было бы намного лучше. Ведь
тогда мы могли бы воспользоваться объявлением типа класса в аргументе ме
тода write () и были бы уверены, что в классе ShopProduct поддерживается
конкретный интерфейс.
Свойства класса ShopProduct, связанные с книгами и компакт-дисками, не
используются одновременно, но они, по-видимому, не могут существовать и по
отдельности. Нам нужно оперировать книгами и компакт-дисками как одним
типом данных, но в то же время обеспечить отдельную реализацию метода для
каждого формата вывода. Следовательно, нам нужно предоставить общие функ
циональные возможность в одном месте, чтобы избежать дублирования, но в то
же время сделать так, чтобы при вызове метода, выводящего краткие сведения
о товаре, учитывались особенности этого товара. Одним словом, нам придется
воспользоваться наследованием.

Использование наследования
Первый шаг в построении дерева наследования состоит в том, чтобы най
ти элементы базового класса, которые не соответствуют друг другу или тре
буют разного обращения с ними. Во-первых, нам известно, что методы
getPlayLength() и getNumberOf Pages () не могут находиться в одном клас
се. И во-вторых, нам известно, что потребуются разные реализации метода
getSummaryLine (). Мы воспользуемся этими отличиями в качестве основания
для создания двух производных классов.

ГЛАВА 3 ■ ОСНОВНЫЕ ПОЛОЖЕНИЯ ОБ ОБЪЕКТАХ
// Листинг 03.35
class ShopProduct
{
public $numPages;
public $playLength;
public $title;
public $producerMainName;
public $producerFirstName;
public $price;

public function __ construct(
string $title,
string $firstName,
string $mainName,
float $price,
int $numPages = 0,
int $playLength = 0
) {
$this->title = $title;
$this->producerFirstName = $firstName;
$this->producerMainName = $mainName;
$this->price = $price;
$this->numPages = $numPages;
$this->playLength = $playLength;
}

public function getProducer()
{
return $this->producerFirstName
. $this->producerMainName;

.

”

”

public function getSummaryLine()
{
$base
= ” { $this->title} ( { $this->producerMainName),
$base .= ” { $this->producerFirstName}
return $base;

// Листинг 03.36
class CdProduct extends ShopProduct
{
public function getPlayLength()
{
return $this->playLength;

public function getSummaryLine()
{
$base
= ’’ { $this->title} ( { $this->producerMainName},
Sbase .= ”{$this->producerFirstName} )";
$base .=
Время звучания - {$this->playLength}";
return $base;

71

72

ЧАСТЬ II Ш ОБЪЕКТЫ

// Листинг 03.37

class BookProduct extends ShopProduct
{
public function getNumberOfPages()
{
return $this->numPages;
}

public function getSummaryLine()
{
$base
= ”{$this->title} ( {$this->producerMainName},
$base .= "{$this->producerFirstName} )";
$base .=
{$this->numPages} стр.";
return $base;
}

";

}

Чтобы создать производный (или дочерний) класс, достаточно указать в его
объявлении ключевое слово extends. В данном примере мы создали два новых
класса — BookProduct и CDProduct. Оба они расширяют класс ShopProduct.
Поскольку в производных классах конструкторы не определяются, при полу
чении экземпляров этих классов будет автоматически вызываться конструктор
родительского класса. Дочерние классы наследуют доступ ко всем методам типа
public и protected из родительского класса, но не к методам и свойствам
типа private. Это означает, что метод getProducer () можно вызвать для соз
данного экземпляра класса CDProduct, как показано ниже, несмотря на то, что
данный метод определен в классе ShopProduct.
// Листинг 03.38
$product2 = new CdProduct(

"Классическая музыка.
"Антонио",
"Вивальди",
10.99,

Лучшее",

0,
60.33
) ;

print "Исполнитель:

{$product2->getProducer()}\п";

Таким образом, оба дочерних класса наследуют поведение общего родитель
ского класса. И мы можем обращаться с объектом типа CdProduct так, как
будто это объект типа ShopProduct. Мы можем также передать объект типа
BookProduct или CDProduct методу write () из класса ShopProductWriter,
и все будет работать как следует.
Обратите внимание на то, что для обеспечения собственной реализации в клас
сах CDProduct и BookProduct переопределяется метод getSummaryLine ().
Производные классы могут расширять и изменять функциональные возможности

ГЛАВА 3

ОСНОВНЫЕ ПОЛОЖЕНИЯ ОБ ОБЪЕКТАХ

73

родительских классов. И в то же время каждый класс наследует свойства роди
тельского класса.
Реализация метода getSummaryLine () в суперклассе может показаться из
быточной, поскольку этот метод переопределяется в обоих дочерних классах.
Тем не менее мы предоставляем базовый набор функциональных возможностей,
который можно будет использовать в любом новом дочернем классе. Наличие
этого метода в суперклассе гарантирует также для клиентского кода, что во всех
объектах типа ShopProduct будет присутствовать метод getSummaryLine ().
Далее будет показано, как выполнить это обязательство в базовом классе, во
обще не предоставляя никакой реализации. Каждый объект дочернего клас
са ShopProduct наследует все свойства своего родительского класса. В соб
ственных реализациях метода getSummaryLine () из классов CDProduct и
BookProduct обеспечивается доступ к свойству $title.
Усвоить понятие наследования сразу не так-то просто. Объявляя один класс,
расширяющий другой, мы гарантируем, что экземпляр его объекта определяет
ся характеристиками сначала дочернего, а затем родительского класса. Чтобы
лучше понять наследование, его удобнее рассматривать с точки зрения поиска.
Так, если сделать вызов $product2->getProducer (), интерпретатор РНР не
сможет найти указанный метод в классе CDProduct. Поиск завершится неу
дачно, и поэтому будет использована стандартная реализация данного метода
в классе ShopProduct. С другой стороны, когда делается вызов $product2>getSummaryLine (), интерпретатор РНР находит реализацию метода
getSummaryLine () в классе CDProduct и вызывает его.
Это же относится и к доступу к свойствам. При обращении к свойству
$title в методе getSummaryLine () из класса BookProduct интерпретатор
РНР не находит определение этого свойства в классе BookProduct и поэто
му использует определение данного свойства, заданное в родительском классе
ShopProduct. А поскольку свойство $title используется в обоих подклассах,
оно должно определяться в суперклассе.
Даже беглого взгляда на конструктор класса ShopProduct достаточно, что
бы понять, что в базовом классе по-прежнему выполняется обработка тех дан
ных, которыми должен оперировать дочерний класс. Так, конструктору класса
BookProduct должен передаваться аргумент $numPages, значение которого
устанавливается в одноименном свойстве, а конструктор класса CDProduct
должен обрабатывать аргумент $playLength и одноименное свойство. Чтобы
добиться этого, определим методы-конструкторы в каждом дочернем классе.
Конструкторы и наследование

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

74

ЧАСТЬ II

ОБЪЕКТЫ

Чтобы вызвать нужный метод из родительского класса, придется обратиться
непосредственно к этому классу через дескриптор. Для этой цели в РНР пред
усмотрено ключевое слово parent.
Чтобы обратиться к методу в контексте класса, а не объекта, следует исполь
зовать символы ”:
а не
Следовательно, синтаксическая конструкция
parent::__ construct () означает следующее: “Вызвать метод__ construct ()
из родительского класса”. Изменим рассматриваемый здесь пример таким обра
зом, чтобы каждый класс оперировал только теми данными, которые имеют к
нему непосредственное отношение.
// Листинг 03.39

class ShopProduct
{

public
public
public
public

$title;
$producerMainName;
$producerFirstName;
$price;

function __ construct(
$title,
$firstName,
$mainName,
$price
)

{

$this->title = $title;
$this->producerFirstName = $firstName;
$this->producerMainName = $mainName;
$this->price = $price;
}

function getProducer()
i

t

return $this->producerFirstName
$this->producerMainName;

.

"

"

}

function getSummaryLine()

$base = ”{$this->title} ( {$this->producerMainName},
$base .= "{$this->producerFirstName} )";
return $base;
}

// Листинг 03.40

class BookProduct extends ShopProduct

{
public $numPages;

”

ГЛАВА 3 а ОСНОВНЫЕ ПОЛОЖЕНИЯ ОБ ОБЪЕКТАХ

)

public function __ construct(
string $title,
string $firstName,
string $mainName,
float $price,
int $numPages
{
parent::__ construct(
$title,
$firstName,
SmainName,
$price

) ;
$this->numPages = $numPages;

public function getNumberOfPages()
{

return $this->numPages;

public function getSummaryLine ()
{
$base = "{$this->title} ( $this->producerMainName,
$base .= "$this->producerFirstName ) ";
$base .=
{$this->numPages} стр.";
return $base;

// Листинг 03.41
class CdProduct extends ShopProduct
{
public $playLength;

public function __ construct(
string $title,
string $firstName,
string $mainName,
float $price,
int $playLength

)

{

parent::__ construct(
$title,
$firstName,
$mainName,
$price

) ;
$this->playLength = $playLength;

public function getPlayLength ()
{
return $this->playLength;

”

75

76

ЧАСТЬ II ® ОБЪЕКТЫ

public function getSummaryLine()

{
$base = "{$this->title} ( {$this->producerMainName},
$base .= "{Sthis->producerFirstName} )”;
$base .= ”: Время звучания - {$this->playLength}”;
return $base;
}

}

В каждом дочернем классе перед определением его собственных свойств вы
зывается конструктор родительского класса. Теперь в базовом классе известны
только его собственные данные. Дочерние классы обычно являются специали
зированными вариантами родительских классов. Как правило, следует не до
пускать, чтобы в родительских классах было известно что-нибудь особенное о
дочерних классах.
НА ЗАМЕТКУ. До появления РНР 5 имя конструктора совпадало с именем того класса,

к которому он относился. В новом варианте обозначения конструкторов для едино
образия используется имя__ construct (). При использовании старого синтакси
са вызов конструктора из родительского класса был привязан к имени конкретного
класса, например: parent: :ShopProduct() А в версии РНР 7 старый синтаксис
вызова конструкторов признан устаревшим и больше не должен использоваться.
Вызов переопределяемого метода

Ключевое слово parent можно использовать в любом методе, переопределя
ющем свой эквивалент из родительского класса. Когда переопределяется метод,
то, вероятнее всего, требуется расширить, а не отменить функциональные воз
можности родительского класса. Достичь этого можно, вызвав метод из роди
тельского класса в контексте текущего объекта. Если снова проанализировать
реализации метода getSummaryLine (), то можно заметить, что значительная
часть кода в них дублируется. И лучше воспользоваться этим обстоятельством,
как показано ниже, чем повторять функциональные возможности, уже имеющи
еся в классе ShopProduct.
// Листинг 03.42
// Класс ShopProduct...

function getSummaryLine()
{
$base = ”{$this->title} ( {$this->producerMainName},
$base .= ”{$this->producerFirstName} )”;
return $base;

ГЛАВА 3 ж ОСНОВНЫЕ ПОЛОЖЕНИЯ ОБ ОБЪЕКТАХ

77

// Листинг 03.43

// Класс BookProduct...
public function getSummaryLine ()

{
$base = parent::getSummaryLine();
$base .=
{$this->numPages} стр.";
return $base;
}

Итак, мы определили основные функции для метода getSummaryLine () в
базовом классе ShopProduct. Вместо того чтобы повторять их в подклассах
CDProduct и BookProduct, мы просто вызовем родительский метод, прежде
чем вводить дополнительные данные в итоговую строку.
А теперь, когда были изложены основы наследования, можно, наконец, рас
смотреть область видимости свойств и методов, чтобы получить полную карти
ну происходящего.

Управление доступом к классам: модификаторы
public, private и protected
До сих пор мы явно или неявно объявляли все свойства как открытые
(public). Такой тип доступа задан по умолчанию для всех методов и свойств,
объявляемых с помощью устаревшего ключевого слова var.
Элементы класса можно объявить как public (открытые), private (закры
тые) или protected (защищенные). Это означает следующее.

$ К открытым свойствам и методам можно получать доступ из любого кон
текста.
« К закрытому свойству и методу можно получить доступ только из того
класса, в котором они объявлены. Даже подклассы данного класса не име
ют доступа к таким свойствам и методам.

К защищенным свойствам и методам можно получить доступ либо из со
держащего их класса, либо из его подкласса. Никакому внешнему коду
такой доступ не предоставляется.
Чем же это может быть нам полезным? Ключевые слова, определяющие об
ласть видимости, позволяют раскрыть только те элементы класса, которые тре
буются клиенту. Это дает возможность задать ясный и понятный интерфейс для
объекта.
Управление доступом, позволяющее запретить клиенту обращаться к неко
торым свойствам и методам класса, помогает также избежать ошибок в при
кладном коде. Допустим, требуется организовать поддержку скидок в объектах
типа ShopProduct. С этой целью можно ввести свойство $discount и метод
setDiscount () в данный класс, как показано ниже.

78

ЧАСТЬ II Я ОБЪЕКТЫ

// Листинг 03.44
// Класс ShopProduct...
public $discount = 0;

//. . .
public function setDiscount(int $num)
{

$this->discount = $num;

}

Имея на вооружении механизм определения скидки, мы можем создать метод
getPriceO, где во внимание принимается установленная скидка.
public function getPriceO

{
return

($this->price - $this->discount);

}

Но тут возникает затруднение. Нам требуется раскрыть только скорректи
рованную цену, но клиент может легко обойти метод getPrice () и получить
доступ к свойству $price следующим образом:
print ’’Цена товара -

{$productl->price}\п";

В итоге будет выведена исходная цена, а не цена со скидкой, которую нам
требуется представить. Чтобы избежать этого, достаточно сделать свойство
$price закрытым (private), тем самым запретив клиентам прямой доступ к
нему и вынуждая их вызывать метод getPriceO. Любая попытка получить
доступ к свойству $price вне класса ShopProduct завершится неудачно. И это
свойство перестанет существовать для внешнего мира.
Но объявление свойства как private может оказаться излишне строгой
мерой, ведь тогда дочерний класс не сможет получить доступ к закрытым
свойствам своего родительского класса. А теперь представьте следующие бизнес-правила: скидка не распространяется только на книги. В таком случае мож
но переопределить метод getPriceO, чтобы он возвращал свойство $price
без учета скидки:
// Листинг 03.45

// Класс BookProduct...
public function getPriceO

{
return $this->price;

ГЛАВА 3

ОСНОВНЫЕ ПОЛОЖЕНИЯ ОБ ОБЪЕКТАХ

79

Свойство $price объявлено в классе ShopProduct, а не в BookProduct, и
поэтому попытка в приведенном выше фрагменте кода получить доступ к этому
свойству завершится неудачно. Чтобы разрешить это затруднение, следует объ
явить свойство $price защищенным (protected) и тем самым предоставить
доступ к нему дочерним классам. Напомним, что к защищенным свойствам или
методам нельзя получить доступ за пределами иерархии того класса, в котором
они были объявлены. Доступ к ним можно получить только из исходного класса
или его дочерних классов.
Как правило, предпочтение следует отдавать конфиденциальности. Сначала
сделайте свойства закрытыми или защищенными, а затем ослабляйте ограниче
ния, накладываемые на доступ к ним, по мере надобности. Многие (если не все)
методы в ваших классах будут открытыми, но опять же, если у вас есть сомне
ния, ограничьте доступ. Метод, предоставляющий локальные функциональные
возможности другим методам в классе, вообще не нужен пользователям класса.
Поэтому сделайте его закрытым или защищенным.

Методы доступа
Даже если в клиентской программе потребуется обрабатывать значения,
хранящиеся в экземпляре вашего класса, как правило, стоит запретить прямой
доступ к свойствам данного объекта. Вместо этого создайте методы, которые
возвращают или устанавливают нужные значения. Такие методы называют ме
тодами доступа или методами получения и установки.
Ранее на примере метода getPricef) уже демонстрировалось одно преи
мущество, которое дают методы доступа: с их помощью можно фильтровать
значения свойств в зависимости от обстоятельств. Метод установки можно
также использовать для соблюдения типа свойства. Если объявления типов
классов накладывают определенные ограничения на аргументы методов, то
свойства могут содержать данные любого типа. Вспомните определение клас
са ShopProductWriter, где для вывода списка данных используется объект
типа ShopProduct? Попробуем пойти дальше и сделать так, чтобы в классе
ShopProductWriter можно было одновременно выводить данные из любого
количества объектов типа ShopProduct.
// Листинг 03.46

class ShopProductWriter
{
public $products = [];
public function addProduct(ShopProduct $shopProduct)
{
$this->products[] = $shopProduct;

80

ЧАСТЬ II

К

ОБЪЕКТЫ

public function write ()
{
$str =
foreach ($this->products as $ShopProduct) {
$str .= ’’ {$shopProduct->title} :
$str .= $shopProduct->getProducer();
$str .= ”({$shopProduct->getPrice()})\n";
}
print $str;
}
}

Теперь класс ShopProductWriter стал намного более полезным. Он может
содержать много объектов типа ShopProduct и сразу выводить информацию
обо всех этих объектах. Но мы все еще должны полагаться на то, что програм
мисты клиентского кода будут строго придерживаться правил работы с классом.
И хотя мы предоставили метод addProduct (), мы не запретили программи
стам непосредственно манипулировать свойством $products. В итоге можно
не только добавить объект неверного типа в массив свойств $products, но и
затереть весь массив и заменить его значением простого типа. Чтобы не допу
стить этого, нужно сделать свойство $products закрытым.
// Листинг 03.47
class ShopProductWriter {
private $products = [];
//. . .

Теперь внешний код не сможет повредить массив свойств $products. Весь
доступ к нему должен осуществляться через метод addProduct (), а объявле
ние типа класса, которое используется в объявлении этого метода, гарантирует,
что в массив свойств могут быть добавлены только объекты типа ShopProduct.

Семейство классов ShopProduct
И в заключение этой главы внесем коррективы в класс ShopProduct и его
дочерние классы таким образом, чтобы ограничить доступ к их элементам.
// Листинг 03.48
class ShopProduct
{
private $title;
private $producerMainName;
private $producerFirstName;
protected $price;
private $discount = 0;

public function __ construct(
string $title,
string $firstName,
string $mainName,
float $price
) {

ГЛАВА 3 » ОСНОВНЫЕ ПОЛОЖЕНИЯ ОБ ОБЪЕКТАХ
$this->title = $title;
$this->producerFirstName = $firstName;
$this->producerMainName = $mainName;
$this->price = $price;

public function getProducerFirstNameО
{
return $this->producerFirstName;

public function getProducerMainName()

{
return $this->producerMainName;

public function setDiscount($num)
{

$this->discount = $num;

public function getDiscount ()
{
return $this->discount;

public function getTitleO
{
return $this->title;

public function getPriceO

{
return

($this->price - $this->discount);

public function getProducer()
{
return $this->producerFirstName
. $this->producerMainName;

.

public function getSummaryLine()
{
$base = "{$this->title} ( {$this->producerMainName},
$base .= "{$this->producerFirstName} )”;
return $base;

// Листинг 03.49
class CdProduct extends ShopProduct
{
private $playLength;

"

81

82

ЧАСТЬ II » ОБЪЕКТЫ

public function __ construct(
string $title,
string $firstName,
string $mainName,
float $price,
int $playLength
) {
parent::__ construct(
$title,
$firstName,
$mainName,
$price
) ;
$this->playLength = $playLength;

public function getPlayLength()
{
return $this->playLength;

public function getSununaryLine()
{
$base = "{$this->title} ( {$this->producerMainName},
$base .= ”{$this->producerFirstName}
$base .=
Время звучания - {$this->playLength}";
return $base;

// Листинг 03.50

class BookProduct extends ShopProduct
{
private $numPages;

public function __ construct(
string $title,
string $firstName,
string $mainName,
float $price,
int $numPages
) {
parent::__ construct(
$title,
$firstName,
$mainName,
$price
) ;
$this->numPages = $numPages;

public function getNumberOfPages()
{
return $this->numPages;

ГЛАВА 3 ® ОСНОВНЫЕ ПОЛОЖЕНИЯ ОБ ОБЪЕКТАХ

83

public function getSummaryLine()

{
$base = parent::getSummaryLine();
$base .=
{$this->numPages} стр.";
return $base;
}

public function getPrice()
{
return $this->price;
}

}

В этой версии семейства классов ShopProduct нет ничего особенно нового.
Все свойства теперь стали закрытыми или защищенными. И для завершенности
этого семейства классов мы добавили в него ряд методов доступа.

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

ГЛАВА 4

Расширенные средства
В предыдущей главе вы ознакомились с объявлениями типов классов и
управлением доступом к свойствам и методам. Все это позволяет очень гибко
управлять интерфейсом класса. В настоящей главе мы подробно исследуем бо
лее развитые объектно-ориентированные возможности языка РНР.
В этой главе рассматриваются следующие вопросы.

$ Статические методы и свойства. Доступ к данным и функциям с помо
щью классов, а не объектов.
ш Постоянные свойства. Неизменяемая часть класса, или константы.
в Абстрактные классы и интерфейсы. Отделение проектного решения от
его реализации.
1 Трейты. Совместное использование реализации в иерархиях классов.

Позднее статическое связывание. Возможность, появившаяся в версии
РНР 5.3.

м Обработка ошибок. Общее представление об исключениях.
Завершенные классы и методы. Ограниченное наследование.

Методы-перехватчики. Автоматическая передача полномочий.
Методы-деструкторы. Освобождение ресурсов после использования объ
екта.
$ Клонирование объектов. Создание копий объектов.
® Преобразование объектов в символьные строки. Создание сводного ме
тода.

Функции обратного вызова. Расширение функциональных возможностей
компонентов с помощью анонимных функций и классов.

86

ЧАСТЬ II й ОБЪЕКТЫ

Статические методы и свойства
Во всех примерах из предыдущей главы мы работали с объектами. Классы
были охарактеризованы как шаблоны, с помощью которых создаются объекты,
а объекты — как активные компоненты, методы которых можно вызывать и
получать доступ к их свойствам. Из этого был сделан вывод, что вся реальная
работа в ООП выполняется в экземплярах классов. А классы в конечном счете
служат шаблонами для создания объектов.
Но на самом деле не все так просто. Доступ к методам и свойствам можно
получать в контексте класса, а не объекта. Такие методы и свойства являются
статическими и должны быть объявлены с помощью ключевого слова static,
как показано ниже.
// Листинг 04.01

class StaticExample
{
static public $aNum = 0;
public static function sayHelloQ

{
print ’’Здравствуй,

Мир!”;

}
}

Статические методы — это функции, применяемые в контексте класса. Они
не могут сами получать доступ к обычным свойствам класса, потому что такие
свойства относятся к объектам. Но из статических методов можно обращать
ся к статическим свойствам, И если изменить статическое свойство, то все
экземпляры данного класса смогут получить доступ к новому значению этого
свойства.
Доступ к статическому элементу осуществляется через класс, а не экземпляр
объекта, и поэтому не требуется переменная для ссылки на объект. Вместо этого
используется имя класса и два знака двоеточия ":: как в следующем примере
кода:
print StaticExample::$aNum;
StaticExample::sayHello();

Этот синтаксис был представлен в предыдущей главе. Мы использовали
синтаксическую конструкцию ”: : ” вместе с ключевым словом parent, что
бы получить доступ к переопределенному методу родительского класса. Но те
перь мы будем обращаться к классу, а не к данным, содержащимся в объекте.
Ключевое слово parent можно использовать в коде класса, чтобы получить
доступ к суперклассу, не употребляя имя класса. Чтобы получить доступ к
статическому методу или свойству из того же самого класса (а не из дочерне
го класса), воспользуемся ключевым словом self. Ключевое слово self слу
жит для обращения к текущему классу подобно тому, как псевдопеременная

ГЛАВА 4 а РАСШИРЕННЫЕ СРЕДСТВА

87

$this — к текущему объекту. Поэтому обращаться к свойству $aNum за преде
лами класса StaticExample следует по имени его класса, как показано ниже.
StaticExample::$aNum;

А в самом классе StaticExample для этой цели можно воспользоваться
ключевым словом self следующим образом:
// Листинг 04.02

class StaticExample

{
static public $aNum = 0;
public static function sayHello()

{
self::$aNum++;
print "Привет!

(. self: : $aNum. ") \n";

}

НА ЗАМЕТКУ. Вызов метода с помощью ключевого слова parent — это единственный

случай, когда следует использовать статическую ссылку на нестатический метод. Кро
ме случаев обращения к переопределенному методу родительского класса, синтак
сической конструкцией "::" следует пользоваться только для доступа к статическим
методам или свойствам.
Но в документации часто можно увидеть примеры применения синтаксической
конструкции ”: :" для ссылок на методы или свойства. Это совсем не означает,
что рассматриваемый элемент кода непременно является статическим, — просто
он относится к указанному классу. Например, ссылку на метод write () из клас
са ShopProductWriter можно сделать следующим образом: ShopProduct
Writer: :write(), несмотря на то, что метод write() не является статическим.
Мы будем пользоваться синтаксической конструкцией "::" в тех примерах из данной
книги, где это уместно.
По определению обращение к статическим методам и свойствам происходит
в контексте класса, а не объекта. Именно по этой причине статические свойства
и методы часто называют переменными и свойствами класса. Как следствие та
кой ориентации на класс — псевдопеременной $this нельзя пользоваться в
теле статического метода для доступа к элементам текущего объекта.
А зачем вообще нужны статические методы или свойства? Статические эле
менты имеют ряд полезных характеристик. Во-первых, они доступны из любого
места в сценарии, при условии, что имеется доступ к классу. Это означает, что
функции можно вызывать, не передавая экземпляр класса от одного объекта
другому или, что еще хуже, сохраняя ссылку на экземпляр объекта в глобальной
переменной. Во-вторых, статическое свойство доступно каждому экземпляру
объекта данного класса. Поэтому можно определить значения, которые должны
быть доступны всем объектам данного типа. И, наконец, благодаря тому, что

88

ЧАСТЬ II

ОБЪЕКТЫ

отпадает необходимость в наличии экземпляра класса для доступа к его стати
ческому свойству или методу, можно избежать создания экземпляров объектов
исключительно ради вызова простой функции.
Чтобы продемонстрировать все сказанное выше на конкретном примере, соз
дадим в классе ShopProduct статический метод для автоматического получе
ния экземпляров объектов типа ShopProduct на основании информации, хра
нящейся в базе данных. Определим таблицу products базы данных средствами
SQLite следующим образом:
CREATE TABLE products

(
id INTEGER
type
firstname
mainname
title
price
numpages
playlength
discount

PRIMARY KEY AUTOINCREMENT
TEXT,
TEXT,
TEXT,
TEXT,
float,
int,
int,
int

)

А теперь создадим метод getlnstance (), которому передаются иденти
фикатор строки и объект типа PDO. Они будут использоваться для извлечения
строки из таблицы базы данных, на основании которой затем формируется объ
ект типа ShopProduct, возвращаемый в вызывающую часть программы. Мы
можем ввести приведенные ниже методы в класс ShopProduct, который был
создан в предыдущей главе. Как вы, вероятно, знаете, сокращение PDO означает
РНР Data Object (Объекты данных РНР). А класс PDO обеспечивает универсаль
ный интерфейс для различных приложений баз данных.
// Листинг 04.03
// Класс ShopProduct...

private $id = 0;
// ...
public function setID(int $id)

{
$this->id = $id;
}

//

...

public static function getlnstance(
int $id, \PDO $pdo): ShopProduct
{

$stmt = $pdo->prepare(
"select * from products where id=?");
$result = $stmt->execute([$id] ) ;
$row = $stmt->fetch() ;

ГЛАВА 4 » РАСШИРЕННЫЕ СРЕДСТВА
if

}
if

}

}

(empty($row))
return null;

89

{

($row [ ’ type ’ ] == ’’book") {
$product = new BookProduct(
$row[’title’],
$row[’firstname’],
$ row[’mainname’],
(float) $row[’price'],
(int) $row[’numpages’]

) ;
elseif ($row[’type’] == "cd")
$product = new CdProduct(
$row[’title’],
$row[’firstname’],
$row[’mainname’],
(float) $row[’price’],
(int) $row[’playlength']

{

) ;
else {
$firstname =

(is_null($row[’firstname’]))
? "’’ : $ row [’firstname’] ;
$product = new ShopProduct(
$row[’title’],
$firstname,
$row[’mainname’],
(float) $row[’price’]

) ;
}
$product->setld((int) $row[’id’]);
$product->setDiscount((int) $row[’discount’]);
return $product;
}

Как видите, метод getlnstance() возвращает объект типа ShopProduct,
причем он достаточно развит логически, чтобы на основании значения поля
type создать объект с нужными характеристиками. В данном примере специ
ально опущена обработка ошибок, чтобы сделать его как можно более лаконич
ным. Так, в реально работающей версии такого кода нельзя слишком полагаться
на то, что переданный объект типа PDO был правильно инициализирован для
обращения к нужной базе данных. На самом деле объект типа PDO, вероятно,
следует заключить в оболочку класса, гарантирующего надлежащее поведение.
Подробнее об ООП применительно к базам данных речь пойдет в главе 13,
‘Шаблоны баз данных”.
Метод getlnstance () оказывается более пригодным в контексте класса,
чем в контексте объекта. Он позволяет легко преобразовать информацию из
базы данных в объект, не требуя отдельного объекта типа ShopProduct. В этом
методе вообще не используются методы или свойства экземпляра, и поэтому ни
что не мешает объявить его статическим. И тогда, имея в своем распоряжении
достоверный объект типа PDO, можно вызвать данный метод из любого места в
приложении, как показано ниже.

90

ЧАСТЬ II » ОБЪЕКТЫ

// Листинг 04.03а
$dsn = "sqlite:/".__ DIR__ ."/products.db";
$pdo = new \PDO($dsn, null, null);
$pdo->setAttribute(\PDO::ATTR_ERRMODE, \PDO::ERRMODE_EXCEPTION);
$obj = ShopProduct::getlnstance(1, $pdo);

Подобные методы работают, как “фабрики”, поскольку берут “сырье” (на
пример, информацию, полученную из строки таблицы базы данных или файла
конфигурации) и используют его для создания объектов. Термин фабрика отно
сится к коду, предназначенному для создания экземпляров объектов. Примеры
подобных “фабрик” еще не раз будут встречаться в последующих главах.
Безусловно, рассмотренный выше пример выявляет не меньше проблем, чем
демонстрирует решений. И хотя метод ShopProduct: :getlnstance () был
сделан доступным из любой части программы, не прибегая к получению экзем
пляра класса ShopProduct, при его определении потребовалось также, чтобы
объект типа PDO был передан из клиентского кода. А откуда его взять? И на
сколько допустимой считается норма практики, когда в родительском классе
известно все до мельчайших подробностей о его дочерних классах? Такая норма
практики, конечно, недопустима. Проблемы вроде, где взять набор ключевых
объектов программы и их значений и насколько одни классы должны быть ос
ведомлены о других классах, широко распространены в ООП. Различные под
ходы к формированию объектов будут рассмотрены в главе 9, “Формирование
объектов”.

Постоянные свойства
Некоторые свойства объектов не должны изменяться. Например, такие эле
менты, как коды ошибок или коды состояния программы, обычно задаются в
классах вручную. И хотя они должны быть общедоступными и статическими,
клиентский код не должен иметь возможности их изменять.
В языке РНР постоянные свойства можно определить в самом классе. Как
и глобальные константы, константы класса нельзя изменить после их опреде
ления. Постоянное свойство объявляется с помощью ключевого слова const.
В отличие от обычных свойств, перед именем постоянного свойства не ставится
знак доллара. Для них зачастую принято выбирать имена, состоящие только из
прописных букв, как в следующем примере:
// Листинг 04.04

class ShopProduct
{

const AVAILABLE
= 0;
const OUT_OF_STOCK - 1;
// ...

ГЛАВА 4

РАСШИРЕННЫЕ СРЕДСТВА

91

Постоянные свойства могут содержать только значения, относящиеся к про
стому типу. Константе нельзя присвоить объект. Как и к статическим свойствам,
доступ к постоянным свойствам осуществляется через класс, а не через экзем
пляр объекта. А поскольку константа определяется без знака доллара, то и при
обращении к ней не нужно указывать никакого специального знака перед ее
именем:
print ShopProduct::AVAILABLE;

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

Абстрактные классы
Экземпляр абстрактного класса нельзя получить. Вместо этого в нем опреде
ляется (и, возможно, частично реализуется) интерфейс для любого класса, кото
рый может его расширить.
Абстрактный класс определяется с помощью ключевого слова abstract. Пе
реопределим класс ShopProductWriter, который мы создали в предыдущей
главе, как абстрактный.
// Листинг 04.05
abstract class ShopProductWriter

{
protected $products =

[];

public function addProduct(ShopProduct $shopProduct)

{
$this->products[]

= $shopProduct;

}
}

В абстрактном классе можно создавать методы и свойства, как обычно, но
любая попытка получить его экземпляр приведет к ошибке. Например, выпол
нение следующей строки кода:
$writer = new ShopProductWriter();

приведет к выводу такого сообщения об ошибке:
Error: Cannot instantiate abstract class ShopProductWriter ..J

1 Ошибка в PHP: нельзя получить экземпляр абстрактного класса
Writer...

ShopProduct

92

ЧАСТЬ II В ОБЪЕКТЫ

Как правило, в абстрактном классе должен содержаться по меньшей мере
один абстрактный метод. Как и абстрактный класс, он объявляется с помощью
ключевого слова abstract. Абстрактный метод не может быть реализован в аб
страктном классе. Он объявляется как обычный метод, но объявление заверша
ется точкой с запятой, а не телом метода. Добавим абстрактный метод write ()
в класс ShopProductWriter следующим образом:
abstract class ShopProductWriter
{
protected $products = [];
public function addProduct(ShopProduct $shopProduct)
{
$this->products[]=$ShopProduct;
}

abstract public function write();

}

Создавая абстрактный метод, вы гарантируете, что его реализация будет до
ступной во всех конкретных дочерних классах, но подробности этой реализации
остаются неопределенными.
Если попытаться следующим образом создать класс, производный от
ShopProductWriter, где метод write () не реализован:
class ErroredWriter extends ShopProductWriter{},

то появится такое сообщение об ошибке:
РНР Fatal error: Class ErroredWriter contains 1 abstract method and
must therefore be declared abstract or implement the remaining methods
(ShopProductWriter::write) in.. .2

Таким образом, в любом классе, расширяющем абстрактный класс, долж
ны быть реализованы все абстрактные методы или же сам класс должен быть
объявлен абстрактным. Расширяющий класс отвечает не только за реализацию
всех абстрактных методов, но и за соответствие их сигнатур. Это означает, что
уровень доступа в реализующем методе не может быть более строгим, чем в
абстрактном методе. Кроме того, реализующему методу должно передаваться
такое же количество аргументов, как и абстрактному методу, и в нем должны
совпадать все объявления типов классов.
Ниже приведены две реализации абстрактного класса ShopProductWriter.

2 Неустранимая ошибка в РНР: класс ErroredWriter содержит один абстрактный ме
тод, поэтому его следует объявить как абстрактный или реализовать остальные методы
(ShopProductWriter: :write) в...

ГЛАВА 4 а РАСШИРЕННЫЕ СРЕДСТВА

93

// Листинг 04.06

class XmlProductWriter extends ShopProductWriter
{

public function write()
{

$writer = new \XMLWriter();
$writer->openMemory();
$writer->startDocument('1.0', 'UTF-8');
$writer->startElement("products");
foreach ($this->products as $shopProduct) {
$writer->startElement("product");
$writer->writeAttribute("title", $shopProduct->getTitle());
$writer->startElement("summary");
$writer->text($shopProduct->getSummaryLine() ) ;
$writer->endElement(); // "summary"
$writer->endElement(); // "product"
}
$writer->endElement(); // "products"
$writer->endDocument();
print $writer->flush();
}

}
// Листинг 04.07

class TextProductWriter extends ShopProductWriter

{
public function write()

{

$str = "ТОВАРЫ:\n";
foreach ($this->products as $shopProduct) {
$str .= $shopProduct->getSummaryLine()."\n";
}
print $str;

}
}

Здесь созданы два класса, причем каждый с собственной реализацией метода
write (). Первый класс служит для вывода сведений о товаре в формате XML,
а второй — в текстовом виде. Теперь в методе, которому требуется передать
объект типа ShopProductWriter, не имеет особого значения, объект какого из
этих двух классов он получит, но в то же время имеется полная уверенность,
что в обоих классах реализован метод write (). Обратите внимание на то, что
тип свойства $products не проверяется, прежде чем использовать его как мас
сив. Дело в том, что это свойство инициализируется как пустой массив в классе
ShopProductWriter.

Интерфейсы
Как известно, в абстрактном классе допускается реализация некоторых ме
тодов, не объявленных абстрактными. В отличие от них, интерфейсы — это

94

ЧАСТЬ II

ОБЪЕКТЫ

чистые шаблоны. С помощью интерфейса можно только определить функцио
нальность, но не реализовать ее. Для объявления интерфейса используется клю
чевое слово interface. В интерфейсе могут находиться только объявления, но
не тела методов.
Ниже приведен пример объявления интерфейса.
// Листинг 04.08
interface Chargeable

{
public function getPriceO:

float;

}

Как видите, интерфейс очень похож на абстрактный класс. В любом классе,
поддерживающем этот интерфейс, необходимо реализовать все определенные в
нем методы. В противном случае класс должен быть объявлен как абстрактный.
При реализации интерфейса в классе имя интерфейса указывается в объяв
лении этого класса после ключевого слова implements. После этого процесс
реализации интерфейса станет точно таким же, как и расширение абстрактного
класса, который содержит только абстрактные методы. А теперь сделаем так,
чтобы в классе ShopProduct был реализован интерфейс Chargeable.
// Листинг 04.09

class ShopProduct implements Chargeable
{

// ...
protected $price;
// ...
public function getPriceO:

float

{

return $this->price;

}
//

...

}

В классе ShopProduct уже имеется метод getPriceO, так что же может
быть полезного в реализации интерфейса Chargeable? И в этом случае ответ
следует искать в типах данных. Дело в том, что реализующий класс принима
ет тип класса и интерфейса, который он расширяет. Это означает, что класс
CDProduct теперь будет относиться к следующим типам:
CDProduct
ShopProduct
Chargeable

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

ГЛАВА 4 » РАСШИРЕННЫЕ СРЕДСТВА

95

public function CDInfо( CDProduct $prod )

//

...

}

известно, что у объекта $prod имеется метод getPlayLength (), а также
все остальные методы, определенные в классе ShopProduct и интерфейсе
Chargeable.
Если тот же самый объект типа CDProduct передается следующему методу:
public function addProduct(

ShopProduct $prod )

{

//

..

}

то известно, что в объекте $prod поддерживаются все методы, определенные в
классе ShopProduct. Но без дополнительной проверки в данном методе ничего
не будет известно о методе getPlayLength (),
И снова, если передать тот же самый объект типа CDProduct следующему
методу:
public function addChargeableltem( Chargeable $item )

{
//. . .
}

то ему ничего не будет известно обо всех методах, определенных в классе
ShopProduct или CDProduct. Но данный метод интересует лишь, поддержи
вается ли в аргументе $item метод getPrice ().
Интерфейс можно реализовать в любом классе (на самом деле в классе мож
но реализовать любое количество интерфейсов), поэтому с помощью интерфей
сов можно эффективно объединить типы данных, не связанных никакими дру
гими отношениями. В итоге мы можем определить совершенно новый класс, в
котором реализуется интерфейс Chargeable.
class Shipping implements Chargeable
{
public function getPrice():

float

{

//. . .
}
}

Теперь объект типа Shipping можно передать методу addChargeableltem ()
таким же образом, как и объект типа ShopProduct. Для клиента, оперирую
щего объектом типа Chargeable, очень важно, что он может вызвать метод
getPrice (). Любые другие имеющиеся методы связаны с иными типами, будь
то через собственный класс объекта, суперкласс или другой интерфейс. Но они
не имеют никакого отношения к клиенту.

96

ЧАСТЬ II ж ОБЪЕКТЫ

В классе можно не только расширить суперкласс, но и реализовать любое
количество интерфейсов. При этом ключевое слово extends должно предше
ствовать ключевому слову implements:
class Consultancy extends TimedService implements Bookable,

Chargeable

{

// ...
}

Обратите внимание на то, что в классе Consultancy реализуются два ин
терфейса, а не один. После ключевого слова implements можно перечислить
через запятую несколько интерфейсов. В языке РНР поддерживается только на
следование от одного родителя (так называемое одиночное, или простое, насле
дование), поэтому после ключевого слова extends можно указать только одно
имя базового класса.

Трейты
В отличие от языка C++, в РНР, как и в языке Java, не поддерживается мно
жественное наследование. Но эту проблему можно частично решить с помощью
интерфейсов, как было показано в предыдущем разделе. Иными словами, для
каждого класса в РНР может существовать только один родительский класс. Тем
не менее в каждом классе можно реализовать произвольное количество интер
фейсов. При этом данный класс будет принимать типы всех тех интерфейсов,
которые в нем реализованы.
Как видите, с помощью интерфейсов создаются новые типы объектов без их
реализации. Но что делать, если требуется реализовать ряд общих методов для
всей иерархии наследования классов? Для этой цели в версии РНР 5.4 было
введено понятие трейтов\
По существу, трейты напоминают классы, экземпляры которых нельзя полу
чить, но их можно включить в другие классы. Поэтому любое свойство (или ме
тод), определенное в трейте, становится частью того класса, в который включен
этот трейт. При этом трейт изменяет структуру данного класса, но не меняет его
тип. Трейты можно считать своего рода включениями в классы. Рассмотрим на
конкретных примерах, насколько полезными могут быть трейты.

Проблема, которую позволяют решить трейты
Ниже приведена версия класса ShopProduct, в который был введен метод
calculateTax().
3 От англ, trait (особенность, характерная черта), но в литературе это понятие обознача
ется термином типаж, или просто трейт. Здесь и далее употребляется термин трейт. тем
более что к моменту издания данной книги он уже был официально принят в русскоязычном
сообществе разработчиков приложений на РНР. — Примеч. ред.

ГЛАВА 4 * РАСШИРЕННЫЕ СРЕДСТВА

97

// Листинг 04.10

class ShopProduct

{
private $taxrate = 17;

//

...

public function calculateTax(float $price):

float

{
return

( ($this->taxrate / 100)

* $price);

}
}

// Листинг 04.11
$p = new ShopProduct("Нежное мыло",
"Ванная Боба",
print $p->calculateTax(100) . "\n";

"",
1.33);

Методу calculateTax () в качестве параметра $price передается цена това
ра, и он вычисляет налог с продаж на основании ставки, величина которой хра
нится во внутреннем свойстве $taxrate. Безусловно, метод calculateTax ()
будет доступен всем подклассам данного класса. Но что, если дело дойдет до
совершенно других иерархий классов? Представьте класс Utilityservice,
унаследованный от другого класса Service. Если в классе Utilityservice
потребуется определить величину налога по точно такой же формуле, то
нам не остается ничего другого, как полностью скопировать тело метода
calculateTax().
// Листинг 04.11а
abstract class Service
{

// Базовый класс для службы

}

class UtilityService extends Service
{
private $taxrate = 17;
function calculateTax(float $price): float
{
return ( ( $this->taxrate/100 ) * $price );

}
}

$u = new UtilityService();
print $u->calculateTax(100)."\n";

98

ЧАСТЬ II ж ОБЪЕКТЫ

Определение и применение трейтов
Одной из целей объектно-ориентированного проектирования, которая крас
ной нитью проходит через всю эту книгу, является устранение проблемы дубли
рования кода. Как будет показано в главе 11, “Выполнение задач и представле
ние результатов”, одним из возможных путей решения этой проблемы является
вынесение общих фрагментов кода в отдельные повторно используемые гло
бальные классы. Трейты также позволяют решить данную проблему, хотя и ме
нее изящно, но, без сомнения, эффективно.
В приведенном ниже примере кода сначала объявляется простой трейт, со
держащий метод calculateTax (), а затем этот трейт включается в оба класса:
ShopProduct и Utilityservice.
// Листинг 04.12

trait Priceutilities
{
private $taxrate = 17;

public function calculateTax(float $price):
{
return ( ($this->taxrate / 100) * $price);
}
// Другие служебные методы

}

// Листинг 04.13
class ShopProduct
{
use Priceutilities;
}

// Листинг 04.14
abstract class Service
{
// Базовый класс для службы
}
// Листинг 04.15

class Utilityservice extends Service
{
use Priceutilities;
}
// Листинг 04.16

$p = new ShopProduct();
print $p->calculateTax(100)

.

"\n";

$u = new UtilityService();
print $u->calculateTax(100)

.

”\n";

float

ГЛАВА 4 ® РАСШИРЕННЫЕ СРЕДСТВА

99

Как видите, трейт Priceutilities объявляется с помощью ключевого сло
ва trait. Тело трейта весьма напоминает тело обычного класса, где в фигур
ных скобках просто указывается ряд методов (или свойств, как будет показано
ниже). Как только трейт Priceutilities будет объявлен, им можно пользо
ваться в собственных классах. Для этой цели служит ключевое слово use, по
сле которого указывается имя трейта. Итак, объявив и реализовав в одном ме
сте метод calculateTax (), им можно далее воспользоваться в обоих классах:
ShopProduct и Utilityservice.

Применение нескольких трейтов
В класс можно включить несколько трейтов, перечислив их через запятую по
сле ключевого слова use. В приведенном ниже примере кода сначала определя
ется, а затем используется новый трейт IdentityTrait в классе ShopProduct
наряду с трейтом Priceutilities.
// Листинг 04.17
trait IdentityTrait
{
public function generateld():
{
return uniqidO;
}
}

string

// Листинг 04.18
class ShopProduct
{
use Priceutilities,
}

IdentityTrait;

// Листинг 04.19
$p = new ShopProduct ();
print $p->calculateTax(100) . "\n”;
print $p->generateld() . "\n”;

Перечислив оба трейта, Priceutilities и IdentityTrait, после ключево
го слова use, мы сделали методы calculateTax () и generateld () доступны
ми для класса ShopProduct. Это означает, что эти методы становятся членами
класса ShopProduct.
НА ЗАМЕТКУ. В трейте IdentityTrait реализован метод generateld (). В действи

тельности однозначные значения идентификаторов объектов часто извлекаются из
базы данных, но в целях тестирования иногда требуется использовать их локальные
реализации. Более подробно об объектах, базах данных и однозначных идентифика
торах речь пойдет в главе 12, “Шаблоны корпоративных приложений”, где описыва
ется шаблон identity Мар, а о тестировании и имитации функциональных возмож
ностей объектов — в главе 18, “Тестирование средствами PHPUnit”.

100

ЧАСТЬ II w ОБЪЕКТЫ

Сочетание трейтов с интерфейсами
Несмотря на то что польза от трейтов не вызывает особых сомнений, они
не позволяют изменить тип класса, в который они включены. Так, если трейт
IdentityTrait используется сразу в нескольких классах, у них все равно не
будет общего типа, который можно было бы указать в сигнатурах методов.
Правда, трейты можно удачно сочетать с интерфейсами. В частности, сначала
можно определить интерфейс с сигнатурой метода generateld (), а затем объ
явить, что в классе ShopProduct реализуются методы этого интерфейса:
// Листинг 04.20

interface Identityobject
{
public function generateld():
}

string;

// Листинг 04.21

trait IdentityTrait
{
public function generateld():
{
return uniqidO;
}
}

string

// Листинг 04.22

class ShopProduct implements Identityobject
{
use Priceutilities, IdentityTrait;
}

Здесь, как и в предыдущем примере, в классе ShopProduct используется
трейт IdentityTrait. Но импортируемый с его помощью метод generateld ()
теперь удовлетворяет также требованиям интерфейса Identityobject.
А это означает, что объекты типа ShopProduct можно передавать тем мето
дам и функциям, в описании аргументов которых указывается тип интерфейса
Identityobject:
// Листинг 04.23

public static function storeldentityObject(
Identityobject $idobj)
{
// сделать что-нибудь с экземпляром типа Identityobject
}
// Листинг 04.24

$р = new ShopProduct();
self::storeldentityObject($p) ;
print $p->calculateTax(100) . "\n";
print $p->generateld() . "\n";

ГЛАВА 4 ж РАСШИРЕННЫЕ СРЕДСТВА

101

Устранение конфликтов имен методов
с помощью ключевого слова insteadof
Безусловно, сочетать трейты с интерфейсами замечательно, но рано или
поздно может возникнуть конфликт имен. Что, например, произойдет, если в
обоих включаемых трейтах будет реализован метод calculateTax (), как по
казано ниже?
// Листинг 04.25
trait TaxTools
{
function calculateTax(float $price):

float

{

return 222;
}
}

// Листинг 04.26
trait Priceutilities

{
private $taxrate = 17;

public function calculateTax(float $price):

float

{

return

(($this->taxrate / 100)

*

$price);

}
// другие служебные методы
}

// Листинг 04.27
class Utilityservice extends Service
{
use Priceutilities, TaxTools;

}

// Листинг 04.28
$u = new Utilityservice ();
print $u->calculateTax(100)

.

”\n";

В связи с тем что в один класс были включены два трейта, содержащие ме
тоды calculateTax (), интерпретатор РНР не сможет продолжить работу, по
скольку он не в состоянии определить, какой из методов переопределяет другой
метод. В итоге выводится следующее сообщение о неустранимой ошибке:
Error: Trait method calculateTax has not been applied, because there are
collisions with other trait methods on Utilityservice in...4
4 Неустранимая ошибка в PHP: метод трейта calculateTax () не может быть использо
ван из-за конфликта имен в другом трейте Utilityservice в ...

102

ЧАСТЬ II а ОБЪЕКТЫ

Для устранения подобного конфликта служит ключевое слово insteadof:
// Листинг 04.29

class Utilityservice extends Service
{

use Priceutilities, TaxTools {
TaxTools::calculateTax insteadof Priceutilities;
}
}
// Листинг 04.30

$u = new UtilityService();
print $u->calculateTax(100)

.

"\n";

Чтобы применять директивы с оператором use, необходимо дополнить их
блоком кода в фигурных скобках, где употребляется ключевое слово insteadof.
Слева от этого ключевого слова указывается полностью определенное имя ме
тода, состоящее из имени трейта и метода. Оба имени разделяются двумя двое
точиями, играющими в данном случае роль операции для определения области
видимости. А справа от ключевого слова insteadof указывается имя трейта,
метод которого с аналогичным именем должен быть заменен. Таким образом,
конструкция
TaxTools::calculateTax insteadof Priceutilities;

означает, что метод calculateTax () из трейта TaxTools следует использо
вать вместо одноименного метода из трейта Priceutilities.
Поэтому в результате выполнения приведенного выше кода будет выведено
число 222, жестко закодированное в теле метода TaxTools: : calculateTax ().

Назначение псевдонимов переопределенным
методам трейта
Как было показано выше, с помощью ключевого слова insteadof можно
устранить конфликт имен методов, принадлежащих разным трейтам. Но что,
если понадобится вызвать переопределяемый метод трейта? Для этой цели
служит ключевое слово as, которое позволяет назначить вызываемому мето
ду псевдоним. Как и в конструкции с ключевым словом insteadof, слева от
ключевого слова as следует указать полностью определенное имя метода, а
справа — псевдоним имени метода. В приведенном ниже примере кода метод
calculateTax () из трейта Priceutilities восстановлен под новым именем
basicTax().
// Листинг 04.31

class UtilityService extends Service
{
use Priceutilities, TaxTools {

ГЛАВА 4 » РАСШИРЕННЫЕ СРЕДСТВА

103

TaxTools::calculateTax insteadof Priceutilities;
Priceutilities::calculateTax as basicTax;
}

}
// Листинг 04.32

$u = new UtilityService();
print $u->calculateTax(100) . ”\n”;
print $u->basicTax(100) . "\n";

Выполнение данного фрагмента кода приведет к следующему результату:
222
17

Таким образом, метод из трейта Priceutilities: :calculateTax () стал
частью класса UtilityService под именем basicTax ().
НА ЗАМЕТКУ. При возникновении конфликта имен между методами разных трейтов не

достаточно просто назначить одному из методов псевдоним в блоке use. Сначала вы
должны решить, какой из методов должен быть замещен, и указать это с помощью
ключевого слова insteadof. Затем замещенному методу можно назначить псевдо
ним с помощью ключевого слова as и восстановить его в классе под новым именем.
Здесь уместно отметить, что псевдонимы имен методов можно использовать
даже в отсутствие конфликта имен. Так, с помощью метода трейта можно реа
лизовать абстрактный метод с сигнатурой, объявленной в родительском классе
или интерфейсе.

Применение статических методов в трейтах
В большинстве рассмотренных до сих пор примеров применялись статиче
ские методы, поскольку для их вызова не требуются экземпляры класса. Поэ
тому ничто не мешает ввести статический метод в трейт. В приведенном ниже
примере кода объявление свойства Priceutilities:: $taxrate и метода
Priceutilities: : calculateTax () было изменено таким образом, чтобы они
стали статическими.
// Листинг 04.33
trait Priceutilities

{
private static $taxrate = 17;

public static function calculateTax(float $price):
{

return

( (self::$taxrate /

100)

*

$price);

float

104

ЧАСТЬ II ® ОБЪЕКТЫ

// другие служебные методы
}

// Листинг 04.34
class Utilityservice extends Service
{

use Priceutilities;
}

// Листинг 04.35
$u = new Utilityservice();
print $u::calculateTax(100)

.

"\n";

Как и следовало ожидать, в результате выполнения этого фрагмента кода
будет выведено число 17. Таким образом, статические методы, объявленные в
трейтах, оказываются доступными обычным образом из базового класса.

Доступ к свойствам базового класса
После рассмотрения приведенных выше примеров у вас могло сложиться
впечатление, что для работы с трейтами подходят только статические методы.
И даже те методы трейта, которые не описаны как статические, по существу
являются статическими, не так ли? На самом деле нет, поскольку доступными
оказываются также свойства и методы базового класса:
// Листинг 04.36

trait Priceutilities
{

function calculateTax(float $price):

float

{
// Удачно ли такое проектное решение?
return ( ($this->taxrate / 100) * $price);

}

// другие служебные методы
}

// Листинг 04.37
class Utilityservice extends Service
{

public $taxrate = 17;

use Priceutilities;
}

// Листинг 04.38
$u = new Utilityservice();
print $u->calculateTax(100)

.

"\n";

ГЛАВА 4 'Ж РАСШИРЕННЫЕ СРЕДСТВА

105

В приведенном выше фрагменте кода трейт Priceutilities был откоррек
тирован таким образом, чтобы из него можно было обращаться к свойству базо
вого класса. И если такое проектное решение покажется вам неудачным, то вы
будете совершенно правы. Скажем больше: оно крайне неудачно! Несмотря на
то что обращение из трейтов к данным, находящимся в базовом классе, является
обычной практикой, объявлять свойство $taxrate в классе UtilityService
не было никаких веских оснований. Ведь не стоит забывать, что трейты могут
использоваться во многих совершенно разных классах. И кто может дать га
рантию (или даже обещание!), что в каждом базовом классе будет объявлено
свойство $taxrate?
С другой стороны, было бы неплохо заключить следующий контракт: “Если
вы пользуетесь данным трейтом, то обязаны предоставить в его распоряжение
определенные ресурсы”. На самом деле достичь такого же результата можно
благодаря тому, что в трейтах поддерживаются абстрактные методы.

Определение абстрактных методов в трейтах
Абстрактные методы можно объявлять в трейтах таким же образом, как и в
обычных классах. Чтобы воспользоваться таким трейтом в классе, в нем сле
дует реализовать все объявленные в трейте абстрактные методы. Принимая все
это во внимание, предыдущий пример можно переписать таким образом, чтобы
трейт вынуждал использующий его класс предоставлять сведения о ставке на
лога.
// Листинг 04.39
trait Priceutilities
function calculateTax(float $price):

float

t

// Более удачное проектное решение,
// известно, что метод getTaxRate()
return (($this->getTaxRate() / 100)

abstract function getTaxRate():
// другие служебные методы

float;

// Листинг 04.40
class UtilityService extends Service
{

use Priceutilities;

public function getTaxRate():
{

return 17;

float

поскольку
должен быть реализован
* $price);

106

ЧАСТЬ II « ОБЪЕКТЫ

// Листинг 04.41
$u = new Utilityservice();
print $u->calculateTax (100)

.

"\п”;

Объявив абстрактный метод getTaxRateO в трейте Priceutilities,
мы вынудили программиста клиентского кода обеспечить его реализацию в
классе Utilityservice. Разумеется, нет полной уверенности, что в методе
Utilityservice: :calculateTax () будет получено корректное значение из
метода getTaxRate (), поскольку в РНР не накладывается никаких жестких
ограничений на тип возвращаемого значения. Это препятствие можно в какой-то
степени преодолеть, введя в прикладной код всевозможные виды проверок, но
самое главное все равно будет упущено. В данном случае, вероятнее всего, бу
дет достаточно указать программисту клиентского кода, что при реализации за
требованных методов необходимо возвратить значение заданного типа.

Изменение прав доступа к методам трейта
Безусловно, ничто не может помешать вам объявить методы трейта откры
тыми (public), защищенными (private) или закрытыми (protected). Но вы
можете изменить эти модификаторы доступа к методам и непосредственно в
том классе, где используется трейт. Как было показано выше, методу можно
назначить псевдоним с помощью ключевого слова as. Если справа от этого клю
чевого слова указать новый модификатор доступа, то вместо назначения псевдо
нима будет изменен уровень доступа к методу.
Допустим, что метод calculateTax () требуется использовать только в са
мом классе Utilityservice и запретить вызов этого метода из клиентского
кода. Ниже показано, какие изменения следует внести для этого в оператор use.
// Листинг 04.42
trait Priceutilities

{

public function calculateTax(float $price): float
{
return (($this->getTaxRate() / 100) ★ $price);
}

public abstract function getTaxRateO:
// другие служебные методы

float;

}
// Листинг 04.43

class Utilityservice extends Service
{

use Priceutilities {
Priceutilities::calculateTax as private;
}

ГЛАВА 4 И РАСШИРЕННЫЕ СРЕДСТВА

107

private $price;
public function __ construct(float $price)

{
$this->price = $price;
}

public function getTaxRate():

float

{

return 17;
}

public function getFinalPrice():

float

{
return

($this->price + $this->calculateTax($this->price));

}
}

/ / Листинг 04.44

$u = new UtilityService(100);
print $u->getFinalPrice() . ”\n";

Чтобы запретить доступ к методу calculateTax () за пределами класса
UtilityService, после ключевого слова as в операторе use был указан моди
фикатор private. В итоге доступ к этому методу стал возможен только из мето
да getFinalPrice (). Если теперь попытаться вызвать метод calculateTax ()
за пределами его класса, например, следующим образом:
u = new UtilityService( 100 );
print $u->calculateTax () .”\n”;

то, как и ожидалось, будет выведено следующее сообщение об ошибке:
Error: Call to private method UtilityService::calculateTax() from context...5

Позднее статическое связывание:
ключевое слово static
А теперь, после того как были рассмотрены абстрактные классы, трейты и
интерфейсы, самое время снова вернуться ненадолго к статическим методам.
Как вам, должно быть, уже известно, статический метод можно использовать
в качестве фабричного для создания экземпляров того класса, в котором со
держится данный метод. Если читатель такой же ленивый программист, как и
автор данной книги, то его должно раздражать дублирование кода, аналогичное
приведенному ниже.

5 Ошибка: вызов закрытого метода UtilityService: : calculateTax () из контекста...

108

ЧАСТЬ II ® ОБЪЕКТЫ

// Листинг 04.45

abstract class Domainobject
{
}

// Листинг 04.46
class User extends Domainobject
{
public static function create () :

User

{

return new User();

}

// Листинг 04.47

class Document extends Domainobject
{
public static function create(): Document
{

return new Document();
}

}

Сначала в данном примере кода был создан суперкласс под именем
Domainobject. Само собой разумеется, что в реальном проекте в нем будут
доступны функциональные возможности, общие для всех дочернихклассов.
После этого были созданы два дочерних класса, User и Document, и было бы
желательно, чтобы в каждом из них имелся статический метод create ().
НА ЗАМЕТКУ. Почему для создания конкретного объекта был использован статический

фабричный метод, а не операция new и конструктор объекта? В главе 12, “Шаблоны
корпоративных приложений”, приведено описание шаблона identity Мар. Компо
нент identity Мар создает и инициализирует новый объект только в том случае,
если объект с аналогичными отличительными особенностями еще не создан. Если же
такой объект существует, то возвращается ссылка на него. Статический фабричный
метод вроде create () является отличным кандидатом для реализации подобной
функциональности.

Приведенный выше код вполне работоспособен, но ему присущ досадный
недостаток — дублирование. Вряд ли кому-то понравится повторять такой сте
реотипный код для создания каждый раз объекта класса, производного от класса
Domainobject. Вместо этого можно попытаться переместить метод create ()
в суперкласс:
// Листинг 04.48
abstract class Domainobject
{

ГЛАВА 4 а РАСШИРЕННЫЕ СРЕДСТВА
public static function create ():

109

Domainobject

{
return new self();

}
}
// Листинг 04.49

class User extends Domainobject
{
}

// Листинг 04.50

class Document extends Domainobject

{
}

// Листинг 04.51
Document::create();

Так-то лучше! Теперь весь общий код сосредоточен в одном месте, а для об
ращения к текущему классу было использовано ключевое слово self. Однако
насчет ключевого слова self было сделано неверное предположение, что оно
должно так работать. На самом деле оно не работает для классов так же, как
псевдопеременная $this для объектов. С помощью ключевого слова self нельзя
обратиться к контексту вызванного класса. Оно используется только для ссылок
на класс, в контексте которого вызывается метод. Поэтому при попытке запуска
приведенного выше примера получим следующее сообщение об ошибке.
Error: Cannot instantiate abstract class Domainobject6

Таким образом, ссылка self преобразуется в ссылку на класс Domainobject,
где определен метод create (), а не на класс Document, для которого этот ме
тод должен быть вызван. До версии 5.3 это было серьезным ограничением язы
ка РНР, которое породило массу неуклюжих обходных решений. А в версии РНР
5.3 было впервые введено понятие позднего статического связывания. Самым
заметным его проявлением является введение нового (в данном контексте) клю
чевого слова static. Оно аналогично ключевому слову self, за исключением
того, что оно относится к вызывающему. а не содержащему классу. В данном
случае это означает, что в результате вызова метода Document: : create () воз
вращается новый объект типа Document и не будет предпринята безуспешная
попытка создать объект типа Domainobject.
Итак, воспользуемся всеми преимуществами наследования в статическом
контексте следующим образом:

6 Ошибка: нельзя создать экземпляр абстрактного класса Domainobject.

110

ЧАСТЬ II « ОБЪЕКТЫ

abstract class Domainobject

{
public static function create () :

Domainobject

{

return new static();

}
}

class User extends Domainobject
{
}

class Document extends Domainobject

{
}
print_r(Document::create() ) ;

В результате выполнения приведенного выше кода будет выведено следующее:
Document Object
(
)

Ключевое слово static можно использовать не только для создания объ
ектов. Подобно ключевым словам self и parent, его можно использовать в
качестве идентификатора для вызова статических методов даже из нестатиче
ского контекста. Допустим, требуется реализовать идею группирования классов
типа Domainobject. По умолчанию все эти классы подпадают под категорию
’’default”. Но данное положение требуется изменить в некоторых ветвях ие
рархии наследования этих классов. Ниже показано, как этого добиться.
// Листинг 04.52
abstract class Domainobject
{

private $group;
public function __ construct()
{

$this->group = static::getGroup();
}

public static function create():

Domainobject

{

return new static ();
}

public static function getGroup():

{
return ’’default";
}
}

string

ГЛАВА 4 » РАСШИРЕННЫЕ СРЕДСТВА

111

// Листинг 04.53

class User extends Domainobject

{
}
// Листинг 04.54

class Document extends Domainobject
{

public static function getGroup():

string

{
return "document”;

}
}
// Листинг 04.55

class Spreadsheet extends Document

{
}
// Листинг 04.56

print_r(User::create() ) ;
print_r(Spreadsheet::create());

Здесь в класс Domainobject был введен конструктор, в котором ключевое
слово static используется для вызова метода getGroup (). Его стандартная
реализация выполняется в классе Domainobject, но переопределяется в клас
се Document. Кроме того, в данном примере кода был создан новый класс
Spreadsheet, расширяющий класс Document Выполнение данного фрагмента
кода приведет к следующему результату:
User Object
(

[group:Domainobjectiprivate] => default
)

Spreadsheet Object
(

[group:Domainobject:private] => document
)

Все происходящее с классом User не настолько очевидно и поэтому требует
некоторых пояснений. В конструкторе класса Domainobject вызывается метод
getGroup (), который интерпретатор РНР находит в текущем классе. Но что ка
сается класса Spreadsheet, то поиск метода getGroup () начинается не с клас
са Domainobject, а с самого вызываемого класса Spreadsheet. А поскольку
в классе Spreadsheet реализация метода getGroup () не предусмотрена, то
интерпретатор РНР вызывает аналогичный метод из класса Document, следуя
вверх по иерархии классов. До внедрения позднего статического связывания в

112

ЧАСТЬ II

ОБЪЕКТЫ

версии РНР 5.3 здесь возникало затруднение в связи с применением ключево
го слова self, по которому поиск метода getGroupO производился только в
классе Domainobject.

Обработка ошибок
Иногда все идет не так, как надо. Файлы где-то потерялись, объекты для
связи с серверами баз данных остались не инициализированными, URL измени
лись, XML-файлы были повреждены, права доступа установлены неправильно,
лимиты на выделенное дисковое пространство превышены. Этот список можно
продолжать до бесконечности. Если пытаться предусмотреть любое осложнение
в простом методе, он может просто утонуть под тяжестью собственного кода
обработки ошибок.
Ниже приведено определение простого класса Conf, где сохраняются, извле
каются и устанавливаются данные в XML-файле конфигурации.
// Листинг 04.57

class Conf
{

private $file;
private $xml;
private $lastmatch;
public function __ construct(string $file)
{

$this->file = $file;
$this->xml = simplexml_load_file($file);
}

public function write()
{

file_put_contents($this->file,

$this->xml->asXML());

}

public function get(string $str)
{
$matches = $this->xml->xpath("/conf/item[@name=\"$str\"]");
if (count($matches)) {
$this->lastmatch = $matches[0];
return (string)$matches [0];
}
return null;

}

public function set(string $key,

string $value)

{
if

(! is_null($this->get($key)))
$this->lastmatch[0]=$value;
return;

}
$conf = $this->xml->conf;

{

ГЛАВА 4 и РАСШИРЕННЫЕ СРЕДСТВА

113

$this->xml->addChild('item', $value)->
addAttribute('name', $key);

}

}

Для доступа к парам “имя-значение” в классе Conf используется расшире
ние SimpleXml языка РНР. Ниже приведен фрагмент из файла конфигурации в
формате XML, который обрабатывается в классе Conf.
// Листинг 04.57а

bob
newpass
localhost

Конструктору класса Conf передается имя файла конфигурации, которое
далее передается функции simplexml load f ile (). Возвращаемый из этой
функции объект типа SimpleXmlElement сохраняется в свойстве $xml. Для об
наружения элемента item с заданным атрибутом name в методе get () вызывает
метод xpath() для объекта SimpleXmlElement. Значение найденного элемента
возвращается в вызывающий код. А метод set () изменяет значение существу
ющего элемента или создает новый элемент. И, наконец, метод write () сохра
няет данные о новой конфигурации в исходном файле на диске.
Как и код из многих приведенных до сих пор примеров, код класса Conf
сильно упрощен. В частности, в нем не предусмотрена обработка ситуаций, ког
да файл конфигурации не существует или в него нельзя записать данные. Этот
код также слишком “оптимистичен”. В нем предполагается, что XML-документ
правильно отформатирован и содержит ожидаемые элементы.
Организовать проверку подобных ошибок совсем не трудно, но нам нужно
решить, как реагировать на них, если они возникнут. В целом у нас имеются
для этого следующие возможности.
1. Завершить выполнение программы. Это простой, но радикальный вы

ход из положения. В итоге вся вина за неудачное завершение программы
падет на скромный класс Conf. Несмотря на то что такие методы, как
construct () и write (), удачно расположены в исходном коде класса
Conf для обнаружения ошибок, им недостает информации, чтобы решить,
как обрабатывать эти ошибки.
2. Вместо обработки ошибки в классе Conf можно возвратить признак ошиб

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

114

ЧАСТЬ II

ОБЪЕКТЫ

Оба упомянутых выше подхода удачно сочетаются во многих пакетах PEAR,
где возвращается объект ошибки (экземпляр класса PEAR Error). Наличие это
го объекта свидетельствует о том, что произошла ошибка, а подробные сведения
о ней содержатся в самом объекте. И хотя применять такой способ обработки
ошибок в настоящее время не рекомендуется, многие классы не были до сих
пор обновлены из-за того, что клиентский код зачастую полагается на старые
стандарты поведения при возникновении ошибок.
Трудность состоит еще и в том, что возвращаемое значение может быть ис
кажено. И тогда приходится полагаться на то, что клиентский код будет прове
рять тип возвращаемого объекта после каждого вызова метода, подверженного
ошибкам. А это довольно рискованно. Доверять нельзя никому!
Когда ошибочное значение возвращается из метода в вызывающий код, нет
никакой гарантии, что клиентский код будет оснащен лучше данного метода и
сможет решить, как обрабатывать ошибку. А если он не сможет это сделать, то
осложнения будут появляться снова и снова. Поэтому в клиентском методе при
дется определить, как реагировать на ошибочную ситуацию, а возможно, даже
реализовать другую стратегию извещения об ошибке.

Исключения
В версии РНР 5 было введено понятие исключения (exception), представля
ющее собой совершенно другой способ обработки ошибок. Имеется в виду, что
он совершенно иной для языка РНР, но если у вас есть опыт программирования
на Java или С+4-, то понятие исключения вам знакомо. Применение исключений
позволяет разрешить все описанные выше трудности, возникающие в связи с
обработкой ошибок.
Исключение — это специальный объект, который является экземпляром
встроенного класса Exception или производного от него класса. Объекты типа
Exception предназначены для хранения информации об ошибках и выдачи со
общений о них. Конструктору класса Exception передаются два необязатель
ных аргумента: строка сообщения и код ошибки. В этом классе существуют
также некоторые полезные методы для анализа ошибочной ситуации, перечис
ленные в табл. 4.1.
Таблица 4.1. Открытые методы класса Exception

Метод
getMessage()

Описание

getCode()

Получить целочисленный код ошибки, который был передан
конструктору

getFile()

Получить имя файла, в котором было сгенерировано исклю
чение

getLine()

Получить номер строки, в которой было сгенерировано ис
ключение

Получить строку сообщения, переданную конструктору

ГЛАВА 4 шг РАСШИРЕННЫЕ СРЕДСТВА

115

Окончание табл. 4.1

Метод

Описание

getPrevious()

Получить вложенный объект типа Exception

getTrace()

Получить многомерный массив, отслеживающий вызовы
метода, которые привели к исключению, в том числе имя
метода, класса, файла и значение аргумента

getTraceAsString ()

Получить строковый вариант данных, возвращаемых мето
дом getTrace ()

__ toString()

Вызывается автоматически, когда объект типа Exception
используется в контексте символьной строки. Возвращает
строку, подробно описывающую возникшее исключение

Классом Exception очень удобно пользоваться для извещения об ошибках и
предоставления отладочной информации (в этом отношении особенно полезны
методы getTrace () и getTraceAsString ()). На самом деле класс Exception
почти идентичен обсуждавшемуся ранее классу PEAR Error, но в нем сохраня
ется намного меньше сведений об исключениях, чем есть на самом деле.
Генерирование исключений

Вместе с объектом типа Exception используется оператор с ключевым сло
вом throw. Этот оператор останавливает выполнение текущего метода и пере
дает ответственность за обработку ошибок обратно в вызывающий код. Внесем
приведенные ниже коррективы в метод-конструктор __ construct (), чтобы
воспользоваться оператором throw.
// Листинг 04.58
public function __ construct(string $file)

{
$this->file = $file;
if (! file_exists($file)) {
throw new \Exception("Файл

’$file’

не найден");

}
$this->xml = simplexml_load_file($file);
}

Аналогичной конструкцией можно воспользоваться и в методе write ().
// Листинг 04.59
public function write ()
{

if

(! is_writeable($this->file)) {
throw new \Exception(
"Файл ’{$this->file}’ недоступен по записи");

}
file_put_contents($this->file,

$this->xml->asXML());

116

ЧАСТЬ II ® ОБЪЕКТЫ

Теперь по ходу выполнения методов__ construct () и write () можно тща
тельно проверять ошибки, связанные с доступом к файлу, хотя решение, как
реагировать на любые обнаруженные ошибки, будет все равно приниматься в
клиентском коде. Так как же тогда клиентский код узнает, что возникло исклю
чение и настала пора его обрабатывать? Для этого при вызове метода, в котором
может возникнуть исключение, следует воспользоваться оператором try. Опера
тор try состоит из ключевого слова try и следующих за ним фигурных скобок.
За оператором try должен следовать по меньшей мере один оператор catch,
где можно обработать любую ошибку, как показано ниже.
// Листинг 04.60

try {
$conf = new Conf (__ DIR__ . "/conf01.xml");
print "user: ” . $conf->get(’user’) . "\n";
print "host: " . $conf->get('host') . "\n";
$conf->set("pass", "newpass");
$conf->write();
} catch (\Exception $e) {
die ($e->__ toString() ) ;

}

Как видите, оператор catch внешне напоминает объявление метода. Когда
генерируется исключение, управление передается оператору catch в контексте
вызывающего метода, которому в качестве переменной аргумента автоматиче
ски передается объект типа Exception. Если теперь возникнет исключение при
выполнении метода, вызов которого находится в блоке оператора try, выполне
ние сценария остановится и управление будет передано непосредственно опе
ратору catch.
Создание подклассов класса Exception

Классы, расширяющие класс Exception, можно создавать таким же обра
зом, как и любой другой класс, определенный пользователем. Имеются две при
чины, по которым может возникнуть потребность в такой подклассификации
исключений. Во-первых, можно расширить функциональные возможности клас
са Exception. И во-вторых, производный от него класс определяет новый тип
класса, который может оказать помощь в обработке ошибок.
На самом деле для одного оператора try можно определить столько опера
торов catch, сколько потребуется. А вызов конкретного оператора catch будет
зависеть от типа сгенерированного исключения и объявления типа класса, ука
занного в списке аргументов. Итак, определим ряд простых классов, расширя
ющих класс Exception.
// Листинг 04.61
class XmlException extends \Exception
{

private $error;

ГЛАВА 4 « РАСШИРЕННЫЕ СРЕДСТВА

117

public function __ construct(\LibXmlError Serror)
{
$shortfile = basename($error->file);
$msg = " [ {$shortfile}, строка {$error->line},
столбец {$error->column}] {$error->message}”;
$this->error = $error;
parent::__ construct($msg, $error->code);
}

public function getLibXmlError()

{
return $this->error;

}
}

// Листинг 04.62

class FileException extends \Exception
{
}

// Листинг 04.63
class ConfException extends \Exception
{
}

Объект класса LibXmlError создается автоматически, когда средства SimpleXml
обнаруживают поврежденный XML-файл. У него есть свойства message и code,
и он напоминает объект класса Exception. Благодаря этому сходству объект
типа LibXmlError выгодно используется в классе XmlException. У классов
FileException и ConfException не больше функциональных возможностей,
чем у любого другого подкласса, производного от класса Exception. Восполь
зуемся теперь этими классами в следующем примере кода, чтобы немного откор
ректировать методы__ construct () и write () в классе Conf:
// Листинг 04.64
// Класс Conf...
function __ construct(string $file)

(
$this->file = $file;
if (! file_exists($file)) (
throw new FileException("Файл

’$file’

не найден”);

}
$this->xml = simplexml_load_file(
$file, null, LIBXML_NOERROR);
if (! is_object($this->xml)) {
throw new XmlException(libxml_get_last_error());

}
$matches = $this->xml->xpath("/conf");
if (! count($matches)) {
throw new ConfException(

118

ЧАСТЬ II » ОБЪЕКТЫ
"Не найден корневой элемент:

conf");

}

}

function write()

{
if

(! is_writeable($this->file)) {
throw new FileException(
"Файл '{$this->file}’ недоступен по записи");

}
file_put_contents($this->file,

$this->xml->asXML());

}

Метод-конструктор__ construct () генерирует исключения типа
XmlException, FileException или ConfException в зависимости от вида
возникшей ошибки. Обратите внимание на то, что методу simplexml_load_
file () передается признак LIBXML NOERROR, блокирующий выдачу преду
преждений и дающий свободу действий для последующей обработки этих
предупреждений средствами класса XmlException. Так, если обнаружится
поврежденный XML-файл, метод simplexml load file () уже не возвратит
объект типа SimpleXMLElement. Благодаря классу XmlException в клиентском
коде можно будет легко узнать причину ошибки, а с помощью метода libxml_
get last error () — все подробности этой ошибки. А метод write () гене
рирует исключение типа FileException, если свойство $file указывает на
файл, недоступный для записи.
Итак, мы установили, что метод-конструктор__ construct () может гене
рировать одно из трех возможных исключений. Как же этим воспользоваться?
Ниже приведен пример кода, где создается экземпляр объекта Conf.
// Листинг 04.65

public static function init()
{
try {
$conf = new Conf(__ DIR__ ."/conf.broken.xml");
print "user: " . $conf->get(’user•) . "\n";
print "host: " . $conf->get(’host’) . "\n";
$conf->set("pass", "newpass");
$conf->write();
} catch (FileException $e) {
// Файл не существует или недоступен
} catch (XmlException $е) {
// Поврежденный XML-файл
} catch (ConfException $е) {
// Неверный формат XML-файла
} catch (\Exception $е) {
// Ловушка: этот код не должен вызываться

ГЛАВА 4

РАСШИРЕННЫЕ СРЕДСТВА

119

В данном примере мы предусмотрели оператор catch для каждого типа клас
са ошибки. Вызов конкретного оператора catch будет зависеть от типа сгенери
рованного исключения. При этом будет выполнен первый подходящий оператор.
Поэтому не следует забывать, что самый общий тип перехватываемой ошибки
необходимо указывать в конце последовательности операторов catch, а самый
специализированный — в ее начале. Так, если разместить оператор catch для
обработки исключения типа Exception перед аналогичным операторами и для
обработки исключений типа XmlException и ConfException, ни один из них
так и не будет вызван. Дело в том, что оба специальных исключения относятся
к более общему типу Exception, и поэтому они будут вполне соответствовать
условию перехвата в первом операторе catch.
Первый оператор catch (FileException $е) вызывается в том случае, если
возникают проблемы при обращении к файлу конфигурации (он не существует,
или в него нельзя ничего записать). Второй оператор catch (XmlException $е)
вызывается в том случае, если происходит ошибка при синтаксическом анализе
XML-файла (например, не закрыт какой-нибудь элемент разметки). Третий опе
ратор catch (ConfException $е) вызывается в том случае, если XML-файл
верного формата не содержит ожидаемый корневой элемент разметки conf.
И последний оператор catch (Exception $е) не должен вообще вызываться,
потому что рассматриваемые здесь методы генерируют только три исключения,
которые обрабатываются явным образом. В общем, было бы неплохо иметь та
кой оператор-ловушку на тот случай, если в процессе разработки понадобится
ввести новые исключения в прикладной код.
НА ЗАМЕТКУ. Если опустить оператор-ловушку catch, то придется предусмотреть дей

ствия на случай возникновения исключений в большинстве случаев. Ведь незаметные
сбои без уведомлений могут стать причиной программных ошибок, которые с трудом
поддаются диагностике.
Преимущество этих операторов catch с подробно составленными условия
ми перехвата исключений заключается в том, что они позволяют применить к
разным ошибкам различные механизмы восстановления или неудачного завер
шения. Например, можно прекратить выполнение программы, записать в жур
нал регистрации сведения об ошибке и продолжить выполнение или повторно
сгенерировать исключение, как показано ниже.
try {
//...
} catch ( FileException $е
throw $е;

)

{

}

Еще один вариант, которым можно воспользоваться, — сгенерировать новое
исключение, которое будет перекрывать текущее. Это позволяет привлечь вни
мание к ошибке, добавить собственную контекстную информацию и в то же

120

ЧАСТЬ II й ОБЪЕКТЫ

время сохранить данные, зафиксированные в исключении, которое обработала
программа.
Но что произойдет, если исключение не будет обработано в клиентском коде?
Тогда оно автоматически сгенерируется повторно, и его сможет обработать вы
зывающий код клиентской программы. Этот процесс будет продолжаться до тех
пор, пока исключение не будет обработано или его уже нельзя будет снова сге
нерировать. Тогда произойдет неустранимая ошибка. Вот что произойдет, если в
рассматриваемом здесь примере кода не будет обработано ни одно исключение:
РНР Fatal error: Uncaught exception ’FileException’ with message
’file ’nonexistent/not_there.xml' does not exist’ in ..,7

Итак, генерируя исключение, вы вынуждаете клиентский код брать на себя
ответственность за его обработку. Но это не отказ от ответственности. Исклю
чение должно генерироваться, когда метод обнаруживает ошибку, но не имеет
контекстной информации, чтобы правильно ее обработать. В данном примере
методу write () известно, когда и по какой причине попытка сделать запись
завершается неудачно и почему, но в то же время неизвестно, что с этим делать.
Именно так и должно быть. Если бы мы сделали класс Conf более сведущим в
отношении ошибок, чем он есть в настоящий момент, он потерял бы свое кон
кретное назначение и стал бы менее пригодным для повторного использования.
Очистка после операторов try/catch с помощью оператора finally

Неожиданные осложнения могут возникнуть из-за того, что в ход выполне
ния программы могут вмешаться внешние факторы, проявляющиеся в виде ис
ключений. Так, после возникновения исключения в блоке оператора try может
не выполниться код очистки или любые другие важные действия. Как пояс
нялось выше, при возникновении исключительной ситуации в блоке оператора
try управление программы передается первому подходящему блоку оператора
catch. В итоге может не выполниться код, где разрывается соединение с базой
данных или закрывается файл, обновляется текущая информация о состоянии
и т.п.
Допустим, в методе Runner:: init () регистрируются все выполняемые дей
ствия. При этом в системном журнале регистрируется момент начала процесса
инициализации, записываются все ошибки, возникающие при работе приложе
ния, а в самом конце — момент окончания процесса инициализации. Ниже при
веден типичный упрощенный фрагмент кода, выполняющего эти действия.
// Листинг 04.66

public static function init ()
{

7 Неустранимая ошибка в РНР: необработанное исключение типа FileException с
сообщением о том, что файл с расширением .xml не существует или отсутствует в...

ГЛАВА 4 ® РАСШИРЕННЫЕ СРЕДСТВА

121

try {
$fh = fopen(__ DIR__ . "/log.txt", "a");
fputs($fh, "НачалоХп");
$conf = new Conf(dirname(__ FILE__ )
. "/conf.broken.xml");
print "user: " . $conf->get('user’) . "\n";
print "host: " . $conf->get(’host’) . "\n";
$conf->set("pass", "newpass");
$conf->write() ;
fputs($fh, "Конец\п");
fclose($fh);
} catch (FileException $e) {
// Файл не существует или недоступен
fputs($fh, "Проблемы с файлом\п");
throw $е;
}

catch (XmlException $е) {
// Поврежденный XML-файл
fputs($fh, "Проблемы с XML\n");

}

catch (ConfException $е) {
// Неверный формат XML-файла
fputs($fh, "Проблемы с конфигурацией\п");

}

catch (\Exception $е) {
// Ловушка: этот код не должен вызываться
fputs($fh, "Непредвиденные проблемы\п");

}

}

В этом примере кода сначала открывается файл регистрации log.txt, за
тем в него записываются данные, а далее вызывается код для конфигурирова
ния. Если на данном этапе возникнет ошибка, сведения об этом записываются
в файл регистрации в блоке оператора catch. Блок оператора try завершается
записью в файл регистрации и закрытием этого файла. Разумеется, если воз
никнет исключительная ситуация, эти действия выполнены не будут, поскольку
управление передается в соответствующий блок оператора catch, а следова
тельно, не будет выполнена и оставшаяся часть кода в блоке оператора try.
Ниже приведен результат вывода в файл регистрации (системный журнал) при
исключительной ситуации, возникающей при обращении к файлу.
Начало
Проблемы с файлом

Как видите, в системном журнале зафиксирован момент начала процесса
инициализации приложения, а также исключение, возникающее при обраще
нии к файлу. А поскольку фрагмент кода, где сведения об окончании процесса
инициализации выводятся в системный журнал, не был выполнен, то и в файл
регистрации ничего не записано.
Казалось бы, код последней стадии записи в системный журнал следует
вынести за пределы блока операторов try/catch, но такое решение нельзя

122

ЧАСТЬ II в ОБЪЕКТЫ

назвать надежным. Дело в том, что при обработке исключительной ситуации в
блоке оператора catch может быть принято решение о возобновлении выполне
ния программы. Следовательно, управление может быть передано в произволь
ное место программы, которое находится далеко за пределами блока операторов
try/catch. Кроме того, в блоке оператора catch может быть сгенерировано
повторное исключение или вообще завершено выполнение сценария.
Чтобы помочь программистам справиться с описанной выше ситуацией, в
версии РНР 5.5 был введен новый оператор finally. Если вы знакомы с язы
ком Java, то, скорее всего, уже с ним сталкивались. Несмотря на то что блок
оператора catch вызывается только при возникновении исключительной ситу
ации заданного типа, блок оператора finally вызывается всегда, независимо
от того, возникло или нет исключение при выполнении блока оператора try.
Таким образом, для разрешения описанного выше затруднения достаточно
переместить код последней стадии записи в системный журнал и закрытия фай
ла в блок оператора finally:
// Листинг 04.66а

public static function init()
{

try {
$fh = fopen (__ DIR__ . ’’/log. txt", "a");
fputs($fh, "Начало\п");
$conf = new Conf(dirname(__ FILE__ )
. "/conf.broken.xml");
print "user: " . $conf->get(’user') . "\n";
print "host: " . $conf->get('host’) . "\n";
$conf->set("pass", "newpass");
$conf->write ();
}

catch (FileException $e) {
// Файл не существует или недоступен
fputs($fh, "Проблемы с файлом\п");
throw $е;

}

catch (XmlException $е) {
// Поврежденный XML-файл
fputs($fh, "Проблемы с XML\n");

}

catch (ConfException $е) {
// Неверный формат XML-файла
fputs($fh, "Проблемы с конфигурацией \п");

}

catch (\Exception $е) {
// Ловушка: этот код не должен вызываться
fputs($fh, "Непредвиденные проблемы \п");

}

finally {
fputs($fh, "Конец\п");
fclose($fh);

ГЛАВА 4

РАСШИРЕННЫЕ СРЕДСТВА

123

Последняя запись в системный журнал и вызов функции f close () помеще
ны в блок оператора finally, и поэтому они будут выполняться всегда, даже
при возникновении исключения типа FileException и повторного его генери
рования в блоке оператора catch. Ниже приведен вывод в системный журнал
при возникновении исключения типа FileException.
Начало
Проблемы с файлом
Конец

НА ЗАМЕТКУ. Блок оператора finally выполняется, если в блоке оператора catch

повторно генерируется исключение или выполняется оператор return, возвращаю
щий значение в вызывающую программу. Если же в блоке оператора try или catch
вызывается функция die() или exit () для завершения сценария, то блок операто
ра finally не выполняется.

Завершенные классы и методы
Наследование открывает большие возможности для широкого поля действий
в пределах иерархии класса. Класс или метод можно переопределить таким об
разом, чтобы вызов в клиентском методе приводил к совершенно разным ре
зультатам в зависимости от типа объекта, переданного этому методу в качестве
аргумента. Но иногда код класса или метода нужно зафиксировать, если пред
полагается, что в дальнейшем он не должен изменяться. Если вы создали необ
ходимый уровень функциональности для класса и считаете, что его переопре
деление может только повредить идеальной работе программы, воспользуйтесь
ключевым словом final.
Ключевое слово final позволяет положить конец наследованию. Для завер
шенного класса нельзя создать подкласс. А завершенный метод нельзя перео
пределить. Ниже показано, каким образом объявляется завершенный класс.
// Листинг 04.67
final class Checkout
{

//

...

}

А вот как выглядит попытка создать подкласс, производный от класса
Checkout:
// Листинг 04.68
class IllegalCheckout extends Checkout

{

//

...

124

ЧАСТЬ II Я ОБЪЕКТЫ

Это приведет к следующему сообщению об ошибке:
РНР Fatal error: Class IllegalCheckout may not inherit from
final class (Checkout) in ...8

Эту ситуацию можно немного смягчить, объявив завершенным только метод
в классе Checkout, а не весь класс, как показано ниже. В объявлении завер
шенного метода ключевое слово final должно быть указано перед любыми
другими модификаторами доступа вроде protected или static.
// Листинг 04.69
class Checkout
{

final public function totalize ()
{

// рассчитать общие расходы
}
}

Теперь можно создать подкласс, производный от класса Checkout, но любая
попытка переопределить метод totalize () приведет к неустранимой ошибке,
как показано ниже.
// Листинг 04.70
class IllegalCheckout extends Checkout
{

final public function totalize ()
{

// внести изменения в расчет общих расходов
}

}

РНР Fatal error: Cannot override final method Checkout:: totalize () ...9

В удачно написанном объектно-ориентированном коде обычно во главу угла
ставится вполне определенный интерфейс. Но за этим интерфейсом могут скры
ваться разные реализации. Разные классы или их сочетания могут соответство
вать общим интерфейсам, но вести себя они могут по-разному в различных си
туациях. Объявляя класс или метод завершенным, вы тем самым ограничиваете
подобную гибкость. Иногда это желательно, и мы рассмотрим такие случаи да
лее в книге. Но прежде чем объявлять что-либо завершенным, следует серьезно
подумать, действительно ли не существует таких ситуаций, где переопределение
8 Неустранимая ошибка в РНР: класс
завершенного класса Checkout в...

IllegalCheckout

не может быть унаследован от

9 Неустранимая ошибка в РНР: нельзя переопределить завершенный метод
totalize ()...

Checkout::

ГЛАВА 4

РАСШИРЕННЫЕ СРЕДСТВА

125

было бы полезным? Конечно, всегда можно передумать, но внести изменения
впоследствии, возможно, будет нелегко, например, в том случае, если распро
страняется библиотека для совместного использования. Поэтому будьте внима
тельны, употребляя ключевое слово final.

Внутренний класс Error
Когда исключения были только внедрены, механизмы попыток выполнить
код и перехватить исключения применялись, главным образом, в коде сценари
ев, а не в самом ядре РНР, где возникавшие ошибки обрабатывались собствен
ной логикой. Это могло привести к серьезным осложнениям, если требовалось
обрабатывать ошибки, возникающие в ядре РНР, таким же образом, как и ис
ключения в прикладном коде. В качестве первоначальной меры борьбы с по
добными осложнениями в версии РНР 7 был внедрен внутренний класс Error,
в котором реализован тот же самый встроенный интерфейс Throwable, что и
в классе Exception. Поэтому с классом Error можно обращаться так же, как
и с классом Exception. Это означает, что в классе Error поддерживаются ме
тоды, перечисленные в табл. 4.1. Для обработки отдельных ошибок из класса
Error можно создать соответствующий подкласс. Ниже показано, как можно
перехватить ошибку синтаксического анализа, возникающую при выполнении
оператора eval.
// Листинг 04.70а
try {
eval("Некорректный код");
} catch (\Error $е) {
print get_class($е).”\п";
} catch (\Exception $е) {
// Обработать как-нибудь исключение типа Exception
}

Выполнение данного фрагмента кода приведет к следующему результату:
ParseError

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

Тип ошибки

Описание

ArithmeticError

Генерируется при возникновении ошибок в математических
операциях, и особенно в поразрядных арифметических
операциях

126

ЧАСТЬ II я ОБЪЕКТЫ
Окончание табл. 4.2

Тип ошибки
AssertionError

Описание

D ivi sionByZeroEr ror

Генерируется при попытке деления числа на нуль

ParseError

Генерируется при неудачной попытке выполнить синтакси
ческий анализ кода РНР, например, с помощью оператора
eval

TypeError

Генерируется при передаче методу аргумента неверного
типа, возврате из метода значения неверного типа или пе
редаче неверного количества аргументов методу

Генерируется при неудачном выполнении языковой кон
струкции assert (), применяемой при отладке прикладно
го кода

НА ЗАМЕТКУ. На момент написания данной книги попытка вызвать метод Error: :get

Message () приводила к ошибке, несмотря на то, что данный метод объявлен в ин
терфейсе Throwable. Этот недостаток, вероятнее всего, будет устранен к тому вре
мени, когда вы будете читать данную книгу!

Работа с методами-перехватчиками
В языке РНР предусмотрены встроенные методы-перехватчики, которые мо
гут перехватывать сообщения, посланные неопределенным (т.е. несуществую
щим) методам или свойствам. Такой механизм называется также перегрузкой
(overloading), но поскольку этот термин в Java и C++ означает нечто совершен
но иное, то будет лучше употреблять термин перехват (interception).
В языке РНР поддерживаются три разновидности встроенных методов-пере
хватчиков. Аналогично методу-конструктору__ construct (), вызов этих мето
дов происходит неявно, когда удовлетворяются соответствующие условия. Эти
методы перечислены в табл. 4.3.
Таблица 4.3. Методы-перехватчики

Метод

Описание

__ get($property)

Вызывается при обращении к неопреде
ленному свойству

__ set($property, $value)

Вызывается, когда неопределенному
свойству присваивается значение

__ isset($property)

Вызывается, когда функция isset() вы
зывается для неопределенного свойства

unset($property)

Вызывается, когда функция unset() вы
зывается для неопределенного свойства

__ call($method, $arg_array)

Вызывается при обращении к неопреде
ленному нестатическому методу

__ callStatic ($method, $arg__array)

Вызывается при обращении к неопреде
ленному статическому методу

ГЛАВА 4 а? РАСШИРЕННЫЕ СРЕДСТВА

127

Методы__ get () и__ set () предназначены для работы со свойствами, кото
рые не были объявлены в классе (или его родительском классе). Метод__ get ()
вызывается, когда клиентский код пытается прочитать необъявленное свойство.
Он вызывается автоматически с одним строковым аргументом, содержащим имя
свойства, к которому клиентский код пытается получить доступ. Все, что воз
вратит метод__ get (), будет отправлено обратно клиенту, как будто искомое
свойство существует с этим значением. Ниже приведен краткий пример приме
нения методов-перехватчиков.
// Листинг 04.71

class Person

{
public function __ get(string $property)

{
$method = "get{$property}";
if (method_exists($this, $method))
return $this->$method();

{

}
}
public function getName():

string

{
return "Иван";
}

public function getAge():

int

{

return 44;
}

}

Когда клиентский код пытается получить доступ к неопределенному свой
ству, вызывается метод __ get (), в котором перед именем переданного ему
свойства добавляется строка "get”. Затем полученная строка, содержащая но
вое имя метода, передается функции method exists (). Этой функции переда
ется также ссылка на текущий объект, для которого проверяется существование
метода. Если метод существует, он вызывается, а клиентскому коду передается
значение, возвращаемое из этого метода. Следовательно, если в клиентском коде
запрашивается свойство $name следующим образом:
$р = new Person();
print $p->name;

то метод getName () вызывается неявно и выводится следующая строка:
Иван

Если же метод не существует, то ничего не происходит. Свойству, к которому
пользователь пытается обратиться, присваивается пустое значение NULL.

128

ЧАСТЬ II Ж ОБЪЕКТЫ

Метод__ isset() действует аналогично методу__ get(). Он вызывается
после того, как в клиентском коде вызывается функция is set () и ей в качестве
параметра передается имя неопределенного свойства. В качестве примера ниже
показано, как можно расширить класс Person.
// Листинг 04.72
public function __ isset(string $property)
{

$method = "get{$property}";
return (method_exists($this,

$method));

}

А теперь предусмотрительный пользователь может проверить свойство, пре
жде чем работать с ним.
if

( isset ( $p->name
print $p->name;

)

)

{

}

Метод__ set () вызывается, когда в клиентском коде предпринимается по
пытка присвоить значение неопределенному свойству. При этом передаются два
аргумента: имя свойства и значение, которое требуется присвоить в клиентском
коде. И тогда можно решить, как обращаться с этими аргументами. Продолжим
расширение класса Person следующим образом:
// Листинг 04.73
class Person {
private $_name;
private $_age;
public function __ set( $property, $value
$method = "set{$property}";
if ( method_exists( $this, $method ) )
return $this->$method( $value );

)

{

{

}

}
public function setName( $name ) {
$this->_name = $name;
if ( ! is_null( $name ) ) {
$this->_name = mb_strtoupper($this->_name);
}

}
public function setAge(
$this->_age = $age;

$age )

{

}
}

В этом примере применяются методы установки, а не получения. Если поль
зователь попытается присвоить значение неопределенному свойству, то методу

ГЛАВА 4 « РАСШИРЕННЫЕ СРЕДСТВА

129

__ set () будут переданы имя этого свойства и присваиваемое ему значение.
В методе__ set () проверяется, существует ли указанный метод, и, если он су
ществует, то вызывается. В итоге можно отфильтровать значение, присваиваемое
свойству.
НА ЗАМЕТКУ. Не забывайте, что при описании имен методов и свойств в документации по

РНР зачастую употребляется статический синтаксис, чтобы было ясно, в каком классе
они содержатся. Поэтому вы можете встретить ссылку на свойство Person:: $name,
даже если оно не объявлено как статическое (static) и к нему на самом деле можно
получить доступ через объект, имя которого отличается от Person.

Итак, если мы создаем объект типа Person, а затем пытаемся установить
свойство Person: :$name, то вызывается метод__ set(), потому что в классе
Person не определено свойство $name. Этому методу передаются две строки,
содержащие имя свойства и значение, которое требуется установить. И как это
значение используется далее, зависит от конкретной реализации метода__ set ().
В данном примере образуется новое имя метода путем добавления строки ’’set”
перед именем свойства, передаваемого в качестве аргумента. В итоге интерпре
татор РНР обнаруживает метод setName () и вызывает его должным образом.
В этом методе входное строковое значение приводится к верхнему регистру букв
и сохраняется в действительно существующем свойстве, как показано ниже.
$р = new Person ();
$p->name = "Иван";
// Реальному свойству $_name присваивается строка

'ИВАН’

Как и следовало ожидать, метод__ unset () является зеркальным отраже
нием метода__ set(). Он вызывается в том случае, если функции unset()
передается имя неопределенного свойства. Имя этого свойства передается далее
методу__ unset (). Полученную информацию о свойстве можно обрабатывать
как угодно. Так, в приведенном ниже примере кода пустое значение null пе
редается найденному в итоге методу тем же самым способом, что и выше в
методе__ set ().
// Листинг 04.74
public function __ unset(string $property)

{
$method = "set{$property}";
if (method_exists($this, $method))
$this->$method(null);

{

}

}

Метод__ call, вероятно, самый полезный из всех методов-перехватчиков.
Он вызывается в том случае, если клиентский код обращается к неопределен
ному методу. При этом методу __ са!1() передаются имя несуществующего

130

ЧАСТЬ II ■ ОБЪЕКТЫ

метода и массив, в котором содержатся все аргументы, переданные клиентом.
Значение, возвращаемое методом__ са11(), передается обратно клиенту так,
как будто оно было возвращено вызванным несуществующим методом.
Метод__ call () можно применять для целей делегирования. Делегирова
ние — это механизм, с помощью которого один объект может вызвать метод
другого объекта. Это чем-то напоминает наследование, когда дочерний класс
вызывает метод, реализованный в родительском классе. Но при наследовании
взаимосвязь между родительским и дочерним классами фиксирована. Поэтому
возможность изменить объект-получатель во время выполнения программы оз
начает, что делегирование является более гибким механизмом, чем наследова
ние. Чтобы механизм делегирования стал понятнее, обратимся к конкретному
примеру. Рассмотрим простой класс, предназначенный для форматирования ин
формации, полученной из класса Person.
// Листинг 04.75

class Personwriter
{

public function writeName(Person $p)
{

.

print $p->getName()

"\n";

}
public function writeAge(Person $p)

{
print $p->getAge()

.

"\n";

}

}

Безусловно, можно было бы создать подкласс, производный от этого клас
са, чтобы выводить различными способами сведения, получаемые из класса
Person. В качестве примера одного из таких способов ниже приведена реа
лизация класса Person, где используется объект типа Personwriter и метод
_са11().
// Листинг 04.76

class Person

{
private $writer;
public function __ construct(Personwriter $writer)

{
$this->writer = $writer;
}

public function __ call(string $method, array $args)
{
if (method_exists($this->writer, $method)) {

ГЛАВА 4 S РАСШИРЕННЫЕ СРЕДСТВА

131

return $this->writer->$method($this) ;
}
}

public function getName():

string

{

return "Иван”;
}

public function getAge():

int

{

return 44;
}

Здесь конструктору класса Person в качестве аргумента передается объект
типа Personwriter, ссылка на который сохраняется в переменной свойства
$writer. В методе__ call () используется значение аргумента $method и про
веряется наличие метода с таким же именем в объекте Personwriter, ссылка
на который была сохранена в конструкторе. Если такой метод найден, еговызов
делегируется объекту Personwriter. При этом вызываемому методу переда
ется ссылка на текущий экземпляр объекта типа Person, которая хранится в
псевдопеременной $this. Так, если клиент вызовет несуществующий в классе
Person метод следующим образом:
$person = new Person(new Personwriter ());
$person->writeName();

в итоге будет вызван метод__ call (), где проверяется существует ли в объ
екте типа Personwriter метод с именем writeName (). Поскольку этот метод
действительно существует, то он и вызывается. Это позволяет избежать вызова
делегируемого метода вручную, как показано ниже.
function writeName() {
$this->writer->writeName($this);
}

Таким образом, класс Person, как по волшебству, получил два новых мето
да из класса Personwriter. Хотя автоматическое делегирование избавляет от
рутинной работы по стереотипному программированию вызовов методов, сам
код становится сложным для понимания. И если в вашей программе активно
используется делегирование, то для внешнего мира создается динамический ин
терфейс, который не поддается рефлексии (исследованию состава класса во вре
мя выполнения программы) и не всегда с первого взгляда понятен программи
сту клиентского кода. Дело в том, что логика, лежащая в основе взаимодействия
делегирующего класса и целевого объекта, может быть непонятной. Ведь она
скрыта в таких методах, как__ call (), а не явно задана отношениями наследо
вания или указаниями типов аргументов в методах. Методы-перехватчики нахо
дят свое применение, но пользоваться ими следует аккуратно. И в тех классах,

132

ЧАСТЬ II ® ОБЪЕКТЫ

где применяются эти методы, такое применение следует хорошо документиро
вать. К вопросам делегирования и рефлексии мы еще вернемся в этой книге.
Методы-перехватчики __ get() и __ set () можно также применять для
поддержки составных свойств. Они могут создать определенные удобства для
программиста клиентского кода. Допустим, что в классе Address сохраняется
информация о номере дома и названии улицы. В конечном итоге информация из
этого класса будет сохранена в соответствующих полях базы данных, и поэтому
такое разделение адреса на улицу и номер дома имеет определенный смысл. Но
если часто требуется неразделенная информация об адресе, содержащая в одной
строке номер дома и название улицы, то необходимо позаботиться и о пользова
телях данного класса. Ниже приведен пример класса, в котором поддерживается
составное свойство Address: :$streetaddress.
// Листинг 04.77

class Address

{

private Snumber;
private $street;

public function __ construct(
string $maybenumber, string $maybestreet = null)
{

if
}

(is_null($maybestreet)) {
$this->streetaddress = $maybenumber;
else {
$this->number = $maybenumber;
$this->street = $maybestreet;

}

}
public function __ set(string $property,

string $value)

{
if

($property === "streetaddress") {
if (preg_match("/A(\d+.*?)[\s,]+(.+)$/",
Svalue, Smatches)) {
$this->number = Smatches[1];
$this->street = Smatches[2];
} else {
throw new \Exception(
"Ошибка в адресе: '{Svalue}’");
}

}

}
public function __ get(string Sproperty)
{

if

(Sproperty === "streetaddress") {
return $this->number . " " . $this->street;

ГЛАВА 4 « РАСШИРЕННЫЕ СРЕДСТВА

133

// Листинг 04.78
$address = new Address("44 lb Bakers Street");
print "Адрес: {$address->streetaddress}\n";

$address = new Address("15"f "Albert Mews");
print "Адрес: {$address->streetaddress}\n";
$address->streetaddress = "34, West 24th Avenue";
print "Адрес: {$address->streetaddress}\n";

При попытке установить значение несуществующего свойства
Address: :$streetaddress будет вызван метод__ set (). В нем проверяется
имя составного свойства ’’streetaddress”, которое необходимо поддерживать
в классе. Перед тем как установить значения свойств $number и $ street, сле
дует убедиться, что переданный адрес соответствует ожидаемому шаблону и
может быть корректно проанализирован. После этого нужно извлечь значения
свойств из строки адреса, которую передал пользователь. Для целей данного
примера было установлено следующее простое правило: адрес может быть про
анализирован, если он начинается с цифры, после которой следует пробел или
запятая, а затем название улицы. Благодаря применению обратных ссылок в ре
гулярном выражении после удачного исхода синтаксического анализа строки в
массиве $matches окажутся нужные данные, которые можно присвоить свой
ствам $number и $street. Если же строка адреса не пройдет проверку, то гене
рируется исключение. Следовательно, когда строка адреса вроде ”441b Bakers
Street” присваивается свойству Address: : $streetaddress, на самом деле
выделенные из этой строки значения будут присвоены свойствам $number и
$street. В этом можно убедиться с помощью функции printer (), как пока
зано ниже.
$address = new Address(
print_r($address) ;

"441b Bakers Street"

);

Address Object
(
[number:Address:private] => 441b
[street.’Address:private] => Bakers Street
)

По сравнению с методом__ set () метод__ get () очень простой. При по
пытке доступа к несуществующему свойству Address: : $streetaddress бу
дет вызван метод__ get (). В рассматриваемой здесь реализации этого метода
сначала проверяется имя свойства ’’streetaddress”, и, если оно совпадает,
то в вызывающую часть программы возвращается строка, составленная из двух
значений свойств $number и $street.

134

ЧАСТЬ II * ОБЪЕКТЫ

Определение методов-деструкторов
Как было показано ранее, при создании экземпляра объекта автоматически
вызывается метод-конструктор construct (). В версии РНР 5 был также вне
дрен метод-деструктор__ destruct(), который вызывается непосредственно
перед тем, как объект отправляется на “свалку”, т.е. удаляется из памяти. Этим
методом можно пользоваться для выполнения завершающей очистки оператив
ной памяти от объектов, если в этом есть необходимость.
Допустим, что по запросу экземпляр класса сохраняется в базе данных. В та
ком случае можно вызвать метод__ destruct (), чтобы гарантированно сохра
нить данные из экземпляра этого класса перед его удалением из памяти. В ка
честве примера введем метод-деструктор в класс Person:
// Листинг 04.79

class Person
{
protected $name;
private $age;
private $id;

public function __ construct(string $name,
{
$this->name = $name;
$this->age = $age;
}

int $age)

public function setld(int $id)
{
$this->id = $id;
}

public function __ destruct()
{
if

(! empty($this->id)) {
// сохранить данные из экземпляра класса Person
print "Сохранение персональных данных \п";

}
}
}

Метод__ destruct () вызывается всякий раз, когда объект типа Person уда
ляется из памяти. Это происходит при вызове функции __ unset (), которой
передается ссылка на удаляемый объект, а также в том случае, когда в текущем
процессе не остается никаких ссылок на объект. Чтобы увидеть, как на самом
деле действует метод-деструктор __ destruct (), достаточно создать объект
типа Person, а затем уничтожить его.
// Листинг 04.80

$person = new Person("Иван",

44);

ГЛАВА 4 в РАСШИРЕННЫЕ СРЕДСТВА
$person->setld(343) ;
unset($person) ;
// выводится сообщение:

135

"Сохранение персональных данных"

И хотя такие приемы выглядят очень занимательно, следует все же высказать
предостережение. Такие методы, как__ call (),__ destruct () и им подобные,
иногда еще называют магическими. Если вы когда-либо читали произведения
фантазийного жанра, то, вероятно, знаете, что магия — это не всегда благо.
Магия случайна и непредсказуема, она нарушает правила и влечет скрытые рас
ходы.
Например, в случае использования вами метода__ destruct () может слу
читься так, что программист клиентского кода столкнется с неприятными сюр
призами. Задумайтесь, как работает класс Person: он делает запись в базу
данных с помощью своего метода__ destruct (). А теперь представьте, что
начинающий разработчик решает воспользоваться вашим классом Person, не
разобравшись в механизме его действия. Не обратив внимания на метод-де
структор __ destruct (), он собирается создать ряд экземпляров класса Person.
Передавая значения конструктору, он дает тайную и обидную кличку генераль
ного директора свойству $name и устанавливает значение 150 в свойстве $аде.
Далее разработчик прогоняет тестовый сценарий несколько раз, используя кра
сочные сочетания имени и возраста своего начальника. А на следующее утро
начальник вызывает его к себе в кабинет и просит объяснить, почему в базе
данных содержатся оскорбительные данные в адрес служащих компании. Мо
раль сей басни такова: не доверяйте магии.

Копирование объектов с помощью
метода__ clone ()
В версии РНР 4 копирование объекта выполнялось очень просто — достаточ
но было присвоить значение одной объектной переменной другой, как показано
ниже.
class СоруМе

{}

$first = new СоруМеО;
$second = $first;
// В версии РНР 4 переменные $second и $first
// ссылаются на два разных объекта.
// Начиная с версии РНР 5, переменные $second и $first
// ссылаются на один и тот же объект

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

136

ЧАСТЬ II В ОБЪЕКТЫ

понять, относятся ли они к одному и тому же объекту. С помощью операций
равенства можно было проверить, одинаковы ли значения во всех полях двух
сравниваемых объектов (операция =) либо являются ли обе переменные объ
ектами (операция =). Но в результате этих проверок нельзя было понять, ука
зывают ли обе переменные на один и тот же объект.
В языке РНР объекты всегда присваиваются и передаются по ссылке. Это
означает, что если выполнить приведенный выше пример кода в версии РНР 5,
то переменные $ first и $ second будут содержать ссылки на один и тот же
объект, а не на две разные его копии. И хотя это именно то, что, как правило,
нужно для манипулирования объектами, возможны ситуации, когда требуется
получить копию объекта, а не ссылку на объект.
В версии РНР 5 для этой цели предусмотрено ключевое слово clone. Оно
применяется к экземпляру объекта и создает его дополнительную копию.
class СоруМе {}
$first = new СоруМе();
$second = clone $first;
// Начиная с версии РНР 5, переменные $second и $first
// ссылаются на два разных объекта

И здесь только начинают возникать вопросы, касающиеся копирования объ
ектов. Рассмотрим в качестве примера класс Person, созданный в предыду
щем разделе. Стандартная копия объекта типа Person содержит идентифика
тор (свойство $id), который при реализации полноценного приложения будет
использоваться для нахождения нужной строки в базе данных. Если разрешить
копирование этого свойства, то программист клиентского кода получит в конеч
ном итоге два разных объекта, ссылающихся на один и тот же источник данных,
причем, вероятно, не тот, который он предполагал, когда создавал копию. При
этом обновление информации в базе данных для одного объекта будет оказывать
влияние на другой объект, и наоборот.
Правда, используя ключевое слово clone для копирования объектов, мож
но проконтролировать, что именно копируется. Для этого следует реализовать
специальный метод__ clone () (обратите еще раз внимание на два знака под
черкивания, с которых начинаются имена всех встроенных методов). Метод__
clone () вызывается автоматически, когда для копирования объекта использу
ется ключевое слово clone.
При реализации метода__ clone () важно понимать контекст, в котором дей
ствует данный метод. А действует метод__ clone () в контексте скопированно
го. а не исходного объекта. Итак, введем метод__ clone () в очередную версию
класса Person, как показано ниже.
// Листинг 04.81
class Person
{
protected $name;

ГЛАВА 4 й РАСШИРЕННЫЕ СРЕДСТВА

137

private $age;
private $id;
public function __ construct(string $name,

int $age)

{
$this->name = $name;
$this->age = $age;
}

public function setld(int $id)

{
$this->id = $id;
}

public function __ clone()

{
$this->id = 0;
}

}

Когда операция clone выполняется для объекта типа Person, создается его
новая неполная или поверхностная (shallow) копия, и для нее вызывается метод
__ clone (). Это означает, что все изменения значений свойств, выполняемые в
методе__ clone (), отразятся только на новой копии объекта. А прежние зна
чения, полученные из исходного объекта, будут затерты. В данном случае га
рантируется, что свойство $id скопированного объекта устанавливается равным
нулю:
// Листинг 04.82
$person = new Person (’’Иван”,
$person->setld(343) ;
$person2 = clone $person;
// $person2 :
//
name: Иван
//
age: 44
//
id: 0.

44);

Поверхностное копирование гарантирует, что значения элементарных свойств
будут скопированы из старого объекта в новый. Но при этом будут скопированы
и ссылки на другие объекты, которые были присвоены свойствам. И возможно,
это не совсем то, что нужно, когда клонируется объект. Допустим, что объект
Person дополнен свойством, ссылающимся на объект типа Account, как пока
зано ниже. В этом объекте хранятся данные о состоянии счета, которые также
требуется скопировать в клонированный объект, но в то же время нам не нужно
сохранять в обеих копиях объекта типа Person ссылки на один и тот же счет.
// Листинг 04.83
class Account
{
public $balance;

138

ЧАСТЬ II Ж ОБЪЕКТЫ

public function __ construct(float $balance)
{
$this->balance = $balance;
}

// Листинг 04.84

class Person
{
private $name;
private $age;
private $id;
public $account;

public function __ construct(
string $name, int $age,

Account $account)

{
$this->name = $name;
$this->age = $age;
$this->account = $account;

}
public function setld(int $id)
{

$this->id = $id;
}

public function __ clone()
{

$this->id = 0;
}

// Листинг 04.85

Sperson = new Person("Иван”,
$person->setld(343);
$person2 = clone $person;

44,

new Account(200));

// Добавим $person немного денег
$person->account->balance += 10;

// Этот кредит отразится и на $person2
print $person2->account->balance;

Выполнение данного фрагмента кода приведет к следующему результату:
210

В объект $person было добавлено специальное свойство $account, содер
жащее ссылку на объект типа Account. Это свойство мы намеренно сделали от
крытым ради краткости данного примера. Как вам, должно быть, уже известно,

ГЛАВА 4

РАСШИРЕННЫЕ СРЕДСТВА

139

доступ к свойству обычно ограничивается, а по мере надобности создается ме
тод доступа к нему. Когда же создается клон, он содержит ссылку на тот же са
мый объект типа Account, что и в объектной переменной $person. Мы нагляд
но продемонстрировали это в данном примере, добавляя сначала немного денег
к балансу объекта Account переменной $person, а затем выводя его значение
через переменную $person2.
Если нежелательно, чтобы после выполнения операции клонирования в но
вом объекте осталась ссылка на старый объект, это свойство следует клониро
вать явным образом в методе__ clone (), как показано ниже.
function __ clone()

{
$this->id = 0;
$this->account = clone $this->account;

}

Определение строковых значений для объектов
Еще одним языковым средством, внедренным в версии РНР 5 явно под вли
янием Java, является метод__ toString(). До выхода версии РНР 5.2 при вы
воде содержимого объекта в следующем фрагменте кода:
// Листинг 04.86
class StringThing

{}

$st = new StringThing();
print $st;

получалась такая строка:
Object id #1

А начиная с версии PHP 5.2 выполнение этого фрагмента кода вызовет сле
дующую ошибку:
Recoverable fatal error: Object of class StringThing could not be
converted to string... 10

Реализовав метод__ toString (), можно контролировать, какая именно ин
формация будет выводиться из объектов на экран. Метод__ toString () должен
возвращать строковое значение. Этот метод вызывается автоматически, когда
объект передается функции print () или echo (), а возвращаемое им строко
вое значение будет выведено на экран. В качестве примера введем свою версию
метода__ toString () в минимальную реализацию класса Person.
10 Устранимая ошибка в РНР: объект класса StringThing не может быть преобразован
в символьную строку...

140

ЧАСТЬ II « ОБЪЕКТЫ

// Листинг 04.88

class Person
{
function getName():
jI

string

return "Иван”;

}
function getAge():

int

j

t

return 44;

function __ toString():

string

{

$desc
= $this->getName();
$desc .= ” (возраст ” . $this->getAge()
return $desc;

.

” лет)";

Если теперь вывести объект типа Person на экран следующим образом:
$person = new Person();
print $person;

то получится следующий результат:
Иван (возраст 44 лет)

Метод__ toStringO особенно удобен для записи информации в файлы
регистрации и выдачи сообщений об ошибках, а также для применения в тех
классах, основная задача которых — передавать информацию. Например, при
выводе на экран объекта класса Exception можно выдать краткий отчет о воз
никших исключениях, реализовав в этом классе метод__ toString ().

Функции обратного вызова, анонимные
функции и механизм замыканий
Несмотря на то что анонимные функции не относятся, строго говоря, к сред
ствам ООП, они настолько полезны, что их нельзя было здесь не упомянуть.
Ведь дело в том, что они активно используются в объектно-ориентированных
приложениях наряду с функциями обратного вызова. Определим сначала не
сколько классов следующим образом:
// Листинг 04.89

class Product {
public $name;
public $price;

ГЛАВА 4 и РАСШИРЕННЫЕ СРЕДСТВА
public function __ construct(string $name,

141

float $price)

{

$this->name = $name;
$this->price = $price;
}

}
class ProcessSale

{

private $callbacks;
public function registercallback(callable $callback)

{

if (! is_callable($callback)) {
throw new Exception("Функция обратного вызова — невызываемая!");
}
$this->callbacks[]

= $callback;

}
public function sale(Product $product)

(
print "{$product->name}: обрабатывается...\n”;
foreach ($this->callbacks as $callback) {
call_user_func(Scallback, $product);
}
}

}

Этот код предназначен для выполнения нескольких функций обратного вызо
ва. В нем определены два класса: Product и ProcessSale. В классе Product
просто сохраняются значения свойств $name и $price. Ради краткости примера
они объявлены открытыми. Не следует, однако, забывать, что в реальном проек
те такие свойства следует сделать закрытыми или защищенными и создать для
них методы доступа. А в классе ProcessSale определены два метода.
В частности, методу registercallback () в качестве параметра должна
передаваться переменная, содержащая имя функции, которую можно вызвать.
Об этом свидетельствует уточнение параметра callable. После проверки она
добавляется в массив функций обратного вызова $callbacks. Проверка вы
полняется с помощью встроенной функции is callable (). В итоге гаранти
руется, что методу registercallback () будет передано имя функции, кото
рую можно вызвать с помощью таких функций, как call user func () или
array_walk().
Методу sale () передается объект типа Product. Этот метод выводит со
общение об обработке данного объекта и затем перебирает в цикле элементы
массива $callbacks. Каждый элемент этого массива вместе с объектом типа
Product передается функции call user func (), которая, собственно, и вы
зывает код, написанный пользователем. Все приведенные ниже примеры будут
следовать этому образцу.

142

ЧАСТЬ II

ОБЪЕКТЫ

Чем же так полезны функции обратного вызова? Они позволяют вводить во
время выполнения в компонент новые функциональные возможности, которые
первоначально не были непосредственно связаны с основной задачей, решаемой
этим компонентом. Предусмотрев в компоненте поддержку функций обратного
вызова, вы тем самым позволите другим программистам расширить функцио
нальные возможности вашего кода, причем в таких контекстах, о которых вы
даже и не подозревали.
Допустим, что через какое-то время пользователю класса ProcessSale по
требуется создать журнал продаж. Если этому пользователю будет доступен
исходный код данного класса, он сможет ввести код регистрации продаж непо
средственно в метод sale (). Но такое решение не всегда оказывается удачным.
Если этот пользователь не является владельцем пакета, в котором определен
класс ProcessSale, то все его исправления будут затерты, когда выйдет об
новленная версия пакета. И даже если он является владельцем пакета, то все
равно вводить в метод sale() дополнительные фрагменты кода, решающие
случайные задачи, неразумно. В конечном итоге это приведет к чрезмерному
расширению обязанностей данного метода и способно уменьшить возможность
его повторного использования в других проектах. Мы еще вернемся к этой теме
в других главах.
Правда, в классе ProcessSale из рассматриваемого здесь примера пред
усмотрена возможность обратного вызова. Ниже приведена функция обратного
вызова, имитирующая регистрацию товара в журнале продаж.
// Листинг 04.90

Slogger = function(Sproduct) {
print ” Записываем ({$product->name})\r\n";
};

Sprocessor = new ProcessSale();
Sprocessor->registerCallback(Slogger);
$processor->sale(new Product("Туфли", 6));
print "\n";
$processor->sale(new Product("Кофе", 6));

В данном случае для создания функции обратного вызова использован син
таксис анонимной функции function ($product). Ранее для этой цели исполь
зовалась специальная функция РНР create function (). Однако, начиная с
версии РНР 7.2 она объявлена устаревшей и более не рекомендуется к исполь
зованию. При попытке воспользоваться этой функцией интерпретатор РНР бу
дет выводить соответствующее предупреждение, которое вполне может в самых
неожиданных местах нарушить работу приложения, или полностью поломать
дизайн симпатичного веб-сайта.

ГЛАВА 4 ® РАСШИРЕННЫЕ СРЕДСТВА

143

Как видите, нашей функции обратного вызова передается один параметр.
В итоге получилась конструкция, которую часто называют анонимной, посколь
ку при создании функции мы не указали ее имя, как при объявлении обычных
функций. Вместо этого ссылка на вновь созданную функцию сохраняется в пе
ременной, которую затем можно передать в качестве параметра другим функци
ям и методам. Именно это и было сделано в приведенном выше фрагменте кода.
В частности, ссылка на анонимную функцию была сохранена в переменной
$logger, которая затем была передана в качестве параметра методу ProcessSale: : registercallback (). И в конце данного фрагмента кода были созда
ны два объекта, которые описывают отдельные товары и переданы по очереди
методу sale (). О том, что произойдет дальше, вы уже, вероятно, догадались.
Каждая операция по продаже будет обработана (на самом деле будет выведено
обычное сообщение о товаре), после чего будут выполнены все зарегистриро
ванные функции обратного вызова, как показано ниже.
Туфли: обрабатывается...
Записываем (Туфли)

Кофе: обрабатывается...
Записываем (Кофе)

Проанализируем еще раз пример кода, в котором создается анонимная функ
ция обратного вызова. Если ранее вам уже приходилось пользоваться для этой
цели функцией РНР create function (), то вы, наверное, обратили внимание
на то, насколько уродливо выглядел такой код, как показано ниже?
$logger = create_function(
'$product’f
'print " Записываем
) ;

({$product->name})\n";'

В первом параметре этой функции передавалась строка, содержащая имя па
раметра, а во втором строка, содержащая программный код. Размещение вы
полняемого кода в символьной строке всегда вызывает немало хлопот. Сначала
необходимо экранировать все специальные символы вроде ’ $ ’ и ’ ? ’, встреча
ющиеся в исходном коде, встраиваемом в символьную строку. Более того, по
мере разрастания тела функции обратного вызова проанализировать и понять
ее будет все труднее. Поэтому в версии РНР 5.3 появился более изящный спо
соб создания анонимных функций. Теперь достаточно объявить функцию, как
обычно, а затем присвоить ссылку на нее переменной. И все это можно сделать
в одном операторе!
// Листинг 04.91

$logger = function($product) {
print " Записываем ({$product->name})\r\n";
};

144

ЧАСТЬ II м ОБЪЕКТЫ

Единственное отличие здесь заключается в способе создания переменной,
ссылающейся на анонимную функцию. Как видите, этот код намного понятнее.
В операторе присваивания было указано ключевое слово function, но без кон
кретного имени функции. Обратите внимание на то, что блок этого кода завер
шается точкой с запятой, поскольку в операторе присваивания указывается под
ставляемая анонимная функция. Результат выполнения нового фрагмента кода
ничем не будет отличаться от предыдущего.
Безусловно, функции обратного вызова не обязательно должны быть аноним
ными. В качестве такой функции смело можно указать имя обычной функции
или даже ссылку на метод какого-нибудь объекта. Ниже приведен характерный
тому пример.
// Листинг 04.92

class Mailer

{
public function doMail(Product $product)

{
print " Отправляется

({$product->name})\n";

}
}

// Листинг 04.93
$processor = new ProcessSale();
$processor->registerCallback([new Mailer(),

"doMail"]);

$processor->sale(new Product("Туфли", 6));
print "\n";
$processor->sale(new Product("Кофе", 6));

В данном примере создается новый класс Mailer, содержащий единствен
ный метод doMail (). Этому методу передается объект типа Product, о ко
тором он выводит сообщение. При вызове метода registercallback () в ка
честве параметра ему передается массив, а не ссылка на функцию обратного
вызова, как это было раньше. Первым элементом этого массива является объект
типа Mailer, а вторым — символьная строка, содержащая имя метода, который
требуется вызвать. Напомним, что в методе registercallback () с помощью
уточнения и функции is callable () выполняется проверка типа аргумента на
предмет того, можно ли его вызвать. Данная функция достаточно развита логи
чески, чтобы распознавать массивы подобного рода. Поэтому при правильной
организации обратного вызова в первом элементе такого массива должен нахо
диться объект, содержащий вызываемый метод, а имя этого метода указывается
в виде символьной строки во втором элементе массива. При удачном исходе
проверки типа аргумента будет выведен следующий результат:
Туфли: обрабатывается...
Отправляется (Туфли)

ГЛАВА 4 < РАСШИРЕННЫЕ СРЕДСТВА

145

Кофе: обрабатывается...
Отправляется (Кофе)

Имеется также возможность возвратить анонимную функцию из метода, как
показано ниже.
// Листинг 04.94

class Totalizer

{
public static function warnAmount()

{

return function (Product $product) {
if ($product->price > 5) {
print ” покупается дорогой товар:

{$product->price}\n”;

}
};

}
}
// Листинг 04.95
$processor = new ProcessSale();
$processor->registerCallback(Totalizer::warnAmount());
// ...

В данном примере нет ничего интересного, кроме того, что метод
warnAmount () используется в качестве фабрики анонимной функции (т.е. в нем
создается анонимная функция). Тем не менее подобная структура позволяет сде
лать нечто гораздо большее, чем просто сгенерировать анонимную функцию.
Она позволяет выгодно воспользоваться механизмом замыканий. В анонимной
функции нового типа могут использоваться переменные, объявленные в другой
анонимной функции, находящейся в родительской области видимости. Это до
вольно сложный принцип, чтобы понять его сразу.
Вкратце его можно объяснить так, как будто анонимная функция запоминает
контекст, в котором она была создана. Предположим, нам нужно сделать так,
чтобы метод Totalizer: :warnAmount () выполнял следующее. Во-первых,
мы хотим, чтобы методу можно было передавать пороговое значение стоимости
проданных товаров. Во-вторых, нам нужно, чтобы он подсчитывал стоимость
(т.е. сумму цен) проданных товаров. И когда стоимость проданных товаров пре
высит установленный порог, функция должна выполнить некоторые действия
(в нашем случае, как вы уже можете догадаться, она просто выведет соответ
ствующее сообщение).
Чтобы в анонимной функции можно было отслеживать переменные, опре
деленные в более обширной (родительской) области видимости, используется
ключевое слово use, как показано в приведенном ниже примере.

146

ЧАСТЬ II « ОБЪЕКТЫ

// Листинг 04.96

class Totalizer2
{

public static function warnAmount($amt)
{

$count = 0;
return function ($product) use ($amt, &$count) {
$count += $product->price;
print ’’ сумма: $count\n”;
if ($count > $amt) {
print "\n Продано товаров на сумму: {$count}\n";
}

};

}
}
// Листинг 04.97

$processor = new ProcessSale();
$processor->registerCallback(Totalizer2::warnAmount(8) ) ;
$processor->sale (new Product("Туфли", 6));
print "\n";
$processor->sale(new Product("Кофе", 6));

В директиве use анонимной функции, которая возвращается методом Totali
zer: : warnAmount (), указаны две переменные. Первой из них является пере
менная $amt, которая передается в качестве аргумента методу warnAmount (),
а вторая — замыкаемая переменная $ count. Она объявлена в теле метода
warnAmount (), и начальное ее значение равно нулю. Обратите внимание на то,
что перед именем переменной $ count в директиве use указан символ ампер
санда ' & ’. Это означает, что данная переменная будет передаваться анонимной
функции по ссылке, а не по значению. Дело в том, что в теле анонимной функ
ции к ее значению прибавляется цена товара, а затем новая сумма сравнивается
со значением переменной $amt. Если достигнуто запланированное значение, то
выводится соответствующее сообщение, как показано ниже.
Туфли: обрабатывается...
сумма: 6

Кофе: обрабатывается...
сумма: 12
Продано товаров на сумму: 12

В данном примере было показано, что значение переменной $ count сохра
няется между вызовами функции обратного вызова. Обе переменные, $ count и
$amt, остаются связанными с этой функцией, поскольку они указаны в контек
сте ее объявления и указаны в директиве use.

ГЛАВА 4 S РАСШИРЕННЫЕ СРЕДСТВА

147

Анонимные классы
Начиная с версии РНР 7 можно объявлять не только анонимные функции,
но и классы. Анонимные классы очень удобны в тех случаях, когда требуется
создать экземпляр небольшого класса. Такая возможность оказывается особенно
удобной, если класс является простым и характерным для локального контекста.
Вернемся к примеру класса Personwriter, начав на этот раз с создания
интерфейса следующим образом:
// Листинг 04.98
interface Personwriter
{

public function write(Person Sperson);
}

Ниже приведена новая версия класса Person, в котором можно воспользо
ваться объектом типа Personwriter.
// Листинг 04.99
class Person

{
public function output(PersonWriter $writer)

{

$writer->write($this);
}

public function getName():

string

{

return "Иван”;
}

public function getAge():

int

{

return 44;
}

}

В данном примере методу output () в качестве аргумента передается эк
земпляр объекта типа PersonWriter, методу write () которого передается эк
земпляр текущего класса. Благодаря такому решению класс Person аккуратно
отделяется от реализации средства вывода на экран, которое переносится в кли
ентский код.
Если же в клиентском коде потребуется вывести на экран имя и возраст из
объекта типа Person, для этого достаточно создать класс PersonWriter обыч
ным образом. Но в нашем случае это будет настолько простая реализация, что
с таким же успехом можно было бы создать класс и сразу же передать его объ
екту типа Person, как показано ниже.

148

ЧАСТЬ II » ОБЪЕКТЫ

// Листинг 04.100

$person = new Person();
$person->output(
new class implements Personwriter {
public function write(Person $person)
{
print $person->
getName(). " " . $person->getAge()
}
}
) ;

.

”\n”;

Как видите, анонимный класс можно объявить с помощью ключевых слов
new class, после которых указываются требуемые операторы расширения
extends и реализации implements, как и при создании обычного класса на
основе другого класса и реализации методов требуемого интерфейса. Далее сле
дует блок кода этого класса. По сути сразу после объявления анонимного клас
са неявно будет создан его экземпляр и передан в качестве параметра методу
output() .
В анонимных классах замыкания не поддерживаются. Иными словами, пе
ременные, объявленные в более обширной (родительской) области видимости,
в анонимном классе будут недоступны. Но в то же время конструктору ано
нимного класса можно передать их значения. В качестве примера создадим
немного более сложный анонимный класс, в котором реализуется интерфейс
Personwriter.
// Листинг 04.101
Sperson = new Person ();
$person->output(
new class(”/tmp/persondump")
private $path;

implements Personwriter

{

public function __ construct(string $path)
{

$this->path = $path;

}
public function write(Person $person)
(
file_put_contents($this->path,
$person->getName().
$person->getAge() .
}

" ” .
”\n");

}

) ;

В данном примере конструктору анонимного класса передается строковый
аргумент $path, содержащий имя файла. Это значение сохраняется в свойстве
$path данного класса и в конечном итоге используется в методе write () для
записи информации из объекта в файл.

ГЛАВА 4

РАСШИРЕННЫЕ СРЕДСТВА

149

Безусловно, если анонимный класс начинает разрастаться и усложняться, то
целесообразнее создать именованный класс в соответствующем файле класса.
Это особенно справедливо, если анонимный класс приходится дублировать в
нескольких местах11.

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

11 Ради читаемости программы настоятельно рекомендуем отказаться от использования
анонимных классов и всегда пользоваться именованными классами. Иначе через какое-то
время ваша красивая и строгая объектно-ориентированная PHP-программа превратится в
“лапшу” наподобие JavaScript-кода, разобраться в котором не смогут даже сами разработчи
ки по прошествии некоторого времени. — Примеч. ред.

ГЛАВА 5

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

в Пространства имен. Организация прикладного кода в отдельные пакето
подобные структуры.
Пути включения файлов. Позволяют указать места централизованного
хранения библиотечного кода.
ш Функции для исследования классов и объектов. Предназначены для тести
рования объектов, классов, свойств и методов.
ж Интерфейс Reflection API. Эффективный набор встроенных классов, обе
спечивающий беспрецедентный доступ к информации о классе во время
выполнения программы.

РНР и пакеты
Пакет — это набор связанных классов, обычно сгруппированных вместе
некоторым образом. Пакеты можно использовать для разделения частей систе
мы на логические компоненты. В некоторых языках программирования пакеты
распознаются формально, и для них создаются различные пространства имен.
А в языке РНР такого понятия, как пакет, никогда не существовало, но начиная
с версии РНР 5.3 в нем поддерживаются пространства имен. Такая возможность
будет рассмотрена в следующем разделе. Кроме того, следует хотя бы вкратце
описать прежний способ организации классов в пакетоподобные структуры.

152

ЧАСТЬ II

ОБЪЕКТЫ

Пакеты и пространства имен в РНР
Несмотря на то что концепция пакетов в РНР внутренне не поддерживалась,
разработчики традиционно использовали различные схемы именования и фай
ловую систему для организации своего кода в пакетоподобные структуры. До
появления версии РНР 5.3 разработчики были вынуждены подбирать для файлов
и классов своего проекта однозначные имена, поскольку с точки зрения интер
претатора все они находились в одном глобальном контексте. Иными словами,
если вы, например, определяли класс ShoppingBasket, он сразу же становился
доступным всему вашему приложению. Это порождало две главные проблемы.
Первая и самая неприятная была связана с потенциальным конфликтом имен в
проекте. Но такой конфликт может показаться маловероятным. Ведь достаточ
но было помнить, что всем классам необходимо назначить однозначные имена!
Но проблема состояла в том, что в своих проектах нам все чаще приходилось
пользоваться библиотечным кодом. Это очень удобно, поскольку способствует
повторному использованию кода. Но допустим, что в проекте используется сле
дующая конструкция:
// Листинг 05.01
require_once__ DIR__

.

”/../useful/Outputter.php'’;

class Outputter

{
// вывести данные

}

Допустим также, что в проект внедряется следующий файл, включаемый по
пути useful/Outputter.php:
// Листинг 05.02
class Outputter

{

//
}

Нетрудно догадаться, что это приведет к следующей неустранимой ошибке:
РНР Fatal error: Cannot declare class Outputter because the name is already in
use in useful/Outputter.php on line 4.1

До внедрения пространств имен существовал традиционный обходной прием
для разрешения подобного затруднения. Он состоял в том, чтобы указать имя
пакета перед именем класса и тем самым гарантировать однозначность имен
классов:
1 Неустранимая ошибка в РНР: нельзя переопределить класс Outputter, поскольку его
имя уже используется в строке кода 4 из исходного файла useful/Outputter.php.

ГЛАВА 5 8 СРЕДСТВА ДЛЯ РАБОТЫ С ОБЪЕКТАМИ

153

// Листинг 05.03
// my/Outputer.php

require_once__ DIR__

.

"/../useful/Outputter.php”;

class my_Outputter
{

// вывести данные
}

// Листинг 05.04
// useful/Outputter.php

class useful_Outputter
{

//
}

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

Пространства имен появились в версии РНР 5.3. По существу, они представ
ляют собой корзину, в которую можно поместить классы, функции и перемен
ные. К ним можно обращаться в пределах одного пространства имен безо вся
кого уточнения. А для того чтобы обратиться к этим элементам за пределами
пространства имен, придется импортировать целое пространство имен или вос
пользоваться ссылкой на него.
Не понятно? Поясним на конкретном примере. Ниже приведен предыдущий
пример кода, переделанный с помощью пространств имен.
// Листинг 05.05

namespace my;
require_once __ DIR__

class Outputter

{
// вывести данные

.

/useful/Outputter.php”;

154

ЧАСТЬ II * ОБЪЕКТЫ

// Листинг 05.06

namespace useful;
class Outputter
{
//
}

Обратите внимание на ключевое слово namespace. Как вы, вероятно, дога
дались, оно устанавливает указанное пространство имен. При использовании
пространств имен в коде их объявление должно быть выполнено в первом опе
раторе исходного файла. В приведенном выше примере созданы два простран
ства имен: ту и useful. Но зачастую в прикладных программах употребляются
более длинные пространства имен. Как правило, они начинаются с названия
организации или проекта, а далее указывается название пакета. В языке РНР до
пускаются вложенные пространства имен. Для их разделения на уровни служит
знак обратной косой черты ' \', как показано ниже.
// Листинг 05.07

namespace popp\ch05\batch04\util;
class Debug
{
public static function helloWorld()
{
print "Ответ из Debug\n";
}
}

Для организации информационного хранилища обычно выбирается имя, свя
занное с разрабатываемым программным продуктом или организацией. С этой
целью можно выбрать один из доменов (например, getinstance.com), по
скольку доменное имя однозначно определяет его владельца. Программирующие
на Java зачастую обозначают доменными именами свои пакеты, указывая их в
обратном порядке: от общего к частному. Но для примеров кода из данной кни
ги выбрано пространство имен рорр, сокращенно обозначающее название этой
книги на английском языке. Итак, выбрав имя для информационного хранили
ща, можно перейти к именам пакетов. В данном случае имя пакета состоит из
обозначения главы книги и номера группы. Это дает возможность организовать
группы примеров кода в отдельные корзины. Например, текущие примеры кода
из этой главы находятся в пакете popp\ch05\batch04. И, наконец, исходный
код можно организовать по категориям, указав дополнительно слово util.
Как же теперь вызвать метод? На самом деле все зависит от того, в каком
контексте это делается. Так, если метод вызывается из текущего пространства
имен, то все происходит, как и прежде, т.е. метод вызывается непосредственно,
как показано ниже.
Debug::helloWorld() ;

ГЛАВА 5 в СРЕДСТВА ДЛЯ РАБОТЫ С ОБЪЕКТАМИ

155

Это так называемое неуточненное имя класса. Ведь мы и так находимся в
пространстве имен popp\ch05\batch04\util, и поэтому нам не нужно указы
вать перед именем класса какой-нибудь путь к нему. Если же требуется вызвать
метод из данного класса за пределами текущего пространства имен, это придет
ся сделать следующим образом:
\popp\ch05\batch04\Debug::helloworld();

Как вы думаете, каким будет результат выполнения приведенного ниже фраг
мента кода?
namespace main;

popp\ch05\batch04\Debug::helloWorld();

Это непростой вопрос. На самом деле будет получено следующее сообщение
об ошибке:
РНР Fatal error: Class ’popp\ch05\batch04\Debug’ not found in...2

Причина в том, что в данном коде использовано относительное имя про
странства имен. Интерпретатор РНР попытается найти в текущем пространстве
имен main имя popp\ch05\batch04\util и не сможет его обнаружить. Чтобы
устранить этот недостаток, следует указать абсолютное имя пространства имен.
Это делается таким же образом, как и при указании абсолютных путей к фай
лам и URL. С этой целью перед названием пространства имен следует указать
разделительный знак ’ \ ’, как показано ниже. Именно этот начальный знак об
ратной косой черты и сообщает интерпретатору РНР, что поиск классов следует
начинать не с текущего, а с корневого пространства имен.
namespace main;
\popp\ch05\batch04\Debug::helloWorld();

Но разве введение пространств имен не должно было сократить имена клас
сов и упростить набор исходного кода? Безусловно, имя класса Debug очень
краткое и понятное, но такой “многословный” вызов метода из этого класса
получился потому, что в данном случае было употреблено прежнее соглашение
об именовании файлов. Дело можно упростить, воспользовавшись ключевым
словом use. Оно позволяет снабжать псевдонимами другие пространства имен
в текущем пространстве имен, как показано в следующем примере кода:
namespace main;
use popp\ch05\batch04\util;
util\Debug;:helloWorld();

2 Неустранимая ошибка в PHP: класс ’popp\ch05\batch04\Debug' не найден в...

156

ЧАСТЬ II

ОБЪЕКТЫ

В данном примере импортируется пространство имен popp\ch05\batch04\
util, которое неявно снабжается псевдонимом util. Обратите внимание на то,
что имя этого пространства имен не предваряетсязнаком обратной косой чер
ты. Дело в том, что поиск пространства имен, указанного в качестве аргумента
в операторе use, начинается с глобального, а не текущего пространства имен.
Если же из нового пространства имен требуется только класс Debug, можно
импортировать только его, а не все пространство в целом, как показано ниже.
namespace main;
use popp\ch05\batch04\util\Debug;
Debug::helloWorld();

Это наиболее часто употребляемое соглашения об именовании файлов. Но
что произойдет, если в пространстве имен main уже определен другой класс
Debug? В качестве примера ниже приведен такой класс.
// Листинг 05.08
namespace popp\ch05\batch04;

class Debug
{
public static function helloWorld ()
{
print "Ответ из popp\\ch05\\batch04\\Debug\n";
}
}

А вот как выглядит вызывающий код из пространства имен popp\ch05\
batch04, в котором происходит обращение к обоим классам Debug:
namespace popp\ch05\batch04;
use popp\ch05\batch04\util\Debug;
use popp\ch05\batch04\Debug;
Debug::helloWorld();

Как и следовало ожидать, выполнение этого фрагмента кода приведет к сле
дующей неустранимой ошибке:
РНР Fatal error: Cannot use popp\ch05\batch04\Debug as Debug because the name is
already in use in...3

Похоже, что круг замкнулся, и мы снова вернулись к конфликту имен клас
сов. Правда, из подобного затруднения нетрудно выйти, явно указав псевдоним
класса, как показано ниже.
namespace main;
use popp\ch05\batch04\Debug as coreDebug;
coreDebug::helloWorld();

3 Неустранимая ошибка в PHP: нельзя использовать класс
по имени Debug, потому что это имя уже используется в...

popp\ch05\batch04\Debug

СРЕДСТВА ДЛЯ РАБОТЫ С ОБЪЕКТАМИ

ГЛАВА 5

157

Воспользовавшись ключевым словом as в операторе use, мы изменили
явным образом псевдоним класса Debug на core Debug. Если вы пишете код
в текущем пространстве имен и хотите обратиться к классу, находящемуся в
глобальном (без имени) пространстве, просто укажите перед его именем знак
обратной косой черты. Ниже приведен пример класса, определенного в глобаль
ном пространстве.
// Листинг 05.09
class Lister

{
public static function helloWorld ()

{
print "Ответ из глобального пространства имен\п";

}
}

А вот пример кода, написанного в том пространстве имен, где используется
данный класс.
// Листинг 05.10
namespace popp\ch05\batch04\util;
class Lister

{
public static function helloWorld ()
{

print "Ответ из "

. __ NAMESPACE__

.

"\n";

}

}

// Листинг 05.11
namespace popp\ch05\batch04;
Lister::helloWorld (); // вызов локального метода
\Lister::helloWorld (); // вызова метода из глобального пространства имен

В коде из локального пространства имен объявлен собственный класс Lister.
Для доступа к его локальной версии из клиентского кода в том же самом про
странстве имен используется неуточненное имя. Если же имя класса уточнено с
помощью начального знака обратной косой черты, то обращение происходит к
классу, находящемуся в глобальном пространстве имен. Ниже приведен резуль
тат выполнения предыдущего фрагмента кода.
Ответ из popp\ch05\batch04\util
Ответ из глобального пространства имен

158

ЧАСТЬ II

ОБЪЕКТЫ

Это очень ценный пример, поскольку в нем наглядно показано, как пользо
ваться константой__ NAME SPACE__ . Она содержит имя текущего пространства
имен, что может очень пригодиться при отладке кода.
С помощью описанного выше синтаксиса можно определить несколько про
странств имен в одном файле. Можно также употребить альтернативный син
таксис, где после ключевого имени name space и названия пространства имен
указываются фигурные скобки, в которые заключается блок кода.
// Листинг 05.12

namespace com\getinstance\util {

class Debug

{

public static function helloWorld ()
{
print "Ответ из Debug\n";
}

}
}

namespace other {

\com\getinstance\util\Debug::helloWorld ();

}

Если вам приходится объединять несколько пространств имен в одном фай
ле, то второй синтаксис предпочтительнее. Хотя в одном файле обычно реко
мендуется определять только одно пространство имен.
НА ЗАМЕТКУ. В одном файле нельзя употреблять оба упомянутых выше синтаксиса

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

Независимо от используемой версии РНР классы можно упорядочивать с по
мощью файловой системы, которая отдаленно напоминает пакетную структуру.
Например, можно создать каталоги util и business и включать находящие
ся в них файлы классов с помощью оператора require once () следующим
образом:
require_once(’business/Customer.php');
require_once(’util/WebTools.php');

С тем же успехом можно также употребить оператор include once (). Един
ственное отличие операторов require once () и include once () заключает
ся в обработке ошибок. Файл, к которому происходит обращение с помощью
оператора require once (), приведет к остановке всего процесса выполнения

ГЛАВА 5 « СРЕДСТВА ДЛЯ РАБОТЫ С ОБЪЕКТАМИ

159

программы, если в нем возникнет ошибка. Аналогичная ошибка, обнаруженная
в результате вызова оператора include once (), приведет лишь к выдаче пред
упреждения и прекращению выполнения включаемого файла, после чего выпол
нение вызвавшего его кода будет продолжено. Поэтому операторы require ()
и require once () надежнее выбирать для включения библиотечных файлов,
а операторы include () и include_once () лучше подходят для выполнения
таких операций, как шаблонная обработка.
НА ЗАМЕТКУ. Синтаксические конструкции require () и require_onceО на самом

деле являются операторами, а не функциями. Это означает, что при их использовании
можно опускать скобки. Лично я предпочитаю использовать скобки в любом случае.
Но если вы последуете моему примеру, будьте готовы, что вам будут надоедать пе
данты, которые не преминут указать вам на ошибку,

На рис. 5.1 показано, как выглядят пакеты util и business в диспетчере
файлов Nautilus.
v

packages
business

0
0

Customer, php
Invoice.php
util

0

WebTods.php

Рис. 5.1. Пакеты РНР, организованные в файловой системе

НА ЗАМЕТКУ. Оператору require_once () передается путь к файлу, содержащему код

РНР, который будет включен в текущий сценарий и выполнен в нем. Включение ука
занного файла в текущий сценарий выполняется только один раз, и если этот файл
был ранее включен в сценарий, то повторное его включение не происходит. Такой
однократный подход особенно удобен при доступе к библиотечному коду, поскольку
тем самым предотвращается случайное переопределение классов и функций. Подоб
ная ситуация может возникнуть в том случае, если один и тот же файл включается в
разные части сценария, выполняющегося в одном процессе с помощью оператора
require () ИЛИ include ().
Обычно предпочтение отдается операторам require () и require_once (), а не
сходным с ними операторам included и include_once(). Дело в том, что неу
странимая ошибка, обнаруженная в файле, к которому происходит обращение с по
мощью оператора required , приведет к остановке всего сценария. Аналогичная
ошибка, обнаруженная в файле, к которому происходит обращение с помощью опе
ратора included, прервет выполнение включаемого файла, но в вызывающем
сценарии будет только сгенерировано предупреждение. Первый вариант считается
более безопасным, хотя и более радикальным.

160

ЧАСТЬ II ж ОБЪЕКТЫ

Применение оператора require_once() требует определенных издержек по срав
нению с оператором require (). Если требуется сократить до минимума время вы
полнения сценария, то лучше воспользоваться оператором require (). И как часто
бывает, приходится выбирать между эффективностью и удобством.
Что касается РНР, то в такой организации файлов нет ничего особенного. Би
блиотечные сценарии просто размещаются в разных каталогах, что придает про
екту четкую организацию. При этом пространствами имен или соглашениями
об именовании файлов и файловой системой можно пользоваться параллельно.
Именование в стиле PEAR

До внедрения пространств имен разработчики вынуждены были прибегать к
определенным соглашениям об именовании файлов, чтобы исключить их кон
фликты. К числу наиболее употребительных среди них относится фальшивая
организация пространств имен, которой придерживались разработчики PEAR.
НА ЗАМЕТКУ. Сокращение PEAR означает РНР Extension and Application Repository (Хра

нилище расширений и приложений РНР). Это официально поддерживаемый архив па
кетов и средств, расширяющих функциональные возможности РНР Основные пакеты
PEAR включены в дистрибутив РНР, а другие пакеты можно добавить с помощью про
стой утилиты командной строки. Просмотреть список пакетов PEAR можно по адресу
http: / /pear. php. net.

Для определения пакетов в PEAR используется файловая система, как по
яснялось выше. До внедрения пространств имен каждый класс получал имя,
исходя из пути к нему, где имена каталогов отделялись знаком подчеркивания.
Например, в PEAR включен пакет под именем XML, в который вложен пакет
RPC. В пакете RPC имеется исходный файл, который называется Server.php.
Класс, определенный в исходном файле Server.php, не называется Server,
как можно было ожидать. В противном случае рано или поздно произошел бы
конфликт с другим классом Server, находящимся в каком-нибудь другом па
кете PEAR или пользовательском коде. Чтобы этого не произошло, класс на
зван XML RPC Server. С одной стороны, имена классов, безусловно, становят
ся слишком громоздкими и малопривлекательными. А с другой стороны, код
становится более удобочитаемым, потому что имя класса всегда описывает его
контекст.

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

ГЛАВА 5 в СРЕДСТВА ДЛЯ РАБОТЫ С ОБЪЕКТАМИ

161

(для текущего рабочего каталога) или полный путь к этому файлу в используе
мой файловой системе.
НА ЗАМЕТКУ. Важно не только понимать принцип действия путей включения файлов и

разбираться в вопросах предоставления требующихся файлов, но также иметь в виду,
что во многих современных системах уже не используются операторы require для
каждого класса. Вместо этого в них применяются пространства имен в определенном
сочетании с автозагрузкой классов. Об автозагрузке речь пойдет ниже, а более под
робные сведения о ней, практические рекомендации и инструментальные средства
представлены в главах 15, “Стандарты РНР”, и 16, “Создание и использование ком
понентов РНР средствами Composer”.
В приведенных до сих пор примерах порой указывалось фиксированное от
ношение между требующими и требуемыми файлами:
require_once(__ DIR__

.

’/../useful/Outputter.php’);

Такой прием вполне работоспособен, за исключением жесткого кодирования
отношений между файлами. В данном случае подразумевается непременное на
личие каталога useful наряду с каталогом, содержащим вызывающий класс.
Вероятно, хуже способа, чем указать запутанный относительный путь вроде
приведенного ниже, трудно придумать.
require_once(’../../projectlib/business/User.php');

Недостаток такого способа заключается в том, что путь указан не относи
тельно того файла, в котором содержится оператор require once (), а отно
сительно сконфигурированного вызывающего контекста, которым нередко, хотя
и не всегда, оказывается текущий рабочий каталог. Такие пути к файлам слу
жат источником недоразумений и почти всегда, как показывает опыт, указывают
явно на то, что система требует значительного усовершенствования и в других
местах.
Безусловно, можно указать и абсолютный путь к файлу, как в следующем
примере:
require_once(’/home/john/projectlib/business/User.php’);

Так можно поступить лишь один раз, но это негибкий подход. Ведь указывая
пути настолько подробно, можно заморозить библиотечный файл в конкретном
контексте. И всякий раз, когда проект устанавливается на новом сервере, при
дется вносить изменения во все операторы require с учетом нового пути к
файлу. В итоге библиотеки трудно будет переносить и практически невозмож
но сделать их общими для разных проектов, не прибегнув к их копированию.
Но в любом случае теряется смысл в размещении пакетов во всех дополни
тельных каталогах, поскольку неясно, о каком пакете идет речь: business или
projectlib/business?

162

ЧАСТЬ II а ОБЪЕКТЫ

Если требуется включить файлы в свой код вручную, то лучше всего отвязать
вызывающий код от библиотеки. Так, по следующему пути:
business/User.php

можно обращаться к библиотечному файлу в любом месте файловой системы.
Это можно сделать, используя пути включения файла — список каталогов, в ко
тором интерпретатор РНР осуществляет поиск, когда потребуется данный файл.
Такой список каталогов можно ввести в директиву include_path, которая обыч
но задается в файле php.ini — главном файле конфигурации РНР. Каталоги пе
речисляются в этой директиве через двоеточие (в UNIX-подобных системах) или
через точку с запятой (в системе Windows), как показано ниже.
include_path =

/usr/local/lib/php-libraries"

Если используется веб-сервер Apache, директиву include path можно ука
зать в глобальном файле конфигурации сервера, который обычно называется
httpd.conf, или в файле конфигурации для конкретного каталога, который
обычно называется .htaccess, употребив следующий синтаксис:
php_value include_path ".:/usr/local/lib/php-libraries"

НА ЗАМЕТКУ. Файлы конфигурации .htaccess обычно используются на веб-серверах

ряда поставщиков услуг хостинга, которые сильно ограничивают права доступа поль
зователей к своим серверам.

Если при указании неабсолютного пути к файлу в таких функциях и опера
торах обращения к файловой системе, как f open () или require (), этот файл
не находится в иерархии текущего рабочего каталога, его поиск автоматически
выполняется в каталогах, включенных в путь поиска, начиная с первого ката
лога в списке. Чтобы активизировать такой режим поиска в функции fopen(),
в список ее аргументов следует включить специальный флаг. И если искомый
файл найден, поиск прекращается и соответствующая функция или оператор
завершает свою работу.
Поэтому, размещая каталог с пакетами во включаемом каталоге, достаточно
указать в операторах require () имя файла и название пакета:
require_once("business/User.php");

Чтобы поддерживать собственный библиотечный каталог, добавьте его имя
в директиву include path, отредактировав файл конфигурации php.ini.
Если вы пользуетесь серверным модулем РНР, не забудьте перезагрузить сервер
Apache, чтобы изменения вступили в силу.
Если у вас нет прав доступа для редактирования файла конфигурации php.
ini, задайте пути включения файлов непосредственно из сценария с помощью
функции set include path (). Этой функции передается список каталогов

ГЛАВА 5

СРЕДСТВА ДЛЯ РАБОТЫ С ОБЪЕКТАМИ

163

(в том же виде, что и для файла конфигурации php.ini), который заменяет
список, указанный в директиве include_path для текущего процесса. В файле
конфигурации php.ini, вероятно, уже определено подходящее значение для ди
рективы include path, и вместо того чтобы затирать его, можете получить его
с помощью функции get include path (), добавив к нему свой каталог. Ниже
показано, как добавить каталог в текущий путь включения файлов.
set_include_path( get_include_path()
. PATH_SEPARATOR . "/home/john/phplib/") ;

Вместо константы PATH SEPARATOR будет подставлен знак разделения спи
ска каталогов, принятый в текущей операционной системе. Напомним, что в
Unix — это двоеточие (:), а в Windows — точка с запятой (;). Пользоваться
константой PATH SEPARATOR рекомендуется из соображений переносимости
кода как передовой нормой практики программирования.

Автозагрузка
Несмотря на все преимущества применения оператора require once ()
вместе с путями включения файлов многие разработчики избегают операторов
require, используя вместо них автозагрузку. Для этого классы необходимо ор
ганизовать таким образом, чтобы каждый из них размещался в отдельном исход
ном файле. Имя каждого такого файла должно быть непосредственно связано
с именем класса, который в нем содержится. Например, класс ShopProduct
можно определить в исходном файле ShopProduct.php и поместить в каталог,
соответствующий пространству имен данного класса.
Для автоматизации процесса включения в программу файлов классов в РНР,
начиная с версии 5, предусмотрена возможность их автозагрузки. Ее стандарт
ная реализация очень проста, но от этого она не становится менее полезной.
Для этого достаточно вызвать функцию spl autoload register () без па
раметров. После этого активизируется средство автозагрузки классов, которое
автоматически вызывает функцию spl autoload () при попытке получить эк
земпляр неизвестного класса. В качестве параметра функции spl autoload ()
передается имя неизвестного класса, которое затем преобразуется в имя файла.
Для этого имя класса преобразуется в нижний регистр букв и по очереди до
полняется всеми зарегистрированными стандартными расширениями (сначала
. inc, а затем .php). Далее функция пытается загрузить содержимое указанного
файла в программу, полагая, что в нем должно содержаться определение неиз
вестного класса. Ниже приведен простой пример организации автозагрузки.
spl_autoload_register ();
$writer = new Writer();

Если в программу еще не включен файл с определением класса Writer, то
при попытке получить экземпляр этого класса возникнет исключительная ситуа
ция. Но поскольку ранее был установлен режим автозагрузки, то интерпретатор

164

ЧАСТЬ II в ОБЪЕКТЫ

РНР попытается включить в программу сначала файл writer, inc, а затем —
writer.php, если первый файл обнаружить не удалось. Если во включаемом
файле содержится определение класса Writer, интерпретатор снова попытается
создать его экземпляр и выполнение программы продолжится.
В стандартной реализации автозагрузки поддерживаются пространства имен,
причем имя пакета считается именем каталога. Поэтому при выполнении при
веденного ниже фрагмента кода интерпретатор РНР будет искать файл writer,
php в каталоге util (обратите внимание на указание имени файла в нижнем
регистре).
spl_autoload_register();
$writer = new util\Writer();

Но что, если в именах файлов классов должен учитываться регистр букв (т.е.
в них могут быть как прописные, так и строчные буквы)? Так, если определе
ние класса Writer будет размещено в файле Writer.php, то при стандартной
реализации автозагрузки файл этого класса не будет найден.
Правда, имеется возможность зарегистрировать специальную функцию ав
тозагрузки, чтобы принимать во внимание другие соглашения об именовании
файлов. Для этого достаточно передать функции spl autoload register ()
ссылку на специальную или анонимную функцию. Такой функции автозагрузки
должен передаваться единственный параметр. И тогда при попытке получить
экземпляр неизвестного класса интерпретатор РНР вызовет специальную функ
цию автозагрузки, передав ей в качестве строкового параметра имя искомого
класса. При этом в функции автозагрузки придется самостоятельно реализовать
стратегию поиска и включения в программу нужных файлов классов. После вы
зова специальной функции автозагрузки интерпретатор РНР снова попытается
получить экземпляр указанного класса.
Ниже приведен простой пример функции автозагрузки вместе с загружаемым
файлом.
// Листинг 05.13

class Blah
{

public function wave()
{
print "Ответ из корневого класса";
}
}

// Листинг 05.14
$basic = function ($classname) {
$file = __ DIR__ . "/" . " { $classname} .php";
if (file_exists(Sfile)) {
require_once($file);
}

};

ГЛАВА 5 ■»- СРЕДСТВА ДЛЯ РАБОТЫ С ОБЪЕКТАМИ

165

\spl_autoload_register($basic);
$blah = new Blah () ;
$blah->wave();

После первоначальной неудачной попытки создать экземпляр класса Blah
интерпретатор РНР обнаружит, что с помощью функции spl_autoload_
register () была зарегистрирована специальная функция автозагрузки, кото
рой в качестве параметра было передано имя данного класса, указанное в сим
вольной строке ’’Blah". В данной реализации мы просто пытаемся включить в
программу файл Blah.php. Это, конечно, получится лишь в том случае, если
включаемый файл находится в том же каталоге, где и файл, в котором объявле
на функция автозагрузки. Но на практике конфигурирование путей включения
файлов придется сочетать с логикой автозагрузки. Именно такая методика при
меняется для реализации автозагрузки в диспетчере зависимостей Composer.
Если же требуется обеспечить поддержку устаревших соглашений об име
новании файлов, процесс включения пакетов PEAR можно автоматизировать
следующим образом:
// Листинг 05.15
class util_Blah

{
public function wave()

{
print "Ответ из файла с подчеркиванием";
}
}

// Листинг 05.16
$underscores = function ($classname) {
$path = str_replace(, DIRECTORY_SEPARATOR,
$path = __ DIR__ . ”/$path";
if (file_exists(”{$path}.php")) {
requi re_once("{$path}.php");

$classname);

}
};
\spl_autoload_register ($underscores);

$blah = new util_Blah();
$blah->wave();

Как видите, функция автозагрузки преобразует знаки подчеркивания, содержа
щиеся в переданном ей аргументе $classname, в знак разделения каталогов, за
данный в константе DIRECTORY SEPARATOR (' /' для Unix и ' \' для Windows).
Затем мы пытаемся включить в программу файл класса util/Blah.php. Если
такой файл существует и класс, который в нем содержится, был назван верно, то
экземпляр объекта будет получен без ошибок. Разумеется, для этого необходимо,

166

ЧАСТЬ II

ОБЪЕКТЫ

чтобы программист соблюдал соглашение об именовании файлов, которое запре
щает употребление знака подчеркивания в именах классов, за исключением тех
случаев, когда этот знак служит для разделения пакетов.
А как быть с пространствами имен? Как упоминалось выше, пространства
имен поддерживаются в стандартной реализации автозагрузки. Но, если мы за
меняем стандартную реализацию собственной, обязанность поддерживать про
странства имен полностью возлагается на нас. Для этого достаточно проверить
наличие в длинном имени класса знаков обратной косой черты и заменить их
знаком разделения каталогов, принятым в используемой операционной системе:
// Листинг 05.17

namespace util;

class LocalPath
{

public function wave()

{
print "Ответ из ".get_class();
}
}
// Листинг 05.18

$namespaces = function (Spath) {
if (preg_match(’/\\\\/’, Spath)) {
Spath = str_replace('\\', DIRECTORY_SEPARATOR, Spath);
}
if (file_exists("{Spath}.php"))
require_once("{Spath}.php");

{

}

};
\spl_autoload_register(Snamespaces);

Sobj = new util\LocalPath();
Sobj->wave();

Значение, передаваемое функции автозагрузки, всегда нормализовано и со
держит полностью уточненное имя класса без начального знака обратной косой
черты. Поэтому в момент получения экземпляра класса можно не беспокоиться
о его псевдониме или относительной ссылке на пространство имен.
Но что, если требуется поддерживать при автозагрузке как именование клас
сов в стиле PEAR, так и пространства имен? Для этого достаточно объединить
реализацию двух приведенных выше функций автозагрузки в одну функцию или
воспользоваться стеком функций автозагрузки, который организуется в функции
spl autoload register (), как показано ниже. Когда интерпретатор РНР обна
ружит неизвестный класс, он вызовет сначала функцию replaceUnderscores (),
а затем функцию myNamespaceAutoload (), если после вызова первой функции
определение нужного класса все еще не будет найдено.

ГЛАВА 5 ив СРЕДСТВА ДЛЯ РАБОТЫ С ОБЪЕКТАМИ

167

// Листинг 05.19

\spl_autoload_register($namespaces);
\spl_autoload_register($undeгscores);
$blah = new util_Blah() ;
$blah->wave();
$obj = new util\LocalPath ();
$obj->wave();

Очевидно, что при использовании описанного выше стека функций автоза
грузки производительность снижается из-за высоких накладных расходов. Так
почему же он все-таки поддерживается в РНР? Дело в том, что в реальных
проектах зачастую пространства имен сочетаются с именами классов, разделя
емыми знаком подчеркивания. Но в некоторых компонентах крупных систем и
сторонних библиотеках может возникнуть потребность реализовать собствен
ный механизм автозагрузки. Поддержка стека функций автозагрузки как раз
позволяет зарегистрировать независимые механизмы автозагрузки, которые не
мешают друг другу. На самом деле библиотека, в которой требуется лишь крат
ковременно воспользоваться механизмом автозагрузки, может передать имя сво
ей специальной функции автозагрузки (или ссылку на нее, если она анонимная)
в качестве параметра функции spl_autoload_unregister(), чтобы удалить
ее из стека и таким образом произвести самоочистку!
НА ЗАМЕТКУ. В языке РНР поддерживается также устаревшая и менее гибкая функция

autoload () для автозагрузки файлов классов. Если в вашем проекте реализова
на именно эта функция, интерпретатор РНР вызовет ее, не найдя определение клас
са. Но поскольку при использовании данной функции не организуется описанный
выше стек автозагрузки, то поддержка функции autoload() в будущих версиях
РНР не гарантируется. Ели же обнаружится, что функция
autoload() перестанет
вызываться интерпретатором РНР или если требуется обеспечить работоспособность
стека автозагрузки, вызовите функцию spl_autoload_register() и передайте
ей в качестве параметра строку 1 autoload1, как показано ниже.
spl autoload register(’autoload’);

Функции для исследования классов и объектов
В языке РНР предусмотрен широкий набор функций для проверки классов и
объектов. Для чего это нужно? Вы ведь, скорее всего, сами создали большин
ство классов, которые используются в сценарии.
На самом деле во время выполнения не всегда известно, какие именно клас
сы используются. Например, вы могли создать систему для “прозрачной” рабо
ты с переопределяемыми классами, разработанными сторонними производите
лями. Обычно экземпляр объекта в РНР получается только на основании имени

168

ЧАСТЬ II

ОБЪЕКТЫ

класса. Однако в языке РНР разрешается использовать символьные строки, что
бы ссылаться на классы динамически, как показано ниже.
// Листинг 05.20

namespace tasks;

class Task
{
public function doSpeak()
{
print "Привет\п";
}
}

// Листинг 05.21
$classname = "Task";
require_once("tasks/{$classname}.php");
$classname = "tasks\\$classname";
$myObj = new $classname();
$myObj->doSpeak();

Символьную строку, присвоенную переменной $classname, можно полу
чить из файла конфигурации или путем сравнения результатов веб-запроса с
содержимым каталога. Затем эту строку можно использовать для загрузки файла
класса и создания экземпляра объекта. Обратите внимание на то, что в приве
денном выше фрагменте кода перед именем класса указано пространство имен.
Как правило, подобные операции выполняются, когда требуется, чтобы систе
ма могла запускать созданные пользователем подключаемые модули. Но прежде
чем делать такие рискованные вещи в реальном проекте, вы должны убедиться,
что указанный класс существует, в нем имеются нужные вам методы и т.д.
НА ЗАМЕТКУ. Даже приняв все меры предосторожности, вы должны быть предельно

внимательны при динамической установке сторонних подключаемых модулей. Нельзя
автоматически запускать код, полученный от неизвестных пользователей. Дело в том,
что любой установленный вами подключаемый модуль, как правило, запускается с
теми же правами доступа, что и основной код вашего приложения. В итоге злоумыш
ленник, написавший такой модуль, может полностью вывести из строя ваше прило
жение и даже сервер, на котором оно выполняется.
Но сказанное выше вовсе не означает, что следует отказаться от применения под
ключаемых модулей. Расширение функциональных возможностей базовой системы с
помощью сторонних подключаемых модулей позволяет добиться большей гибкости.
Для повышения уровня безопасности необходимо создать специальный каталог, в
котором будут размещаться подключаемые модули. Доступ к этому каталогу следу
ет предоставить только системному администратору, который и должен заниматься
установкой подключаемых модулей, как непосредственно, так и через специальное
приложение, защищенное паролем. А перед установкой подключаемого модуля адми
нистратор должен лично проконтролировать его исходный код или получить его из за
служивающего доверия источника. Именно так реализована работа с подключаемыми
модулями на популярной платформе WordPress для разработки веб-сайтов и блогов.

ГЛАВА 5 Ш СРЕДСТВА ДЛЯ РАБОТЫ С ОБЪЕКТАМИ

169

В версии РНР 5 часть функций для работы с классами была заменена более
эффективным прикладным интерфейсом Reflection API, который будет рассма
триваться далее в этой главе. Но простота и удобство использования этих функ
ций иногда делают их более предпочтительными. Именно по этой причине мы
и рассмотрим их в первую очередь.

Поиск классов
Функции class exists () передается строка, содержащая имя класса. Она
возвращает логическое значение true, если класс существует, а иначе — логи
ческое значение false. С помощью этой функции можно сделать более безо
пасным фрагмент кода из предыдущего примера, как показано ниже.
// Листинг 05.22

$base = __ DIR__ ;
$classname = "Task";
$path = "{$base}/tasks/{$classname}.php";
if (! file_exists($path)) {
throw new \Exception("Файл не найден: {$path}");

}
require_once($path);
$qclassname = "tasks\\$classname";
if (! class_exists($qclassname) ) {
throw new Exception("Файл не найден: $qclassname");
}
$myObj = new $qclassname();
$myObj->doSpeak() ;

Безусловно, нет никакой гарантии, что конструктору рассматриваемого здесь
класса не потребуются аргументы. Для достижения такого уровня безопасно
сти при программировании необходимо обратиться к интерфейсу Reflection
API, описанному далее в этой главе. Тем не менее с помощью функции class_
exists () можно убедиться, что нужные классы существуют, прежде чем обра
щаться к этому интерфейсу.
НА ЗАМЕТКУ. Не забывайте, что к данным, полученным из внешних источников, следу

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

Чтобы получить массив всех классов, определенных в сценарии, можно вос
пользоваться функцией get_declared_classes(), как показано ниже.
print_r(get_declared_classes () ) ;

170

ЧАСТЬ II Ж ОБЪЕКТЫ

В итоге будет выведен список встроенных и определенных пользователем
классов. Не следует, однако, забывать, что данная функция возвращает только
те классы, которые были объявлены к моменту ее вызова. Ведь, выполнив в
дальнейшем оператор require () или require once (), можно тем самым до
полнить число классов, применяемых в сценарии.

Получение сведений об объекте или классе
Как вам, должно быть, уже известно, с помощью объявлений типов классов
можно ограничить типы аргументов метода некоторого объекта. Но даже ис
пользуя эту возможность, не всегда можно быть уверенным в отношении типа
объекта. Для проверки типа объекта имеется целый ряд инструментальных
средств. Прежде всего, класс, а следовательно, и тип объекта можно проверить
с помощью функции get_class (). Этой функции в качестве аргумента переда
ется любой объект, а она возвращает имя его класса в виде символьной строки,
как демонстрируется в следующем примере кода:
// Листинг 05.23

$product = self::getProduct();
if (get_class($product) === 'popp\ch05\batch05\CdProduct’)
print ”\$product является объектом класса CdProductXn";

{

}

В данном фрагменте кода мы получаем нечто из метода getProduct (). Что
бы убедиться, что это объект типа CDProduct, мы вызываем функцию getclass ().
НА ЗАМЕТКУ. Классы CdProduct и BookProduct описаны в главе 3, “Основные по

ложения об объектах”.
Ниже приведено определение метода getProduct ().
// Листинг 05.24
public static function getProduct()
(
return new CdProduct (
’’Классическая музыка. Лучшее”,
"Антонио",
"Вивальди",
10.99,
60.33
) ;
}

Метод getProduct () просто создает экземпляр объекта типа CDProduct и
возвращает его. Мы еще не раз выгодно воспользуемся данным методом в этом
разделе.

ГЛАВА 5

СРЕДСТВА ДЛЯ РАБОТЫ С ОБЪЕКТАМИ

171

А функция get class () выдает слишком конкретную информацию. Обычно
же требуются более общие сведения о принадлежности проверяемого объекта
к семейству классов. Допустим, требуется выяснить, принадлежит ли объект
семейству класса ShopProduct, но при этом не имеет значения, к какому кон
кретно классу он относится: BookProduct или CDProduct. Для этой цели в
языке РНР предусмотрена операция instanceof.
НА ЗАМЕТКУ. В версии РНР 4 операция instanceof не поддерживается. Вместо этого

в версии РНР 4 была предусмотрена функция is_a(), которую в версии РНР 5.0 уже
не рекомендовалось использовать. Начиная с версии РНР 5.3 этой функцией можно
пользоваться снова.

Операция instanceof выполняется над двумя операндами: объектом, кото
рый требуется проверить (этот операнд указывается слева от ключевого слова
instanceof), и именем класса или интерфейса, указываемого справа. В итоге
операция instanceof возвращает значение true, если объект является экзем
пляром класса указанного типа.
// Листинг 05.25
$product = self: : getProduct ();
if ($product instanceof \popp\ch05\batch05\CdProduct) {
print ”\$product является экземпляром класса CdProduct\n";
}

Получение полностью уточненной строковой ссылки на класс
Благодаря внедрению пространств имен удалось избежать множества за
труднений, которые возникали при использовании объектно-ориентированных
средств языка РНР. В итоге мы навсегда избавились от необходимости созда
вать длинные и уродливые имена классов, а также от опасности возникновения
конфликта имен, разумеется, кроме устаревшего кода. С другой стороны, при
использовании псевдонимов классов или относительных ссылок на простран
ства имен иногда нелегко выяснить, являются ли пути к некоторым классам
полностью определенными.
Ниже приведено несколько примеров, когда нелегко определить имя класса.
namespace mypackage;

use util as u;
use util\db\Querier as q;
class Local { }

// Определить следующее:
// Чему соответствует псевдоним пространства имен
// u\Writer;

172

ЧАСТЬ II Я ОБЪЕКТЫ

// Чему соответствует псевдоним класса
// q;
// Чему соответствует ссылка на класс в локальном контексте
// Local

На самом деле не так уж и трудно определить, во что превращаются приве
денные выше ссылки на класс. Намного труднее написать код, в котором обра
батывались бы все возможные ситуации. Так, чтобы проанализировать ссылку
u\Writer, средству автоматического разрешения имен придется определить,
что и — это псевдоним util и что util не является, собственно, простран
ством имен. Правда, в версии РНР 5.5 была внедрена синтаксическая конструк
ция ИмяКласса: :class. Она позволяет добавить к ссылке на класс операцию
разрешения области видимости, а с помощью ключевого слова class выяснить
полностью уточненное имя этого класса, как демонстрируется в приведенных
ниже примерах.
print u\Writer::class."\n”;
print q::class."\n";
print Local::class.”\n";

Выполнение данного фрагмента кода приведет к следующему результату:
util\Writer
util\db\Querier
mypackage\Local

Получение сведений о методах
Чтобы получить список всех методов класса, можно воспользоваться функ
цией get class methods (), как показано ниже. В качестве аргумента ей пе
редается имя класса, а она возвращает массив, содержащий имена всех методов
класса.
print_r(get_class_methods(
’Wpopp\\ch04\\batch02\\BookProduct’));

Если класс BookProduct существует, то получится следующий результат:
Array
(
[0] =>
[1] =>
[2] =>
[3] =>
[4] =>
[5] =>
[6] =>
[7] =>
[8] =>

__ construct
getNumberOfPages
getSummaryLine
getPrice
setID
getProducerFirstName
getProducerMainName
setDiscount
getDiscount

ГЛАВА 5 и СРЕДСТВА ДЛЯ РАБОТЫ С ОБЪЕКТАМИ

173

[9] => getTitle
[10] => getProducer
[11] => getlnstance
)

В этом примере передается имя класса функции get_class_methods (), а
возвращаемый ею массив выводится с помощью функции print r (). С таким
же успехом можно было бы передать функции get_class_methods () объект
и получить аналогичный результат. Но в этом случае в возвращаемый список
будут включены только имена открытых методов.
Как было показано ранее, имя метода можно сохранить в строковой перемен
ной и вызвать его динамически вместе с объектом следующим образом:
$product = self::getProduct (); // получить объект
$method = "getTitle"; // определить имя вызываемого метода
print $product->$method (); // вызвать метод

Безусловно, такой подход таит в себе опасность. Что, например, произой
дет, если метода не существует? Как и следовало ожидать, сценарий завершится
ошибкой. Ранее уже рассматривался один способ проверки существования мето
да, как в следующем примере кода:
if (in_array( $method, get_class_methods( $product )))
print $product->$method (); // вызвать метод

{

Прежде чем вызывать метод, мы проверяем, присутствует ли его имя в мас
сиве, возвращенном функцией get_class_methods(). Но в РНР для этой
цели предусмотрены более специализированные инструментальные средства.
Имена методов так или иначе можно проверить с помощью двух функций: is_
callable () и method exists (). Из них более сложной оказывается функция
is callable (). В качестве первого аргумента ей передается строковая пере
менная, определяющая имя функции. Если указанная функция существует и
ее можно вызвать, функция is callable () возвращает логическое значение
true. Чтобы организовать такую же проверку для метода, вместо имени функ
ции придется передать массив. Этот массив должен содержать ссылку на объект
или имя класса в качестве первого элемента и имя проверяемого метода в ка
честве второго. Функция is callable () возвратит логическое значение true,
если указанный метод существует в классе.
// Листинг 05.27
if ( is_callable( array ( $product, $method) ) )
print $product->$method (); // вызвать метод

{

}

У функции is callable () имеется и второй необязательный аргумент, при
нимающий логическое значение. Если задать в нем логическое значение true,

174

ЧАСТЬ II Ж ОБЪЕКТЫ

то данная функция проверит, существует ли указанное имя функции или метода,
но не будет проверять возможность вызова проверяемого элемента кода.
А функции method exists () передаются ссылка на объект (или имя класса)
и имя метода, как показано ниже. Она возвращает логическое значение true,
если указанный метод существует в классе объекта.
// Листинг 05.28

if ( method_exists ( $product, $method ) ) {
print $product->$method(); // вызвать метод

}

ВНИМАНИЕ!. Само существование метода еще не означает, что его можно вызвать.

Функция method_exists () возвращает логическое значение true для обнаружи
ваемых закрытых (private), защищенных (protected) и открытых (public) ме
тодов.

Получение сведений о свойствах
Подобно запрашиванию списка методов, можно запросить список свойств из
класса. С этой целью функции get_class_vars () передается имя класса, а она
возвращает ассоциативный массив. Имена свойств сохраняются в виде ключей
этого массива, а содержимое полей — в виде значений. Произведем проверку
объекта класса CDProduct. Для большей наглядности примера введем в этот
класс открытое свойство: CDProduct: :$coverUrl. В результате следующего
вызова:
print_r( get_class_vars(’Wpopp\\ch05\\batch05\\CdProduct’));

будет выведено только открытое свойство.
Array
(
[coverUrl] => cover Url
)

Получение сведений о наследовании
Используя функции для обращения с классами, можно также выявлять от
ношения наследования. Так, с помощью функции get_parent_class() можно
выяснить имя родительского класса для указанного класса. Этой функции пере
дается ссылка на объект или имя класса, а она возвращает имя суперкласса, если
такой существует. Если же такого класса не существует, т.е. если у проверяемого
класса нет родительского класса, то функция get parent class () возвращает
логическое значение false. Например, в результате следующего вызова:
print get_parent_class('Wpopp\\ch04\\batch02\\BookProduct');

ГЛАВА 5 я СРЕДСТВА ДЛЯ РАБОТЫ С ОБЪЕКТАМИ

175

будет получено имя родительского класса ShopProduct, как и следовало
ожидать.
С помощью функции is_subclass_of () можно также проверить, является
ли класс дочерним для другого класса. Этой функции передаются ссылка на до
черний объект и имя родительского класса, как показано ниже. Она возвращает
логическое значение true, если класс, указанный в качестве второго аргумента,
является суперклассом для класса, указанного в качестве первого аргумента.
// Листинг 05.29

$product = self::getBookProduct(); // получить объект
if (is_subclass_of($product,
'Wpopp\\ch04\\batch02\\ShopProduct'))

{
print "BookProduct является подклассом ShopProduct\n”;

}

Функция is_subclass_of () сообщит сведения только об отношениях на
следования в классе, но она не поможет выяснить, реализован ли в этом классе
некоторый интерфейс. Дня этой цели следует применить операцию instanceof.
Кроме того, можно воспользоваться функцией class_implements (), как
показано ниже. Эта функция входит в состав библиотеки SPL (Standard РНР
Library — стандартная библиотека РНР). Ей передается имя класса или ссылка
на объект, а она возвращает массив имен интерфейсов.
// Листинг 05.30

if (in_array('somelnterfасе’, class_implements($product)))
{
print "В BookProduct реализован интерфейс somelnterface\n";
}

Вызов методов
Ранее мы уже рассматривали пример, где строковая переменная использова
лась для динамического вызова метода.
$product = getProduct();
// получить объект
$method = "getTitle";
// определить имя метода
print $product->$method(); // вызвать метод

Для этой цели в языке РНР предусмотрена также функция call_user_
f unc (), которая может вызывать как методы, так и функции. Чтобы вызвать
функцию, в качестве первого аргумента следует указать строку, содержащую
имя этой функции.
$returnVal = call_user_func("myFunction");

176

ЧАСТЬ II « ОБЪЕКТЫ

Для вызова метода в качестве первого аргумента указывается массив. Первым
элементом массива должен быть объект, а вторым — имя вызываемого метода.
$returnVal = call_user_func(array[ $myObj,

"methodName"]);

Вызываемой функции или методу можно передать любое количество аргу
ментов, указав их в качестве дополнительных аргументов функции call_user_
func() .
// Листинг 05.31

$product = self::getBookProduct();
// получить объект типа BookProduct
call_user_func([$product, ’setDiscount’], 20);

Этот динамический вызов эквивалентен следующему:
$product->setDiscount( 20 );

Функция call user func () не особенно облегчит жизнь, поскольку в рав
ной степени вместо имени метода можно употребить строковую переменную,
как показано ниже.
$method = "setDiscount";
$product->$method(20) ;

Намного большее впечатление производит родственная ей функция са11_
user func array (). Что касается выбора нужного метода или функции, то
она действует аналогично функции call user func (). Но решающее значе
ние приобретает то обстоятельство, что данной функции можно передать в виде
массива любыеаргументы, требующиеся для вызова указанного метода.
НА ЗАМЕТКУ. Имейте в виду, что аргументы, требующиеся для вызова указанного мето

да или функции, не передаются функции call user func() по ссылке.

В чем же здесь польза? Иногда аргументы приходится получать в виде мас
сива. Если количество обрабатываемых аргументов заранее неизвестно, то пере
дать их функции будет очень трудно. В главе 4, “Расширенные средства”, были
рассмотрены методы-перехватчики, которые можно применять для создания де
легирующих классов. Ниже приведен простой пример применения метода__
call ().
// Листинг 05.32

public function __ call($method, $args)
{
if (method_exists($this->thirdpartyShop, $method))
return $this->thirdpartyShop->$method();

{

ГЛАВА 5

СРЕДСТВА ДЛЯ РАБОТЫ С ОБЪЕКТАМИ

177

Как пояснялось ранее, метод__ call () вызывается в том случае, когда в кли
ентском коде предпринимается попытка вызвать неопределенный метод. В дан
ном примере мы используем объект, сохраненный в свойстве $thirdpartyShop.
Если у этого объекта существует метод, имя которого указано в первом аргумен
те $ met hod, то он вызывается. Мы легкомысленно предположили, что метод,
который требуется вызвать, не требует никаких аргументов. Но именно здесь
начинаются затруднения! При создании метода__ call () заранее нельзя знать,
насколько крупным может оказаться массив $args при разных вызовах этого
метода. Если мы передадим массив $args непосредственно делегирующему
методу, то передадим единственный аргумент в виде массива, а не отдельные
аргументы, как того, возможно, ожидает делегирующий метод. Поэтому функ
ция call user func array () идеально разрешает данное затруднение следу
ющим образом:
// Листинг 05.33
public function __ call($method,

$args)

{
if (method_exists($this->thirdpartyShop,
return call_user_func_array(
[
$this->thirdpartyShop,
$method

$method))

{

b
$args
) ;

}

}

Интерфейс Reflection API
Программный интерфейс Reflection API для PHP — это то же самое, что и
пакет java. lang, reflect для Java. Он состоит из встроенных классов для
анализа свойств, методов и классов. В какой-то степени он напоминает такие
рассмотренные выше функции для манипулирования объектами, как, напри
мер, функция get class vars (), но в то же время он предоставляет больше
удобств и сведений об анализируемых элементах прикладного кода. Он пред
назначен также для более эффективной работы с такими объектно-ориентиро
ванными средствами РНР, как управление доступом, интерфейсы и абстракт
ные классы, по сравнению с ограниченными функциональными возможностями
прежних классов.

Краткое введение в Reflection API
Интерфейс Reflection API можно использовать для исследования не толь
ко классов. Например, класс ReflectionFunction предоставляет сведе
ния об указанной функции, а класс ReflectionExtension — сведения о

178

ЧАСТЬ II

ОБЪЕКТЫ

скомпилированных расширениях языка РНР. В табл. 5.1 перечислены некоторые
классы интерфейса Reflection API.
Таблица 5.1. Некоторые классы из интерфейса Reflection API

Класс

Описание

Reflection

Содержит статический метод exportO , предостав
ляющий итоговые сведения о классе

Reflectionclass

Позволяет получить сведения о классе и содержит
средства для работы с ним

ReflectionMethod

Позволяет получить сведения о методах класса и со
держит средства для работы с ними

Reflectionparameter

Позволяет получить сведения об аргументах метода

Reflectionproperty

Позволяет получить сведения о свойствах класса

ReflectionFunction

Позволяет получить сведения о функциях и содержит
средства для работы с ними

ReflectionExtension

Позволяет получить сведения о расширениях РНР

ReflectionException

Предназначен для обработки ошибок

ReflectionZendExtension

Содержит сведения о расширении Zend языка РНР

Некоторые классы из интерфейса Reflection API позволяют во время выпол
нения программы получить просто беспрецедентную информацию об объектах,
функциях и расширениях языка, содержащихся в сценарии, добыть которую
раньше было невозможно. Из-за более широких возможностей и большей эф
фективности во многих случаях следует использовать интерфейс Reflection API,
а не функции для работы с классами и объектами. И вскоре вы поймете, что это
незаменимое инструментальное средство для исследования классов. Например,
с его помощью можно создавать диаграммы классов или документацию, сохра
нять сведения об объекте в базе данных, исследовать методы доступа (установ
ки и получения), применяемые для извлечения значений полей (или свойств)
объекта. Создание каркаса, где вызываются методы из классов модуля в соответ
ствии с принятой схемой именования, служит еще одним примером применения
интерфейса Reflection API.

Время засучить рукава
В приведенных ранее примерах уже демонстрировались некоторые функции
для исследования атрибутов классов. И хотя они полезны, тем менее, обычно
ограничены. А теперь рассмотрим инструментальное средство, специально пред
назначенное для выполнения такой работы. Им служит класс Reflectionclass,
предоставляющий методы для сбора сведений обо всех аспектах указанного
класса: как внутреннего, так и определяемого пользователем. В качестве един
ственного аргумента конструктору класса Reflectionclass передается имя
исследуемого класса, интерфейса (или экземпляра объекта), как показано ниже.

ГЛАВА 5 S СРЕДСТВА ДЛЯ РАБОТЫ С ОБЪЕКТАМИ

179

// Листинг 05.34
Sprodclass = new ReflectionClass('CdProduct’) ;
Reflection::export($prodclass);

Создав объект типа Reflectionclass, можно воспользоваться вспомогатель
ным классом Reflection для вывода итоговых сведений об указанном классе
CDProduct. В классе Reflection имеется статический метод export(), фор
матирующий и выводящий данные, содержащиеся в объекте типа Reflection
(а точнее, в любом экземпляре класса, реализующего интерфейс Reflector).
Ниже приведен фрагмент вывода данных, получаемых в результате вызова ме
тода Reflection::export().
Class [ class CdProduct extends ShopProduct ]
@@ /usr/home/phpObj5ed/listing03_36.php 8-22

- Constants
}

[0]

{

- Static properties
}
- Static methods
}
- Properties
Property [
Property [
Property [
Property [
Property [
Property [

{

[0]

[0]

{

{

[6] {

public
public
public
public
public
public

$numPages ]
$playLength ]
$title ]
$producerMainName ]
$producerFirstName ]
$price ]

- Methods [4] {
Method [ public method getPlayLength ] {
@@ /usr/home/phpObj5ed/listing03_36.php 10 - 13
}

Method [ public
method getSummaryLine ] {
@@ /usr/home/phpObj5ed/listing03_36.php 15 - 21
}

Method [ public method __ construct

{

@0 /usr/home/phpObj5ed/listing03_35.php 14 - 28

Parameter;s [6]
Parameter #0 [
Parameter #1 [
Parameter #2 [
Parameter #3 [
Parameter #4 [

{

string $title ]
string $firstName ]
string $mainName ]
float $price ]
integer SnumPages = 0 ]

180

ЧАСТЫ! а ОБЪЕКТЫ
Parameter #5

[ integer $playLength = 0 ]

}

Method [ public method getProducer ]
@@ /usr/home/phpObj5ed/listing03_35.php 30 - 34

{

Как видите, метод Reflection: :export() обеспечивает удобный доступ
к сведениям об исследуемом классе. Этот метод, в частности, предоставляет
итоговые сведения практически о каждом аспекте класса CdProduct, включая
состояние управления доступом к свойствам, методам и аргументам, требую
щимся для каждого метода, а также местоположение каждого метода в сце
нарии. Сравните это с более традиционной функцией отладки. Так, функция
var_dump () служит универсальным инструментальным средством для вывода
итоговых данных. Перед выводом информации об объекте с помощью функции
var dump () необходимо получить его экземпляр. Однако при этом вы не уви
дите того беспрецедентного объема информации, который можно получить с
помощью вызова метода Reflection: :export().
// Листинг 05.35
$cd = new CdProduct

( "Классическая музыка. Лучшее",
"Антонио",
"Вивальди",
10.99,
0,
60.33
) ;

var_dump ($cd) ;

Выполнение данного фрагмента кода приведет к следующему результату:
object(CdProduct)#1 (6) {
["numPages"]=>
int (0)
["playLength"]=>
int (60)
["title"]=>
string (51) "Классическая музыка. Лучшее"
["producerMainName"]=>
string(16) "Вивальди"
["producerFirstName"]=>
string(14) "Антонио"
["price"]=>
float(10.99)

ГЛАВА 5

СРЕДСТВА ДЛЯ РАБОТЫ С ОБЪЕКТАМИ

181

Функция var dumpO и родственная ей функция print_r() служат неве
роятно удобными инструментальными средствами для отображения данных в
сценариях. Но для исследования классов и функций интерфейс Reflection API
позволяет выйти на совершенно новый уровень отладки.

Исследование класса
Метод Reflection: :export () предоставляет немало полезных сведений
для отладки прикладного кода, но интерфейс Reflection API можно использовать
особым образом. Поэтому будем пользоваться дальше непосредственно клас
сами интерфейса Reflection API. Как было показано ранее, создать экземпляр
объекта Reflectionclass можно следующим образом:
Sprodclass = new ReflectionClass(’CdProduct');

Теперь воспользуемся объектом типа Reflectionclass, чтобы исследовать
класс CDProduct в процессе выполнения сценария. В данном случае необходи
мо выяснить, к какому именно типу класса он относится и можно ли создать
его экземпляр. Ниже приведена функция, которая поможет найти ответы на эти
вопросы.
// Листинг 05.36
// Класс Classinfo
public static function getData(ReflectionClass Sclass)
{

Sdetails =
$name = $class->getName();
if ($class->isUserDefined()) {
$details .= "Sname — определен пользователем\п”;
}

if ($class->islnternal()) {
Sdetails .= "$name — встроенный класс\п”;
}

if ($class->islnterface()) {
$details .= "Sname — интерфейс\п”;
}

if ($class->isAbstract()) {
Sdetails .= "$name — абстрактный класс\п";
}

if ($class->isFinal()) {
Sdetails .= "Sname — завершенный класс\п";
}

if ($class->islnstantiable ()) {
Sdetails .= "Sname -- можно создать экземпляр объекта\п";
} else {

182

ЧАСТЬ II » ОБЪЕКТЫ
$details . = ”$name — нельзя

создать экземпляр объекта\п";

}
if ($class->isCloneable()) {
$details .= "$name -- можно клонировать\n”;
} else {
$details . = "$name -- нельзя клонировать\n”;
}
return $details;

}

// Листинг 05.37
$prodclass = new ReflectionClass(’CdProduct•);
print ClassInfo::getData($prodclass);

В данном примере создается объект типа Reflectionclass, который
присваивается переменной $prodclass. При этом конструктору класса
Reflectionclass передается символьная строка, содержащая имя исследуе
мого класса ’ CDProduct ’. Затем переменная $prodclass передается методу
Classinfo: :getData(), демонстрирующему работу ряда методов, которыми
можно воспользоваться для исследования класса.
Методы класса Reflectionclass, вероятно, не требуют особых пояснений,
тем не менее, приведем их краткое описание.

$ Метод Ref lectionClass :: getName () возвращает имя исследуемого
класса.
в Метод Ref lectionClass :: isUserDef ined () возвращает логиче
ское значение true, если класс был объявлен в коде РНР, а метод
Reflectionclass: :islnternal () — если класс является встроенным.

С помощью метода Ref lectionClass :: isAbstract () можно прове
рить, является ли класс абстрактным, а с помощью метода Reflection
Class: :islnterface — является ли исследуемый элемент кода интер
фейсом.

« Если требуется получить экземпляр класса, то с помощью метода Ref le
ctionClass: : islnstantiable () можно проверить, насколько это осу
ществимо.
в С помощью метода Reflectionclass:: isCloneable () можно прове
рить, подлежит ли класс клонированию.

Имеется даже возможность исследовать исходный код определяемого поль
зователем класса. В частности, объект Reflectionclass позволяет получить
имя исходного файла класса и номера первой и последней строк кода, где этот
класс определяется.
Ниже приведен простой пример, в котором объект типа Reflectionclass
используется для доступа к исходному коду указанного класса.

ГЛАВА 5 И СРЕДСТВА ДЛЯ РАБОТЫ С ОБЪЕКТАМИ

183

// Листинг 05.38

class ReflectionUtil

{
public static function getClassSource(
Reflectionclass $class): string

{
$path = $class->getFileName();
$lines = file($path);
$from = $class->getStartLine();
$to = $class->getEndLine();
$len = $to - $from + 1;
return implode(array_slice($lines,

$from - 1,

$len));

}
}
// Листинг 05.39

print ReflectionUtil::getClassSource (
new ReflectionClass(’CdProduct’)

) ;

Как видите, класс ReflectionUtil очень прост и содержит единствен
ный статический метод Ref lectionUtil:: getClassSource () . В ка
честве единственного аргумента этому методу передается объект типа
Reflectionclass, а он возвращает исходный код исследуемого класса. Метод
Reflectionclass: :getFileName () возвращает абсолютное имя файла клас
са, поэтому код из данного примера должен без проблем открыть указанный ис
ходный файл. Функция file () возвращает массив всех строк кода в исходном
файле, метод Reflectionclass:: getStartLine () — номер начальной строки
кода, а метод Reflectionclass: :getEndLine() — номер последней строки,
где содержится определение класса. И теперь для получения нужных строк кода
достаточно воспользоваться функцией array slice ().
Ради краткости в данном примере кода опущена обработка ошибок. Но в
реальном приложении нужно непременно проверить аргументы и возвращаемые
коды состояния.

Исследование методов
Подобно тому как Reflectionclass служит для исследования класса,
класс ReflectionMethod служит для исследования метода. Ссылку на объ
ект типа ReflectionMethod можно получить двумя способами. Во-пер
вых, можно получить массив объектов типа ReflectionMethod, вызвав
метод Ref lectionClass :: getMethods (). И во-вторых, если особый ин
терес представляет конкретный метод, его имя следует передать методу
Reflectionclass: :getMethod (), который возвратит соответствующий объект
типа ReflectionMethod.
Приведенный ниже метод Reflectionclass: -.getMethods () применяется
с целью проверить возможности класса ReflectionMethod.

184

ЧАСТЬ II » ОБЪЕКТЫ

// Листинг 05.40

Sprodclass = new ReflectionClass(1CdProduct’);
Smethods = $prodclass->getMethods();

foreach ($methods as Smethod) {
print Classinfo::methodData($method);
print "\n-------- \n”;

// Листинг 05.41
// Класс Classinfo
public static function methodData(ReflectionMethod $method)

(
Sdetails =
Sname = Smethod->getName();
if ($method->isUserDefined()) {
Sdetails .= "$name -- определен пользователем.\n";
}
if
}
if
}
if

}
if
}
if

}
if
}
if

}
if
}
if

($method->islnternal()) {
Sdetails .= "$name -- встроенный метод\п";
($method->isAbstract()) {
Sdetails .= ”$name -- абстрактный метод\п";
($method->isPublic()) {
Sdetails .= ’’Sname -- открытый метод\п";
($method->isProtected()) {
Sdetails .= "Sname -- защищенный метод\п”;

($method->isPrivate()) {
Sdetails .= "Sname -- закрытый метод\п";
($method->isStatic()) {
Sdetails .= "Sname — статический метод\п";

($method->isFinal()) {
Sdetails .= "Sname -- завершенный метод\п";
($method->isConstructor()) {
Sdetails .= "Sname -- конструктор\п";

($method->returnsReference()) {
Sdetails . = "Sname -- возвращает ссылку, а не значение\п";

}
return Sdetails;
}

В приведенном выше примере кода для получения массива объектов типа
ReflectionMethod вызывается метод Reflectionclass: : getMethods (). За
тем в цикле выполняется обращение к каждому элементу массива и вызывается
метод methodData () класса Classinfo, которому передается полученный объ
ект типа ReflectionMethod.

ГЛАВА 5

СРЕДСТВА ДЛЯ РАБОТЫ С ОБЪЕКТАМИ

185

Имена методов, вызываемых в функции methodData (), отражают их на
значение: в коде проверяется, является ли метод определяемым пользователем,
встроенным, абстрактным, открытым, защищенным, статическим или завер
шенным. Можно также проверить, является ли метод конструктором для своего
класса и что он возвращает: ссылку или значение.
Но здесь необходимо сделать следующую оговорку: метод ReflectionMethod: : returnsReference () не возвращает логическое значение true в
случае, если проверяемый метод просто возвращает объект, хотя в версии РНР 5
объекты передаются и присваиваются по ссылке. Этот метод возвращает логи
ческое значение true только в том случае, если в исследуемом методе было
явно объявлено, что он возвращает ссылку. С этой целью перед именем метода
в его объявлении должен быть указан знак амперсанда.
Как и следовало ожидать, доступ к исходному коду метода можно получить
тем же способом, который использовался ранее для доступа к исследуемо
му классу с помощью класса Reflectionclass, как показано ниже. В клас
се Ref lectionMethod имеются методы getFileName (), getStartLine () и
getEndLine (), что дает возможность очень просто получить исходный код ис
следуемого метода.
// Листинг 05.42

Class ReflectionUtil {
public static function getMethodSource (
ReflectionMethod $method): string

{
$path = $method->getFileName();
$lines = @file($path);
$from = $method->getStartLine();
$to = $method->getEndLine() ;
$len = $to - $from + 1;
return implode(array_slice($lines,

$from - 1, $len));

}

}
// Листинг 05.43

$class = new ReflectionClass(’CdProduct');
$method = $class->getMethod('getSummaryLine');
print ReflectionUtil::getMethodSource(Smethod);

Исследование аргументов методов
Теперь, когда стало возможным ограничивать типы аргументов с помощью
сигнатур методов, чрезвычайно полезной кажется возможность исследования
аргументов, объявленных в сигнатуре метода. Именно для этой цели в интер
фейсе Reflection API предусмотрен класс Reflectionparameter. Чтобы полу
чить объект типа Reflectionparameter, потребуется помощь объекта типа
ReflectionMethod. В частности, метод ReflectionMethod: :getParameters () возвращает массив объектов типа Reflectionparameter.

186

ЧАСТЬ II В ОБЪЕКТЫ

Имея в своем распоряжении объект типа Reflectionparameter, можно
выяснить следующее: имя аргумента; была ли переменная передана по ссылке
(т.е. при объявлении метода перед его именем был помещен символ амперсан
да); сведения о классе, применяемом для уточнения типа аргумента; а также
может ли методу передаваться пустое значение в качестве аргумента.
Ниже приведен пример применения некоторых методов из класса Reflec
tionparameter.
// Листинг 05.44

$class = new Reflectionclass (
$method
$params
foreach
print

'CdProduct’);

= $class->getMethod(”__ construct’’);
= $method->getParameters();
($params as $param) {
Classinfo::argData($param) . ”\n";

}
// Листинг 05.45
// Класс Classinfo
public function argData(ReflectionParameter $arg)

{

$details =
$declaringclass = $arg->getDeclaringClass();
$name = $arg->getName () ;
$class = $arg->getClass () ;
$position = $arg->getPosition ();
Sdetails .= "\$$name расположен в позиции $position\n”;
if ( ! empty($class)) {
$classname = $class->getName () ;
$details .= "\$$name должно быть объектом типа $classname\n”;

}
if ($arg->isPassedByReference()) {
$details .= ”\$$name передан по ссылке \n”;

}

if ($arg->isDefaultValueAvailable()) {
$def = $arg->getDefaultValue ();
$details .= "\$$name имеет стандартное значение: $def\n";
}
if ($arg->allowsNull ()) {
$details .= "\$$name может быть null\n";

}

return $details;
}

Метод ReflectionClass::getMethod() возвращает объект типа
Ref lectionMethod для интересующего нас метода (в данном примере это метод

ГЛАВА 5

СРЕДСТВА ДЛЯ РАБОТЫ С ОБЪЕКТАМИ

187

конструктора). Затем вызывается метод Reflectionclass:: getParameters ()
для получения массива объектов типа Reflectionparameter, соответствую
щих данному методу. Далее в цикле функции argData () передается объект
типа Reflectionparameter, а она возвращает информацию об аргументе.
Сначала в данном примере выясняется имя переменной аргумента с
помощью метода Ref lectionParameter :: getName (). Метод Refle
ctionparameter: cgetClass () возвращает объект типа Reflectionclass,
если в сигнатуре метода использовано указание типа данных. Далее с помощью
метода isPassedByReference () проверяется, является ли аргумент ссылкой.
И, наконец, с помощью метода isDefaultValueAvailable () проверяется,
было ли аргументу присвоено стандартное значение.

Применение интерфейса Reflection API
Зная основы интерфейса Reflection API, можно теперь воспользоваться им на
практике. Допустим, требуется создать класс, динамически вызывающий объек
ты типа Module. Это означает, что данный класс должен уметь работать с моду
лями, написанными сторонними разработчиками, которые можно автоматически
подключать к приложению, не занимаясь трудоемким кодированием. Чтобы до
биться этого, можно определить метод execute () в интерфейсе Module или аб
страктном базовом классе, вынуждая разработчиков определять его реализацию
во всех дочерних классах. Пользователям системы можно разрешить указывать
классы типа Module во внешнем XML-файле конфигурации. Эти сведения мо
гут использоваться в системе для группирования ряда объектов типа Module,
перед тем как вызывать метод execute () для каждого из них.
Но что произойдет, если каждому объекту типа Module для выполнения его
обязанностей потребуются свои (отличные от других) данные? На этот случай в
XML-файле конфигурации могут быть предоставлены ключи и значения свойств
для каждого объекта типа Module, а создатель объекта типа Module должен
предоставить методы установки для каждого имени свойства. И на этом осно
вании в прикладном коде можно обеспечить вызов нужного метода установки
по имени соответствующего свойства.
Ниже приведено объявление интерфейса Module и пара классов, в которых
он реализован.
// Листинг 05.46
class Person
{
public $name;
public function __ construct(string $name)
{

$this->name = $name;
}

}

188

ЧАСТЬ II « ОБЪЕКТЫ

// Листинг 05.47

interface Module
{
public function execute ();
}

// Листинг 05.48
class FtpModule implements Module

{
public function setHost($host)

{
print "FtpModule::setHost () : $host\n";
}

public function setUser($user)
{

print "FtpModule::setUser(): $user\n";
}

public function execute ()

{
// сделать что-нибудь

}
}

// Листинг 05.49
class PersonModule implements Module
{
public function setPerson(Person $person)
{

print "PersonModule::setPerson () :

{$person->name}\n";

}

public function execute ()
{

// сделать что-нибудь
}

}

В классах PersonModule и FtpModule из приведенного выше кода пред
усмотрены пустые реализации метода execute (). В каждом классе также реа
лизованы методы установки, которые ничего не делают, но сообщают, что они
были вызваны. В рассматриваемой здесь системе принято соглашение, что всем
методам установки должен передаваться только один аргумент: символьная
строка или объект, экземпляр которого можно создать с помощью одного стро
кового аргумента. Методу PersonModule: : setPerson)) должен передаваться
объект типа Person, поэтому в данный пример был включен несложный класс
Person.

ГЛАВА 5 w СРЕДСТВА ДЛЯ РАБОТЫ С ОБЪЕКТАМИ

189

Следующей стадией в работе с классами PersonModule и FtpModule явля
ется создание класса ModuleRunner. В нем используется многомерный массив,
проиндексированный по имени модуля и содержащий сведения о параметрах
конфигурации, полученные из XML-файла. Ниже приведено определение класса
ModuleRunner.
// Листинг 05.50
class ModuleRunner

{
private $configData = [ ’’PersonModule” =>
['person' => 'bob ’ ],
’’FtpModule" =>
[

’host' => 'example.com',
’user' => 'anon'
]
] ;
private $modules = [ ] ;
// ...

Свойство ModuleRunner: :$configData содержит массив параметров для
двух классов типа Module. В каждом элементе этого массива содержится вло
женный массив, содержащий набор свойств для каждого модуля. Метод init ()
из класса ModuleRunner отвечает за создание соответствующих объектов типа
Module, как показано в следующем фрагменте кода:
// Листинг 05.51

// Класс ModuleRunner
public function init ()
{
$interface = new ReflectionClass('Module;
foreach ($this->configData as $modulename => $params)
$module__class = new ReflectionClass($modulename);
if (! $module_class->isSubclassOf($interface)) {
throw new Exception(
"Неизвестный тип модуля: $modulename");
}
$module = $module_class->newlnstance ();
foreach ($module_class->getMethods () as $method) {
$this->handleMethod($module, $method, $params);
// Метод handleMethod () представлен
//в последующем листинге!
}
array_push($this->modules, $module);
}
}

// Листинг 05.52
$test = new ModuleRunner () ;
$test->init ();

{

ЧАСТЬ II

190

ОБЪЕКТЫ

В методе init () в цикле перебираются все элементы массива ModuleRunner: :$configData и для каждого указанного в нем имени класса типа
Module предпринимается попытка создать объект типа Reflectionclass. Ког
да конструктору класса Reflectionclass передается имя несуществующего
класса типа Module, генерируется исключение. Поэтому в реальное приложение
необходимо включить также код обработки ошибок. Чтобы проверить, относит
ся ли класс модуля к типу Module, вызывается метод Reflectionclass: :isS
ubclassOf().
Прежде чем вызвать метод execute () для каждого объекта типа Module,
необходимо создать экземпляр этого объекта. Для этой цели служит метод
Reflectionclass: :newlnstance (). Этому методу можно передать произ
вольное количество аргументов, которые будут далее переданы конструктору
соответствующего класса. Если все пройдет удачно, метод возвратит экземпляр
исследуемого класса. В реальном приложении перед получением экземпляра
объекта типа Module следует непременно убедиться, что методу конструктора
каждого объекта типа Module не требуется передавать никаких аргументов.
Метод Reflectionclass: :getMethods () возвращает массив всех объек
тов типа ReflectionMethod, имеющихся для исследуемого класса. Для каждо
го элемента массива в рассматриваемом здесь примере кода вызывается метод
ModuleRunner: :handleMethod (), которому передаются экземпляр объекта
типа Module, объект типа Ref lectionMethod и массив свойств для связывания
с текущим объектом типа Module. Переданные данные проверяются в методе
handleMethod (), после чего вызываются методы установки текущего объекта
типа Module, как показано ниже.
// Листинг 05.53
// Класс ModuleRunner
public function handleMethod(Module $module,
ReflectionMethod $method, $params)

{
$name = $method->getName();
$args = $method->getParameters();
if (count ($args)
return false;

!= 1

||

substr($name,

0,

3)

!= ’’set”)

}

$property = strtolower(substr($name,

if (! isset($params[$property]))
return false;

3) ) ;

{

}

$arg_class = $args[0]->getClass ();

if (empty($arg_class)) {
$method->invoke($module,

$params[$property]);

{

ГЛАВА 5 «« СРЕДСТВА ДЛЯ РАБОТЫ С ОБЪЕКТАМИ

191

} else {
$method->invoke(
$module, $arg_class->newlnstance($params[$property])
) ;
}
}

В методе handleMethod () сначала проверяется, является ли исследуемый
метод допустимым методом установки. В данном примере кода допустимый ме
тод установки должен называться setXXXXO и содержать только один аргумент.
Если предположить, что аргумент проверен, то в рассматриваемом здесь при
мере кода из имени метода установки извлекается далее имя свойства. Для этого
в начале имени метода удаляется слово "set" и полученная в итоге подстро
ка преобразуется в строчные буквы. Эта строка служит для проверки элемента
массива $params. Напомним, что в этом массиве содержатся предоставляемые
пользователем значения свойств, связанных с объектом типа Module. Если тре
буемое свойство не обнаружено в массиве $params, то возвращается логическое
значение false.
Если имя свойства, извлеченное из имени метода, содержащегося в объек
те типа Module, соответствует элементу массива $params, то для него можно
вызвать соответствующий метод установки. Но прежде необходимо проверить
тип первого (и только первого) аргумента метода установки. Эти сведения пре
доставляются методом Reflectionparameter: :getClass (). Если этот метод
возвратит пустое значение, методу установки следует передать значение элемен
тарного (т.е. строкового) типа, а иначе — объект.
Для вызова метода установки потребуется новый метод ReflectionMethod: : invoke () из интерфейса Reflection API. Этому методу передаются
объект (в данном случае — типа Module) и произвольное количество аргумен
тов, которые будут переданы далее методу установки объекта типа Module.
Метод ReflectionMethod: : invoke () генерирует исключение, если пере
данный ему объект не соответствует методу, определенному в объекте типа
ReflectionMethod. Метод ReflectionMethod: : invoke () можно вызвать
одним из двух способов. Так, если методу установки требуется передать значе
ние элементарного типа, то метод ReflectionMethod: : invoke () вызывается
с переданным ему строковым значением свойства, предоставляемым пользова
телем. А если методу установки требуется объект, то строковое значение свой
ства служит для получения экземпляра объекта требуемого типа, который затем
передается методу установки.
В данном примере кода предполагается, что для получения экземпляра
требуемого объекта его конструктору требуется передать только один строко
вый аргумент. Но это лучше все же проверить, прежде чем вызывать метод
Reflectionclass::newlnstance().
После того как метод ModuleRunner: :init () завершит свою работу, объ
ект типа ModuleRunner будет содержать ряд объектов типа Module (в массиве

192

ЧАСТЬ II Й ОБЪЕКТЫ

свойств $modules), причем все они будут заполнены данными. Остается лишь
создать в классе ModuleRunner специальный метод, перебирающий в цикле все
объекты типа Module и вызывающий для каждого из них метод execute ().

Резюме
В этой главе были рассмотрены некоторые способы и средства для управ
ления библиотеками и классами. В ней были описаны пространства имен как
языковое средство РНР и было показано, что их можно успешно применять для
гибкой организации классов и пакетов наряду с путями включения файлов, ав
тозагрузкой и каталогами файловой системы.
Кроме того, в этой главе были рассмотрены функции для работы с объекта
ми и классами в РНР, а на более высоком уровне — эффективный и удобный
интерфейс Reflection API. И, наконец, классы Reflection API были использова
ны для простого примера, демонстрирующего одно из возможных применений
этого интерфейса.

ГЛАВА 6
ЖВВ

Объекты и проектирование
Рассмотрев подробно механизм поддержки объектов в РНР, отвлечемся от
подробностей и выясним, почему лучше всего пользоваться теми средствами, с
которыми вы познакомились ранее. В этой главе мы остановимся на некоторых
вопросах, касающихся объектов и проектирования. В ней будет также рассмо
трен UML — эффективный графический язык для описания объектно-ориенти
рованных систем.
В этой главе рассматриваются следующие вопросы.
Основы проектирования. Что понимается под проектированием и чем
объектно-ориентированная структура кода отличается от процедурной.

$ Контекст класса. Как решить, что следует включить в класс.
it Инкапсуляция. Сокрытие реализации и данных в интерфейсе класса.

$ Полиморфизм. Использование общего супертипа с целью разрешить про
зрачную подстановку специализированных подтипов во время выполне
ния программы.
« UML. Использование диаграмм для описания объектно-ориентированных
архитектур.

Определение программного проекта
Один из аспектов программного проекта касается определения системы: вы
яснение требований к системе, контекста и целей. Что система должна делать?
Для кого она должна это делать? Каковы выходные данные системы? Отвечают
ли они поставленным требованиям? На нижнем уровне проектирование можно
понимать как процесс, посредством которого определяются участники системы
и устанавливается связь между ними. Эта глава посвящена второму аспекту:
определению и расположению классов и объектов.
Кто же такой участник? Объектно-ориентированная система состоит из клас
сов. И очень важно решить, каким будет характер этих классов в проектируемой
системе. Классы отчасти состоят из методов. Поэтому при определении классов

194

ЧАСТЬ II ж ОБЪЕКТЫ

необходимо решить, какие методы следует объединить, чтобы они составляли
одно целое. Но, как будет показано далее в этой главе, классы часто объеди
няются в отношения наследования, чтобы подчиняться общим интерфейсам.
Именно эти интерфейсы, или типы, должны стать первыми участниками проек
тируемой системы.
Существуют и другие отношения, которые можно определить для классов.
Так, можно создать классы, состоящие из других типов или управляющие спи
сками экземпляров других типов. Кроме того, можно спроектировать классы, в
которых просто используются другие объекты. Возможность для составления
или использования таких отношений встроена в классы (например, через объ
явления типов классов в сигнатурах методов). Но реальные отношения между
объектами вступают в действие во время выполнения программы, что позволяет
сделать процесс проектирования более гибким. Из этой главы вы узнаете, как
моделировать эти отношения, а в остальной части книги они будут исследованы
более подробно.
В процессе проектирования требуется решить, когда операция должна отно
ситься к одному типу, а когда — к другому классу, используемому этим типом.
За что бы ни взяться, приходится постоянно делать выбор, который приведет к
ясному и изящному проектному решению или затянет в болото компромиссов.
В этой главе основное внимание уделяется вопросам, способным повлиять на
выбор проектных решений.

Объектно-ориентированное
и процедурное программирование
Чем объектно-ориентированный проект отличается от более традиционного
процедурного кода? Так и хочется сказать: “Главное отличие в том, что в объ
ектно-ориентированном коде имеются объекты”. Но это неверно. С одной сто
роны, в языке РНР часто случается так, что в процедурном коде используются
объекты. А с другой стороны, могут встретиться классы, в которых содержатся
фрагменты процедурного кода. Наличие классов не может служить гарантией
объектно-ориентированного характера проекта, даже в таком языке, как Java, в
котором практически все операции выполняются в пределах класса.
Коренное отличие объектно-ориентированного кода от процедурного заклю
чается в том, как распределяется ответственность. Процедурный код имеет фор
му последовательности команд и вызовов функций. Управляющий код обыч
но несет ответственность за обработку различных ситуаций. Это управление
сверху вниз может привести к дублированию и возникновению зависимостей в
проекте. Объектно-ориентированный код пытается свести к минимуму эти за
висимости, передавая ответственность за управление задачами от клиентского
кода к объектам в системе.

ГЛАВА 6

ОБЪЕКТЫ И ПРОЕКТИРОВАНИЕ

195

В этом разделе рассматривается простая задача, которая анализируется с точ
ки зрения объектно-ориентированного и процедурного подходов, чтобы проде
монстрировать их отличия. Эта задача состоит в том, чтобы создать простое
средство для считывания информации из конфигурационных файлов и записи
в них. Чтобы сосредоточить внимание на структуре кода, в приведенных далее
примерах опускается код их реализации.
Начнем с процедурного подхода к решению данной задачи. Организуем сна
чала чтение и запись текста в приведенном ниже формате.
ключ:значение

Для этой цели нам потребуются только две функции:
// Листинг 06.01
function readParams(string $source): array
{

$params = [ ] ;
// прочитать текстовые параметры из
// указанного источника $source
return $params;
}
function writeParams(array $params, string $source)

{

// записать текстовые параметры
//в указанный источник $source
}

Функции readParams () нужно передать имя файла конфигурации. Она пы
тается открыть его и прочитать из него каждую строку, отыскивая в ней пары
“ключ-значение”. По ходу дела эта функция создает ассоциативный массив и
возвращает этот массив управляющему коду. А функции writeParams () пе
редаются ассоциативный массив и имя файла конфигурации. Она перебирает
этот ассоциативный массив в цикле, записывая каждую пару “ключ-значение” в
файл конфигурации. Ниже приведен пример клиентского кода, где применяются
эти функции.
// Листинг 06.02
$file = __ DIR__ . "/params.txt";
$params = [
"keyl” => "vail",
"key2" => "val2",
"key3" => "val3",
];
writeParams($params, $file);
$output = readParams($file);
print_r($output);

196

ЧАСТЬ II » ОБЪЕКТЫ

Этот код относительно компактный, и его легко сопровождать. При вызове
функции writeParams() создается файл param.txt, в который записывается
приведенная ниже информация.
keyl:vail
key2:val2
кеуЗ:val3

Функция readParams () производит синтаксический анализ в том же самом
формате. Многие проекты постепенно расширяют свои рамки и развиваются.
Сымитируем эту особенность проектов, введя новое требование, в соответствии
с которым код должен также обрабатывать структуру XML-файла конфигура
ции, которая выглядит следующим образом:

my key
my val

Если данный конфигурационный файл имеет расширение .xml, то для его
обработки необходимо задействовать средства обработки XML-разметки, встро
енные в РНР. И хотя такую задачу совсем нетрудно решить, существует угроза,
что прикладной код станет намного труднее сопровождать. Для этого у нас име
ются две возможности: проверить расширение файла в управляющем коде или
произвести проверку в теле функций чтения и записи. Остановимся на второй
возможности.
// Листинг 06.03
function readParams(string $source) : array
{
$params = [ ] ;
if (preg_match(”/\.xml$/i", $source)) {
// прочитать параметры в формате XML
// из указанного источника $source
} else {
// прочитать текстовые параметры из
// указанного источника $source
}
return $params;
}
function writeParams(array $params, string Ssource)
{
if (preg_match(”/\.xml$/i", Ssource)) {
// записать в формате XML параметры
// в указанный источник $source
} else {
// записать текстовые параметры
// в указанный источник $source

ГЛАВА 6 « ОБЪЕКТЫ И ПРОЕКТИРОВАНИЕ

197

НА ЗАМЕТКУ. Код любого примера всегда несет в себе элемент трудного компромисса.

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

Как видите, расширение конфигурационного файла .xml пришлось прове
рять в каждой функции. Именно это повторение в итоге может стать причиной
осложнений. Если же заказчики попросят включить в проектируемую систему
поддержку еще одного формата параметров, то нужно внести изменения в функ
ции readParams() и writeParams ().
А теперь попробуем решить ту же самую задачу с помощью простых клас
сов. Создадим сначала абстрактный базовый класс, где будет определяться ин
терфейс заданного типа.
// Листинг 06.04
abstract class ParamHandler
{
protected $source;
protected $params = [];
public function __ construct (string $source)

{
$this->source = $source;
}

public function addParam(string $key,

string $val)

{

$this->params[$key] = $val;
}

public function getAHParams () : array

{
return $this->params;
}

public static function getlnstance(string $filename):
ParamHandler
{

if (preg_match("/\.xml$/i”, $filename)) {
return new XmlParamHandler($filename);
}
return new TextParamHandler($filename);

}
abstract public function write(): bool;
abstract public function read(): bool;

198

ЧАСТЬ II

ОБЪЕКТЫ

В приведенном выше фрагменте кода мы определили метод addParamO,
чтобы пользователь мог вводить параметры в защищенное свойство $params,
а метод getAllParams (), чтобы предоставить доступ к копии массива пара
метров. Кроме того, мы создали статический метод getlnstance (), где про
веряется расширение файла и возвращается объект конкретного подкласса в
соответствии с результатами проверки. А самое главное — мы определили два
абстрактных метода, read () и write (), гарантировав тем самым, что любые
подклассы будут поддерживать этот интерфейс.
НА ЗАМЕТКУ. Разместить статический метод для формирования дочерних объектов в

родительском классе, конечно, удобно. Но такое проектное решение будет иметь
отрицательные последствия, поскольку возможности класса ParamHandler теперь
стали существенно ограничены в отношении работы с его конкретными подклассами,
возвращаемыми рассматриваемым статическим методом из центрального условно
го оператора. Что, например, произойдет, если понадобится работать с еще одним
форматом файлов конфигурации? Безусловно, если вы сопровождаете код класса
ParamHandler, то всегда можете исправить метод getlnstance (). Но если вы
создаете клиентский код, то изменение этого библиотечного класса может быть не
таким простым делом (на самом деле изменить его несложно, но в перспективе вам
придется вносить исправление при каждой переустановке пакета, в котором приме
няется этот класс). Вопросы создания объектов мы обсудим в главе 9, “Формирова
ние объектов”.

Определим далее подклассы, снова опуская подробности реализации ради
ясности примера кода.
// Листинг 06.05
class XmlParamHandler extends ParamHandler
{
public function write (): bool

{

// записать параметры в формате XML,
// используя свойство $this->params
}
public function read(): bool
{
// прочитать параметры в формате XML
// и заполнить свойство $this->params

}

}
// Листинг 06.06

class TextParamHandler extends ParamHandler
{
public function write () : bool
{
// записать текст,

ГЛАВА 6 « ОБЪЕКТЫ И ПРОЕКТИРОВАНИЕ

199

// используя свойство $this->params
}

public function read(): bool

{

// прочитать параметры в формате XML
// и заполнить свойство $this->params
}

}

В этих классах просто обеспечена реализация методов read () и write ().
Каждый класс будет читать и записывать данные в соответствующем формате.
В итоге из клиентского кода можно будет совершенно прозрачно записывать
параметры конфигурации в текстовый или XML-файл в зависимости от расши
рения имени файла:
// Листинг 06.07
$test = ParamHandler::getlnstance(__ DIR__ . ’’/params . xml" ) ;
$test->addParam("keyl", "vail");
$test->addParam("key2", "val2");
$test->addParam("key3", "val3");
$test->write(); // записать параметры в формате XML

Параметры конфигурации можно также прочитать из файла любого поддер
живаемого формата следующим образом:
// Листинг 06.08

$test = ParamHandler::getlnstance(__ DIR__ . "/params.txt");
$test->read(); // прочить в текстовом формате
$params = $test->getAllParams();
print_r($params);

Итак, какие выводы можно сделать из рассмотренных здесь двух подходов?

Ответственность
Управляющий код в примере процедурного кода несет ответственность за
выбор формата, но принимает это решение не один раз, а дважды. И хотя ус
ловный код перенесен в функции, это лишь скрывает факт принятия решений
в одном потоке. Вызов функции readParams () всегда происходит в ином кон
тексте, чем вызов функции write Params (), поэтому мы вынуждены повторять
проверку расширения файла в каждой функции (или выполнять разновидности
этой проверки).
В объектно-ориентированном примере кода выбор формата файла делается в
статическом методе getlnstance (), где расширение файла проверяется только
один раз и создается нужный подкласс. Клиентский код не несет ответственно
сти за реализацию. Он использует предоставленный объект, не зная и даже не
интересуясь, какому именно подклассу он принадлежит. Ему известно только,
что он работает с объектом типа ParamHandler, в котором поддерживаются

200

ЧАСТЬ II

ОБЪЕКТЫ

методы read () и write (). Если процедурный код занят подробностями реа
лизации, то объектно-ориентированный код работает только с интерфейсом, не
заботясь о подробностях реализации. А поскольку ответственность за реализа
цию лежит на объектах, а не на клиентском коде, то поддержку новых форматов
будет нетрудно внедрить прозрачным образом.

Связность
Связность — зто степень, до которой соседние процедуры зависят друг от
друга. В идеальном случае следует создавать компоненты, в которых ответ
ственность разделена совершенно четко и ясно. Если по всему коду разброса
ны связанные процедуры, то вскоре обнаружится, что их трудно сопровождать,
потому что придется прилагать усилия для поиска мест, где необходимо внести
изменения.
В рассматриваемых здесь классах типа ParamHandler связанные процедуры
собраны в общем контексте. Методы для обработки данных в формате XML со
вместно используют один контекст, где они могут обмениваться данными и где
необходимые изменения в одном методе могут быть легко отражены в другом,
если, например, потребуется изменить имя элемента XML-разметки. И это дает
основания считать, что классы ParamHandler имеют сильную связность.
А в процедурном примере кода связанные процедуры разделены. Код для
обработки данных формата XML распределен понескольким функциям.

Тесная связь
Тесная связь (coupling) возникает в том случае, когда отдельные части кода
системы тесно связаны одна с другой, так что изменение в одной части вызыва
ет потребность вносить изменения в других частях. Тесная связь не обязательно
возникает в процедурном коде, но последовательный характер такого кода при
водит к определенным осложнениям.
Такой вид тесной связи можно наблюдать в примере процедурного кода.
Функции readParams () и writeParams () производят одну и ту же проверку
расширения файла, чтобы определить порядок обработки данных. Любое изме
нение в логике работы одной функции должно быть реализовано и в другой.
Так, если бы потребовалось добавить новый формат файла, для этого пришлось
бы привести в соответствие все функции, чтобы новое расширение файла обра
батывалось в них одинаково. По мере внедрения новых функций, обрабатываю
щих другие форматы файлов, эта проблема будет только усугубляться.
А в примере объектно-ориентированного кода классы не связаны ни вместе,
ни с клиентским кодом. И если бы потребовалось внедрить поддержку нового
формата файла, то было бы достаточно создать новый подкласс, изменив един
ственную проверку в статическом методе getlnstance ().

ГЛАВА 6 Ж ОБЪЕКТЫ И ПРОЕКТИРОВАНИЕ

201

Ортогональность
Практически идеальное сочетание компонентов с четко определенными обя
занностями наряду с независимостью от более обширного контекста системы
иногда называют ортогональностью. Этот предмет обсуждается, например,
в книге Эндрю Ханта (Andrew Hunt) и Дэвида Томаса (David Thomas) The
Pragmatic Programmer (издательство Addison-Wesley Professional, 1999 r.)1.
Как утверждают авторы данной книги, ортогональность способствует по
вторному использованию кода, поскольку готовые компоненты можно включать
в новые системы без специальной их настройки. Такие компоненты должны
иметь четко определенные входные и выходные данные, независимые от како
го-либо более обширного контекста. В ортогональный код легче вносить измене
ния, поскольку изменение реализации будет локализовано в том компоненте, где
вносятся изменения. И, наконец, ортогональный код безопаснее. Последствия
ошибок будут ограничены в определенном контексте. В то же время ошибка в
чрезвычайно взаимозависимом коде может легко оказать эффект цепной реак
ции на остальную систему в более обширном контексте.
Но слабая связь и сильная связность не являются автоматическими признака
ми в контексте класса. Ведь в конечном счете целый пример процедурного кода
можно вставить в один неверный класс. Как же тогда достичь золотой середины
в разрабатываемом коде? Как правило, начинать рекомендуется с рассмотрения
классов, которые должны присутствовать в проектируемой системе.

Выбор классов
Порой определить границы классов бывает необычайно сложно. И это осо
бенно трудно сделать по мере развития классов вместе с проектируемой систе
мой.
При моделировании реальной ситуации эта задача может показаться нетруд
ной. Как правило, объектно-ориентированные системы являются программным
представлением реальных вещей, поскольку в них нередко применяются клас
сы вроде Person, Invoice и Shop. Следовательно, можно предположить, что
определение классов — это вопрос выявления некоторых объектов в системе
и наделения их определенными функциями с помощью методов. И хотя это не
плохая отправная точка, она не лишена скрытых опасностей. Если рассматри
вать класс как существительное, которым оперирует произвольное количество
глаголов, то окажется, что он будет все больше расширяться, потому что в ходе
разработки и внесения изменений потребуется, чтобы класс выполнял все боль
ше и больше обязанностей.
Рассмотрим в качестве примера класс ShopProduct, который был создан в гла
ве 3, “Основные положения об объектах”. В контексте системы, предназначенной
1 Эндрю Хант, Дэвид Томас. Программист-прагматик. Путь от подмастерья к мастеру
(пер. с англ., издательство “Лори”, 2012 г.).

202

ЧАСТЬ II

ОБЪЕКТЫ

для продажи товаров покупателям, определение класса ShopProduct является
вполне очевидным решением. Но окажется ли это решение единственным? Для
доступа к данным о товаре предоставляются методы getTitle () и getPrice ().
Если заказчики попросят предоставить механизм для вывода кратких сведений
о товарах для счетов-фактур и уведомлений о доставке товаров, то, вероятно,
имеет смысл определить метод write (). А если заказчики попросят предоста
вить механизм выдачи подобных сведений в разных форматах, то придется сно
ва обратиться к классу ShopProduct и надлежащим образом создать методы
writeXML () и writeXHTML () в дополнение к методу write (). С другой сторо
ны, в тело метода write () можно ввести условные операторы, чтобы выводить
данные в различных форматах в соответствии с признаком, устанавливаемым в
дополнительном аргументе.
Но в любом случае проблема заключается в том, что класс ShopProduct те
перь пытается делать слишком много. Кроме хранения сведений о самом товаре,
этот класс должен еще выбирать способы представления этих данных.
Так как же следует определять классы? Наилучший подход состоит в том,
чтобы рассматривать класс наделенным основной обязанностью и сделать эту
обязанность как можно более конкретной и единственной. Эту обязанность сле
дует выразить словами. Считается, что обязанность класса должна описываться
не более чем 25 словами с редкими включениями союзов “и” и “или”. И если
предложение, описывающее обязанность класса, становится слишком длинным
или перегружено подчиненными предложениями, значит, настало время поду
мать об определении новых классов, наделив их некоторыми из описанных обя
занностей.
Итак, обязанность класса ShopProduct — хранить сведения о товаре. И если
мы вводим в него методы для вывода данных в разных форматах, то тем самым
наделяем его новыми обязанностями представлять сведения о товарах. Как было
показано в главе 3, на основе этих отдельных обязанностей были определены
два разных класса. В частности, класс ShopProduct остался ответственным за
хранение сведений о товарах, а класс ShopProductWriter взял на себя обязан
ность за представление этих сведений. Уточнение этих обязанностей осущест
вляется в отдельных подклассах.
НА ЗАМЕТКУ. Далеко не все правила проектирования являются очень жесткими. Иногда

встречается код, предназначенный для хранения объектных данных и находящийся в
другом классе, совершенно не связанном с текущим классом. Очевидно, что самым
удобным местом для размещения таких функциональных возможностей служит теку
щий класс, хотя такой подход, на первый взгляд, нарушает правило наделения класса
только одной обязанностью. Такое удобство объясняется тем, что локальный метод
будет иметь полный доступ к полям экземпляра класса. Использование локальных
методов для целей сохраняемости позволит также не создавать параллельную ие
рархию классов сохраняемости, которые являются зеркальным отображением клас
сов сохраняемых объектов, что неизбежно приведет к их связанности. Другие стра
тегии обеспечения сохраняемости объектов будут рассмотрены в главе 12, “Шаблоны

ГЛАВА 6 ® ОБЪЕКТЫ И ПРОЕКТИРОВАНИЕ

203

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

Полиморфизм
Полиморфизм, или замена классов, — это общее свойство объектно-ориен
тированных систем. Его проявление уже раз встречалось в примерах кода из
данной книги.
Полиморфизм — это поддержка нескольких реализаций на основе общего
интерфейса. На первый взгляд такое определение может показаться сложным,
но на самом деле это понятие должно быть вам уже знакомо. О необходимости
полиморфизма обычно говорит наличие в коде большого количества условных
операторов.
Когда класс ShopProduct был впервые создан в главе 3, мы эксперимен
тировали с этим единственным классом, используя его для хранения сведений
о книгах и компакт-дисках, а также о других товарах общего назначения. Для
вывода краткой сводки о товаре мы полагались на ряд условных операторов,
как показано ниже.
// Листинг 03.31
public function getSummaryLine ()

{
Sbase = ”{$this->title} ( {$this->producerMainName},
$base .= ”{$this->producerFirstName} )’’;
if ($this->type == ’book’) {
$base ♦ = ’’: {$this->numPages} стр.”;
} elseif ($this->type == ’cd’) {
$base .=
Время звучания - {$this->playLength}’’;

}
return $base;

}

Именно эти условные операторы и определили функциональные возможно
сти двух подклассов: CDProduct и BookProduct. Аналогичным образом в рас
смотренном ранее примере процедурного кода именно в условных операторах,
проверяющих значения параметров, было заложено основание для объектно-о
риентированной структуры, к которой мы в конечном итоге пришли. Но одни и
те же условия проверяются в двух разных частях сценария, как показано ниже.
// Листинг 06.03
function readParams(string $source): array
{

$params = [ ] ;
if (preg_match(”/\.xml$/i”, $source)) {
// прочитать параметры в формате XML
// из указанного источника $source

204

ЧАСТЬ II W ОБЪЕКТЫ

} else {
// прочитать текстовые параметры из
// указанного источника $source
}
return $params;

}
function writeParams(array $params,

string $source)

{
if (preg_match(”/\.xml$/i", $source))
// записать в формате XML параметры
// в указанный источник $source
} else {
// записать текстовые параметры
// в указанный источник $source

{

}

}

В каждой из этих частей напрашивается решение выделить их в отдельные
подклассы XmlParamHandler и TextParamHandler, которые в конце концов и
были созданы. В этих подклассах реализованы методы write () и read() из
абстрактного базового класса ParamHandler, который они расширяют.
// Листинг 06.09
// Может быть возвращен объект типа XmlParamHandler
// или объект типа TextParamHandler
$test = ParamHandler::getlnstance($file);

// Может быть сделан вызов XmlParamHandler::read()
// или вызов TextParamHandler::read()
$test->read();
$test->addParam("newkeyl",

"newvall");

// Может быть сделан вызов XmlParamHandler::write()
// или вызов TextParamHandler::write()
$test->write();

Важно отметить, что полиморфизм не отрицает использование условных опе
раторов. Обычно в методах вроде ParamHandler: :getlnstance () с помощью
оператора switch или if определяется, какие именно объекты следует возвра
тить. Но это ведет к сосредоточению кода с условными операторами в одном
месте.
Как было показано ранее, в языке РНР приходится создавать интерфейсы,
определяемые в абстрактных классах. Это удобно, потому что дает уверенность,
что в конкретном дочернем классе будут в точности поддерживаться те же са
мые сигнатуры методов, которые были определены в абстрактном родительском
классе. В них будут включены все объявления типов классов и модификаторы
доступа. Поэтому все дочерние классы общего суперкласса можно рассматри
вать в клиентском коде как взаимозаменяемые, при условии, что он опирается
только на функциональные возможности, определенные в родительском классе.

ГЛАВА б ж ОБЪЕКТЫ И ПРОЕКТИРОВАНИЕ

205

Инкапсуляция
Инкапсуляция — это просто сокрытие данных и функциональных возможно
стей от клиентского кода. И в то же время это ключевое понятие ООП.
На самом элементарном уровне данные инкапсулируются путем объявления
свойств как private или protected. Скрывая свойство от клиентского кода,
мы соблюдаем общий интерфейс и тем самым предотвращаем случайное по
вреждение данных объекта.
Полиморфизм демонстрирует другой вид инкапсуляции. Скрывая различные
реализации за общим интерфейсом, мы прячем основополагающие стратегии
от клиентского кода. Это означает, что любые изменения, внесенные за этим
интерфейсом, являются прозрачными для более обширного контекста остальной
системы. Мы можем ввести новые классы или изменить исходный код в классе,
и это не приведет к ошибкам. Значение имеет не интерфейс, а действующий за
ним механизм. Чем более независимы подобные механизмы, тем меньше веро
ятность, что внесенные изменения или поправки окажут эффект цепной реакции
на ваши проекты.
В каком-то отношении инкапсуляция — это ключ к ООП. Наша цель — сде
лать каждую часть проектируемой системы как можно более независимой от
остальных ее частей. Классы и методы должны получать столько информации,
сколько требуется для выполнения стоящих перед ними задач, которые должны
быть ограничены конкретными рамками и ясно определены.
Внедрение ключевых слов private, protected и public облегчает ин
капсуляцию. Но инкапсуляция — это и образ мышления. В версии РНР 4 не
было предусмотрено формальной поддержки для сокрытия данных. О конфи
денциальности необходимо было предупреждать с помощью документации и
соглашений об именовании. Например, символ подчеркивания — это обычный
способ предупреждения о закрытом свойстве.
var $_touchezpas;

Безусловно, написанный код приходилось тщательно проверять, потому что
конфиденциальность не была строго соблюдена. Но любопытно, что ошибки
случались редко, потому что структура и стиль кода довольно четко определяли,
какие свойства трогать нельзя.
И даже в версии РНР 5 можно нарушить правила и выяснить точный подтип
объекта, который используется в контексте замены классов, просто выполнив
операцию instanceof:
function workWithProducts ( ShopProduct $prod )
if ( $prod instanceof CDProduct ) {
// обработать данные о компакт-диске

} else if ($prod instanceof BookProduct )
// обработать данные о книге

{

{

206

ЧАСТЬ II Я8 ОБЪЕКТЫ

Для выполнения подобных действий должна быть серьезная причина, по
скольку в целом это вносит некоторую неопределенность. Запрашивая конкрет
ный подтип, как в данном примере, мы устанавливаем жесткую зависимость.
Если же особенности подтипа скрываются полиморфизмом, то можно совер
шенно безболезненно изменить иерархию наследования класса ShopProduct,
не опасаясь негативных последствий. Но в рассматриваемом здесь коде это
му положен предел. Если теперь нам потребуется усовершенствовать классы
CDProduct и BookProduct, мы должны не забывать о возможном проявлении
нежелательных побочных эффектов в методе workWithProducts ().
Из данного примера мы должны вынести два урока. Во-первых, инкапсуля
ция помогает создать ортогональный код. И во-вторых, степень инкапсуляции,
которую можно соблюсти, к делу не относится. Инкапсуляция — это методи
ка, которую должны в равной степени соблюдать как сами классы, так и их
клиенты.

Забудьте, как это делается
Если вы похожи на меня, то упоминание о конкретной задаче заставит ваш
ум интенсивно работать в поисках подходящего решения. Вы можете выбрать
функции, которые могут решить данную задачу, поискать регулярные выраже
ния, исследовать пакеты Composer. Возможно, у вас есть фрагмент кода из ста
рого проекта, который выполняет нечто подобное, и его можно вставить в но
вый код. На стадии разработки вы выиграете, если на некоторое время отложите
все это в сторону, выбросив из головы всякие процедуры и механизмы.
Думайте только о ключевых участниках системы: требующихся типах дан
ных и интерфейсах. Безусловно, знание программируемого процесса окажет
помощь в ваших размышлениях. В частности, классу, в котором открывается
файл, необходимо передать имя этого файла; код базы данных должен опериро
вать именами таблиц, паролями и т.д. Но старайтесь, чтобы ход ваших мыслей
следовал структурам и отношениям в разрабатываемом коде. В итоге вы обна
ружите, что реализация легко встанет на свое место за правильно определенным
интерфейсом. И тогда вы получите широкие возможности заменить, улучшить
или расширить реализацию, если в этом возникнет потребность, не затрагивая
остальную систему в более обширном контексте.
Чтобы сосредоточить основное внимание на интерфейсе, старайтесь мыслить
категориями абстрактных базовых классов, а не конкретных дочерних классов.
Так, в рассмотренном выше примере кода для извлечения параметров интер
фейс является самым важным аспектом проектирования. Для этого требуется
тип данных, предназначенный для чтения и записи пар “имя-значение”. Для
такого типа данных важна именно эта обязанность, а не реальный носитель,
на котором будут сохраняться данные или способы их хранения и извлечения.
Проектирование системы необходимо сосредоточить вокруг абстрактного класса

ГЛАВА 6

ОБЪЕКТЫ И ПРОЕКТИРОВАНИЕ

207

ParamHandler, внедрив только конкретные стратегии, чтобы в дальнейшем
можно было читать и записывать параметры. Таким образом, полиморфизм и
инкапсуляция внедряются в проектируемую систему с самого начала. Такая
структура уже тяготеет к использованию замены классов.
Но мы, конечно, знали с самого начала, что должны существовать тексто
вая и XML-реализации класса ParamHandler, которые, безусловно, оказывают
влияние на проектируемый интерфейс. При проектировании интерфейсов всегда
есть над чем подумать, прежде чем выбрать подходящее решение.
"Банда четырех” в упоминавшейся ранее книге Design Patterns сформулиро
вала этот принцип следующим образом: ‘‘Программируйте на основе интерфей
са, а не его реализации”. Это высказывание заслуживает того, чтобы вы занесли
его как памятку в свою записную книжку.

Четыре явных признака
недоброкачественного кода
Очень немногие разработчики принимают совершенно правильные решения
еще на стадии проектирования. Большинство из них исправляют код по мере
изменения требований к нему или в результате более полного понимания ха
рактера решаемой задачи.
Но по мере изменения кода он может в конечном счете выйти из-под кон
троля. Если ввести метод в одном месте, а класс — в другом, то система станет
постепенно усложняться. Но, как было показано ранее, сам код может указы
вать пути для его совершенствования. Такие признаки в разрабатываемом коде
иногда называют запахами кода (code smells), или недоброкачественным кодом
(буквально — кодом “с душком”). Речь идет о тех местах в коде, где необхо
димо внести конкретные исправления или, по крайней мере, еще раз проана
лизировать проектное решение. В этом разделе некоторые уже рассмотренные
моменты будут выделены в четыре явных признака недоброкачественного кода,
которые необходимо всегда иметь в виду в процессе программирования.

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

208

ЧАСТЬ II ж ОБЪЕКТЫ

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

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

Условные операторы
У вас, вероятно, будут веские причины для употребления операторов if и
switch в своем коде. Но иногда наличие подобных структур служит сигналом
прибегнуть к полиморфизму.
Если вы обнаружите, что проверяете некоторые условия в классе слишком
часто, особенно если эти проверки повторяются в нескольких методах, то, воз
можно, это сигнализирует о том, что один класс нужно разделить на два класса
или более. Выясните, не предполагает ли структура условного кода обязанности,
которые можно выразить в отдельных классах. В этих новых классах должны
быть реализованы методы общего абстрактного базового класса. Вполне веро
ятно, что затем вам придется найти способ передать нужный класс клиентскому
коду. О некоторых проектных шаблонах для создания объектов речь пойдет в
главе 9, “Формирование объектов”.

ГЛАВА б ® ОБЪЕКТЫ И ПРОЕКТИРОВАНИЕ

209

Язык UML
В примерах, приведенных до сих пор, код не требовал особых пояснений.
В этих кратких примерах демонстрировались такие понятия, как наследование
и полиморфизм. И это было полезно, потому что в центре нашего внимания на
ходился сам язык РНР. Но по мере увеличения размеров и сложности примеров
использование только исходного кода для демонстрации широкого спектра про
ектных решений становится нецелесообразным. Согласитесь, нелегко увидеть
общую картину в нескольких строках кода.
Сокращение UML обозначает Unified Modeling Language (унифицированный
язык моделирования). История создания этого языка очень интересна. По сло
вам Мартина Фаулера (из книги UML Distilled, издательство Addison-Wesley
Professional, 1999 г.2), язык UML возник как стандарт после многолетних ин
теллектуальных и бюрократических споров в сообществе приверженцев объек
тно-ориентированного проектирования.
Результатом этих споров стал эффективный графический синтаксис для опи
сания объектно-ориентированных систем. В этом разделе мы рассмотрим его
только в общих чертах, но вскоре вы поймете, что “скромный малый” UML
прошел долгий путь развития.
Диаграммы классов позволяют описывать структуры и шаблоны таким обра
зом, чтобы их смысл становился ясным и понятным. Такой кристальной ясности
трудно достичь с помощью фрагментов кода или маркированных списков.

Диаграммы классов
Диаграммы классов — это всего лишь один аспект UML, но именно они
чаще всего употребляются в объектно-ориентированном проектировании. А по
скольку они очень полезны для описания объектно-ориентированных связей, мы
будем часто пользоваться ими далее в книге.
Представление классов

Как и следовало ожидать, классы являются главными составными элемента
ми диаграмм классов. На такой диаграмме класс представлен в виде именован
ного прямоугольника (рис. 6.1).
ShopProduct

Рис. 6.1. Представление класса в UML

2 Мартин Фаулер. UML. Основы. Краткое руководство по стандартному языку объект
ного моделирования (пер. с англ., издательство “Символ-Плюс”, 2011 г.).

210

ЧАСТЬ II ш ОБЪЕКТЫ

Прямоугольник, представляющий класс, делится на три части, в первой из
которых отображается имя класса. Разделительные линии необязательны, если
больше никакой дополнительной информации, кроме имени класса, не предо
ставляется. Составляя диаграммы классов, можно обнаружить, что для неко
торых классов достаточно того уровня детализации, который представлен на
рис. 6.1. На диаграмме классов совсем не обязательно обозначать все поля и
методы, и даже все классы.
Для представления абстрактных классов на диаграмме имя класса выделя
ется курсивом (рис. 6.2), или же оно дополняется обозначением {abstract},
как показано на рис. 6.3. Первый способ считается более распространенным, а
второй — более удобным для того, чтобы делать заметки в записной книжке.

ShopProductWriter
Рис. 6.2. Пример представ
ления абстрактного класса

ShopProductWriter

{abstract}
Рис. 6.3. Пример представле

ния абстрактного класса с до
полнительным ограничением
НА ЗАМЕТКУ. Обозначение {abstract} — это пример ограничения. На диаграммах

классов ограничения служат для описания порядка применения отдельных элемен
тов. Специальных правил для указания текста в фигурных скобках не установлено. Он
просто должен ясно давать пояснение каких-нибудь условий, устанавливаемых для
элемента.
Интерфейсы определяются таким же образом, как и классы, за исключением
того, что они должны включать стереотип (т.е. расширение словаря UML), как
показано на рис. 6.4.

«interface»
Chargeable

Рис. 6.4. Пример представ
ления интерфейса

ГЛАВА 6

ОБЪЕКТЫ И ПРОЕКТИРОВАНИЕ

211

Атрибуты

Вообще говоря, атрибуты описывают свойства класса. Атрибуты перечисля
ются в той части диаграммы, которая располагается непосредственно под име
нем класса (рис. 6.5).
ShopProduct

#price: int = О
Рис. 6.5. Пример обозначения атрибута

Рассмотрим подробнее атрибут из примера, приведенного на рис. 6.5. Первый
знак (#) в этом атрибуте обозначает уровень видимости атрибута или управле
ния доступом к нему. В табл. 6.1 перечислены знаки для обозначения уровня
видимости.
Таблица 6.1. Знаки уровня видимости

Знак

Уровень видимости

Описание

+

Общедоступный

Доступность для всего кода

-

Закрытый

Доступность только для текущего класса

#

Защищенный

Доступность только для текущего класса и его подклассов

После знака уровня видимости указывается имя атрибута. В данном случае
описывается свойство ShopProduct: : $price. Двоеточие служит для отделения
имени атрибута от его типа, а возможно, и от его стандартного значения. Сле
дует еще раз подчеркнуть, что в описание атрибута можно включить столько
подробностей, сколько потребуется для ясности.
Операции

Операции описывают методы, а точнее, вызовы, которые могут быть сдела
ны для экземпляра класса. На рис. 6.6 показаны две операции, обозначаемые в
классе ShopProduct.
ShopProduct

#price: int = О

tsetDiscount(amount:int)
+getTitle(): String
Рис. 6.6. Представление операций

Как видите, для обозначения операций служит такой же синтаксис, как и для
обозначения атрибутов. Знак уровня видимости предшествует имени метода.

212

ЧАСТЬ II

ОБЪЕКТЫ

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

В языке UML отношения наследования описываются в виде обобщений. Это
отношение обозначается линией, ведущей от подкласса к родительскому классу.
Эта линия оканчивается незаполненной замкнутой стрелкой. В качестве при
мера на рис. 6.7 показана связь между классом ShopProduct и его дочерними
классами.

Рис. 6.7. Описание наследования

Средствами языка UML описывается также связь между интерфейсом и клас
сами, в которых он реализован. Так, если бы в классе ShopProduct был реа
лизован интерфейс Chargeable, мы бы добавили его в диаграмму класса, как
показано на рис. 6.8.

Рис. 6.8. Описание реализации интерфейса

ГЛАВА 6

ОБЪЕКТЫ И ПРОЕКТИРОВАНИЕ

213

Ассоциации

Наследование — это только одно из отношений в объектно-ориентирован
ной системе. Ассоциация происходит в том случае, когда в классе объявляется
свойство, где содержится ссылка на экземпляр (или экземпляры) другого класса.
В качестве примера на рис. 6.9 моделируются два класса и образуется ассоци
ация между ними.
Teacher

Pupil

Рис- 6.9, Ассоциация класса

На данном этапе нам неизвестна природа этих отношений. Мы только указа
ли, что у объекта типа Teacher будет ссылка на один или несколько объектов
типа Pupil, или наоборот. Это отношение может быть или не быть взаимным.
Стрелки на диаграмме классов служат для описания направления ассоциа
ции. Так, если в классе Teacher имеется ссылка на экземпляр класса Pupil,
а не наоборот, то их ассоциацию следует определить с помощью стрелки, на
правленной от класса Teacher к классу Pupil. Такая ассоциация называется
однонаправленной и показана на рис. 6.10.

Рис. 6.10. Пример однонаправлен

ной ассоциации

Если в каждом классе имеется ссылка на другой класс, то для обозначения
двунаправленного отношения служит двунаправленная стрелка, как показано на
рис. 6.U.
Teacher Pupil

Рис. 6.11. Двунаправленная ассоциация

Имеется также возможность указать количество экземпляров класса, на кото
рые ссылается другой класс в ассоциации. Для этого достаточно указать число
или диапазон чисел рядом с каждым классом. Можно также употребить знак
звездочки (*), обозначающий любое число. На рис. 6.12 показано, что может
существовать только один объект типа Teacher и нуль или больше объектов
типа Pupil.

214

ЧАСТЬ II ш ОБЪЕКТЫ

Рис. 6.12. Пример определения

множественности для ассоциации

На рис. 6.13 показано, что в ассоциации может быть один объект типа
Teacher и от пяти до десяти объектов типа Pupil.

Рис. 6.13. Еще один вариант определе

ния множественности для ассоциации
Агрегирование и композиция

Агрегирование и композиция похожи на ассоциацию. Все эти термины слу
жат для описания ситуации, когда в классе содержится постоянная ссылка на
один или несколько экземпляров другого класса. Но с помощью агрегирования
и композиции экземпляры, на которые ссылаются, формируют внутреннюю
часть ссылающегося объекта.
Что касается агрегирования, то объекты составляют основную часть объек
та-контейнера, который их содержит, но они могут одновременно содержаться
и в других объектах. Отношение агрегирования обозначается линией, которая
начинается с незаполненного ромба. В качестве примера на рис. 6.14 определя
ются два класса, Schoolclass и Pupil, причем класс Schoolclass агрегирует
класс Pupil.

Рис. 6.14. Пример агрегирования

ГЛАВА 6 ® ОБЪЕКТЫ И ПРОЕКТИРОВАНИЕ

215

Класс Pupil состоит из учеников, но на один и тот же объект типа Pupil
могут одновременно ссылаться различные экземпляры класса Schoolclass.
Если же понадобится распустить школьный класс, для этого необязательно уда
лять ученика, который может посещать другие классы.
Композиция представляет собой еще более сильное отношение, чем описан
ное выше. В композиции на содержащийся объект может ссылаться только со
держащий его объект-контейнер. И он должен быть удален вместе с удаляемым
объектом-контейнером. Отношения композиции обозначаются таким же обра
зом, как и отношения агрегирования, только с заполненным ромбом. Пример
отношения композиции наглядно показан на рис. 6.15.

Рис. 6.15. Пример композиции

В классе Person имеется постоянная ссылка на объект типа SocialSecurityData. Экземпляр этого объекта может принадлежать только содержащему
его объекту типа Person.
Описание отношений использования

В языке UML отношение использования описывается в виде зависимости.
Это самое неустойчивое из всех отношений, рассматриваемых в данном разделе,
потому что оно не описывает постоянную связь между классами. Используемый
класс может передаваться в качестве аргумента или быть получен в результате
вызова метода.
В классе Report, приведенном на рис. 6.16, используется объект типа
ShopProductWriter. Отношение использования обозначается пунктирной ли
нией со стрелкой, имеющей незамкнутый контур на конце. Эта линия соединяет
рассматриваемые здесь класс и объект. Но при таком отношении ссылка на объект
не хранится в виде свойства, как, например, в объекте типа ShopProductWriter,
где хранится массив ссылок на объекты типа ShopProduct.
Использование примечаний

На диаграммах классов отображается структура системы, но они не дают до
статочного представления о самом процессе. Как следует из рис. 6.16, в объекте
типа Report используется объект типа ShopProductWriter, но механизм этого
процесса неизвестен. На рис. 6.17 используются примечания, которые помогают
немного прояснить эту ситуацию.

216

ЧАСТЬ II

ОБЪЕКТЫ

Рис. 6.16. Пример отношения использования зависимостей

Рис. 6.17. Использование примечаний для прояснения зависимости

Как видите, примечание обозначается на диаграмме прямоугольником с
уголком, загнутым справа вверху. Обычно в примечании содержатся фрагменты
псевдокода.

ГЛАВА 6

ОБЪЕКТЫ И ПРОЕКТИРОВАНИЕ

217

Примечание вносит некоторую ясность в рассматриваемую здесь диаграмму
классов. Теперь мы видим, что объект типа ShopProductWriter используется
в объекте типа Report для вывода данных о товаре. На самом деле отноше
ния использования не всегда настолько очевидны. В некоторых случаях даже
примечание может не предоставить достаточной информации. Правда, взаимо
действие объектов в проектируемой системе, а также структуру классов можно
смоделировать.

Диаграмма последовательностей
В основе диаграммы последовательности лежит объект, а не класс. Она служит для поэтапного моделирования процесса в проектируемой системе.
Составим простую диаграмму последовательности, моделируя порядок вы
вода данных о продукте из объекта типа Report. На диаграмме последователь
ности объекты из проектируемой системы представлены справа налево, как по
казано на рис. 6.18.

Report

Productstore

ShopProductWriter

ShopProduct

Рис. 6.18. Пример представления объектов из проектируемой
системы на диаграмме последовательности

Объекты обозначены на этой диаграмме только именем класса. Если бы
имелось несколько действующих независимо экземпляров одного класса, имя
каждого объекта следовало бы указать в формате метка-.класс (например,
productl: ShopProduct).
Время жизни моделируемого процесса отображается на диаграмме последо
вательности сверху вниз, как показано на рис. 6.19.
Вертикальными пунктирными линиями на этой диаграмме обозначается вре
мя существования объектов в системе, а прямоугольниками на линиях жизни —
направленность процесса. Если просмотреть рис. 6.19 сверху вниз, то можно
увидеть, как процесс продвигается по объектам в системе. Но это трудно понять
без сообщений, которыми обмениваются объекты. Такие сообщения добавлены
на рис. 6.20.
Стрелками обозначены сообщения, которыми обмениваются объекты. Воз
вращаемые значения зачастую остаются неявными, хотя они могут быть обозна
чены пунктирной линией, идущей от вызываемого объекта к объекту, отправля
ющему сообщение. Каждое сообщение помечается вызовом соответствующего
метода. Для меток имеется свой синтаксис, где квадратные скобки обозначают
заданное условие. Так, следующая запись:
[okToPrint]
write ()

218

ЧАСТЬ II № ОБЪЕКТЫ

I
I
I
I
I
I
I

I
I
I
I

I
I
I
I
I
I
Рис. 6.19. Пример обозначения линий жизни объектов на диа
грамме последовательности

Report

Productstore

ShopProductWriter

ShopProduct

getProductsO i

addProductsO

wrlteO

I
►

*[для каждого ShMProlduct] getSummaryLineQ

T

Рис. 6.20. Пример завершенной диаграммы последовательности

ГЛАВА 6 ■ ОБЪЕКТЫ И ПРОЕКТИРОВАНИЕ

219

означает, что вызов метода write () может произойти только при выполнении
указанного условия. Знак звездочки служит для того, чтобы обозначить повторе
ние, как показано ниже. А далее может последовать соответствующее пояснение
в квадратных скобках, хотя это и необязательно.
*[для каждого ShopProduct]
write()

Теперь диаграмму последовательности, приведенную на рис. 6.20, можно
интерпретировать сверху вниз. В частности, объект типа Report получает спи
сок объектов типа ShopProduct из объекта типа Productstore. Этот объект
передает полученный список объекту типа ShopProductWriter, где сохраня
ются ссылки на данные объекты, хотя, глядя на диаграмму последовательно
сти, об этом можно только догадываться. Объект типа ShopProductWriter
вызывает метод ShopProduct::getSummaryLine () для каждого объекта типа
ShopProduct, ссылка на который хранится в массиве, добавляя полученный
результат к выводимым данным.
Как видите, диаграммы последовательностей позволяют моделировать про
цессы, фиксируя срезы динамического взаимодействия и представляя их с нео
быкновенной ясностью.
НА ЗАМЕТКУ. Посмотрите внимательно на рис. 6.16 и 6.20. Обратите внимание, как на

диаграмме класса проиллюстрирован полиморфизм (наглядно показаны классы, ко
торые происходят от классов ShopProductWriter и ShopProduct). А теперь по
смотрите, насколько этот факт становится очевидным, когда мы моделируем взаимо
действие между объектами. Нам требуется, чтобы объекты работали по возможности
с самыми общими из имеющих типов данных и чтобы можно было скрыть подробно
сти их реализации.

Резюме
В этой главе мы немного отошли от конкретных особенностей ООП и рас
смотрели некоторые важные вопросы проектирования. В частности, мы ис
следовали такие понятия, как инкапсуляция, связность, слабая и тесная связь,
которые являются важными аспектами проектирования гибкой и повторно ис
пользуемой объектно-ориентированной системы. Мы также рассмотрели сред
ства языка UML как очень важное основание для работы с шаблонами, о кото
рых речь пойдет далее в этой книге.

ЧАСТЬ III

Шаблоны

ГЛАВА 7
£

Назначение и применение
проектных шаблонов
Большинство задач, которые нередко приходится решать программистам, уже
давно решены другими членами их сообщества. Проектные шаблоны (patterns,
иногда их так и называют — паттернами) как раз и являются тем средством, с
помощью которого люди могут делиться друг с другом накопленным опытом.
Как только шаблон становится всеобщим достоянием, он обогащает наш лекси
кон и позволяет легко обмениваться с другими новыми идеями проектирования
и последствиями их осуществления. С помощью проектных шаблонов легко
выделяются общие задачи, определяются проверенные решения и описываются
вероятные результаты. Во многих книгах и статьях основное внимание уделяет
ся особенностям конкретных языков программирования, имеющимся функциям,
классам и методам. А в каталогах шаблонов, наоборот, акцент сделан на том,
как перейти в своих проектах от этих основ (“что делать”) к осмыслению задач
и возможных решений (“зачем и как делать”).
В этой главе будут представлены проектные шаблоны и проанализированы
некоторые причины их широкой распространенности. В ней, в частности, будут
рассмотрены следующие вопросы.

Основы шаблонов. Что такое проектные шаблоны?
Структура шаблона. Каковы основные элементы проектного шаблона?

Преимущества шаблонов. Почему шаблоны стоят того, чтобы их изучать?

224

ЧАСТЬ III Й ШАБЛОНЫ

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

Гради Буч (Grady Booch),
из книги Core J2EE Patterns'.
Проектный шаблон — это решение задачи в определенном
контексте.
"Банда четырех” (The Gang of Four),
из книги Design Patterns: Elements of Reusable
Object-Oriented Software1.
Как следует из приведенных выше цитат, проектный шаблон — это задача,
которая взята из норм надлежащей практики программистов и решение которой
проанализировано и объяснено. Задачи имеют свойство повторяться, и веб-про
граммистам приходится решать их снова и снова. В частности, как обработать
входящий запрос? Как преобразовать данные в команды для проектируемой си
стемы? Как запросить данные? Как представить результаты? Со временем мы
находим более или менее изящные ответы на все эти вопросы и создаем не
формальный набор методик, которые затем используем снова и снова в своих
проектах. Эти методики и есть проектные шаблоны.
С помощью проектных шаблонов описываются и формализуются типовые
задачи и их решения. В результате опыт, который нарабатывается с большим
трудом, становится доступным широкому сообществу программистов. Шаблоны
должны быть построены главным образом по восходящему, а не нисходящему
принципу. Они укоренены в практике, а не в теории. Но это совсем не означает,
что в проектных шаблонах отсутствует элемент теории, как будет показано в
следующей главе. Шаблоны основаны на реальных методах, применяемых про
граммистами на практике. Известный приверженец проектных шаблонов Мар
тин Фаулер говорит, что он открывает шаблоны, а не создает их. Поэтому мно
гие шаблоны будут вызывать у вас ощущение уже пройденного, ведь вы будете
узнавать в них методики, которыми пользуетесь сами.
Каталог шаблонов — это не книга кулинарных рецептов. Рецептам можно
следовать буквально, а код можно скопировать и вставить в проект с незначи
тельными изменениями. Понимать весь код, используемый в рецепте, обязатель
но не всегда. А проектные шаблоны описывают подходы к решению конкретных
задач. Подробности реализации могут существенно изменяться в зависимости
1 Дипак Алур, Джон Крупи, Дэн Малке. Образцы J2EE. Лучшие решения и стратегии
проектирования (пер. с англ., издательство “Лори”, 2013 г.).

2 Эрих Гамма, Ричард Хелм, Ральф Джонсон, Джон Влиссидес. Приемы объектно-ориен
тированного проектирования. Паттерны проектирования (пер. с англ., издательство “Пи
тер”, 2007 г.).

ГЛАВА 7 ® НАЗНАЧЕНИЕ И ПРИМЕНЕНИЕ ПРОЕКТНЫХ ШАБЛОНОВ

225

от более широкого контекста. От этого контекста зависят выбор используемого
языка программирования, характер приложения, масштабы проекта и особенно
сти решения конкретной задачи.
Допустим, в проекте требуется создать систему шаблонной обработки. На
основании имени файла шаблона необходимо синтаксически проанализировать
его содержимое и построить дерево объектов, представляющих обнаруженные
дескрипторыразметки.
Сначала синтаксический анализатор просматривает текст на предмет поис
ка триггерных лексем. Обнаружив соответствие, он передает лексему другому
объекту-анализатору, который специализируется на чтении содержимого дес
крипторов разметки. В итоге данные шаблона продолжают анализироваться до
тех пор, пока не произойдет синтаксическая ошибка, достигнут их конец или
найдена другая триггерная лексема. Обнаружив такую лексему, объект-анали
затор должен также передать ее на обработку соответствующей программе —
скорее всего, анализатору аргументов. Все вместе эти компоненты образуют так
называемый рекурсивный нисходящий синтаксический анализатор.
Следовательно, участниками проектируемой системы можно назвать следую
щие классы: MainParser, TagParser и Argumentparser. Потребуется также
класс ParserFactory, создающий и возвращающий эти объекты.
Но все, конечно, идет не так гладко, как хотелось бы, и в дальнейшем на
одном из совещаний выясняется, что в шаблонах нужно поддерживать не
сколько синтаксисов. И теперь нужно создать параллельный набор объектованализаторов в соответствии с конкретным синтаксисом: OtherTagParser,
OtherArgumentParser и т.д.
Таким образом, поставлена следующая задача: формировать разные наборы
объектов в зависимости от конкретной ситуации, и эти наборы объектов долж
ны быть более или менее прозрачными для других компонентов системы. Но
оказывается, что “Банда четырех” в своей книге определила следующую задачу
для проектного шаблона Abstract Factory (Абстрактная фабрика): “Преду
смотреть интерфейс для создания семейств связанных или зависимых объектов
без указания их конкретных классов”.
Этот проектный шаблон вполне подходит в данном случае! Сама суть по
ставленной задачи определяет и очерчивает рамки применения данного шабло
на. Но решение этой задачи не имеет ничего общего с операциями вырезания
и вставки, как поясняется в главе 9„ “Формирование объектов”, где подробно
рассматривается проектный шаблон Abstract Factory.
Название шаблона уже само по себе очень ценно. Подобным образом созда
ется нечто вроде общего словаря, который годами накапливается и используется
в среде профессионалов. Такие условные обозначения помогают в совместных
разработках, когда оцениваются и проверяются альтернативные подходы и раз
ные последствия их применения. Например, при обсуждении семейств альтер
нативных синтаксических анализаторов достаточно сказать коллегам по работе,

226

ЧАСТЬ III

ШАБЛОНЫ

что в проектируемой системе каждый набор создается по проектному шаблону
Abstract Factory. Одни кивнут головой с умным видом, кто-то сразу поймет,
о чем идет речь, а кто-нибудь отметит про себя, что нужно будет ознакомиться
с этим шаблоном позже. Но суть в том, что у такой системы набора понятий
и разных результатов их воплощения имеется абстрактный описатель, способ
ствующий созданию более кратких обозначений, как демонстрируется далее в
этой главе.
И наконец, по международному законодательству некорректно писать о
проектных шаблонах, не процитировав Кристофера Александера (Christopher
Alexander), профессора архитектуры, работы которого оказали огромное вли
яние на первых сторонников объектно-ориентированных проектных шабло
нов. Вот что он пишет в своей книге A Pattern Language (издательство Oxford
University Press, 1977 г.)3.

Каждый проектный шаблон описывает задачу, которая возника
ет снова и снова, а затем описывает суть решения данной задачи,
так что вы можете использовать это решение миллион раз, всякий
раз делая это по-другому
Очень важно, что это определение, хотя оно относится к архитектурным
задачам и решениям, начинается с формулировки задачи и ее более широко
го контекста и переходит к решению. За последние годы прозвучало немало
критики по поводу того, что проектными шаблонами злоупотребляют, особен
но неопытные программисты. Причина в том, что решения применялись там,
где не была сформулирована задача и отсутствовал соответствующий контекст.
Шаблоны — это нечто большее, чем конкретная организация классов и объек
тов, совместно работающих определенным образом. Шаблоны создаются для
определения условий, в которых должны применяться решения, а также для
обсуждения результатов этих решений.
В данной книге основной акцент будет сделан на особенно влиятельном на
правлении в сфере проектных шаблонов: форме, описанной в упоминавшейся
в начале этой главы книге Design Patterns: Elements of Reusable Object-Oriented
Software, Она посвящена применению проектных шаблонов при разработке объ
ектно-ориентированного программного обеспечения, и в ней описываются не
которые классические шаблоны, которые имеются в большинстве современных
объектно-ориентированных проектах.
Эта книга “Банды четырех” очень важна не только потому, что в ней описы
ваются основные проектные шаблоны, но и потому, что в ней рассматриваются
принципы проектирования, которые положены в основу этих шаблонов. Неко
торые из этих принципов мы рассмотрим в следующей главе.

3 Кристофер Александер, Сара Исикава, Мюррей Силверстайн. Язык шаблонов. Гэрода.
Здания. Строительство (пер. с англ., издательство студии Артемия Лебедева, 2014 г.).

ГЛАВА 7 « НАЗНАЧЕНИЕ И ПРИМЕНЕНИЕ ПРОЕКТНЫХ ШАБЛОНОВ

227

На заметку. Проектные шаблоны, описанные “Бандой четырех” и в данной книге, слу

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

Краткий обзор проектных шаблонов
По существу, проектный шаблон состоит из четырех частей: названия, поста
новки задачи, описания ее решения и последствий.

Название
Выбор названия для шаблона очень важен. Несколькими краткими словами
можно обозначить довольно сложные задачи и их решения, поэтому при выборе
названий для проектных шаблонов следует соблюдать золотую середину между
краткостью и описательностью. “Банда четырех” утверждает: “Поиск удачных
названий был одной из самых трудных задач при разработке нашего каталога”.
И с этим согласен Мартин Фаулер, заявляя: “Названия для шаблонов чрезвычай
но важны, потому что одна из целей шаблонов — создать словарь, позволяю
щий разработчикам общаться более эффективно” (из книги Patterns of Enterprise
Application Architecture, издательство Addison-Wesley Professional, 2002 r.)4.
В своей книге Patterns of Enterprise Application Architecture Мартин Фаулер
совершенствует шаблон доступа к базе данных, описание которого я впервые
обнаружил в упоминавшейся в начале этой главы книге Core J2EE Patterns.
В частности, Фаулер определяет два шаблона, которые описывают специали
зацию старого шаблона. Логика такого подхода ясна и точна: один из новых
шаблонов моделирует объекты предметной области, в то время как другой —
таблицы базы данных, тогда как в предыдущем труде это различие было нечет
ким. Тем не менее заставить себя мыслить категориями новых шаблонов было
нелегко. Я лично пользовался названием первоначального шаблона при проекти
ровании и документировании так долго, что оно прочно вошло в мой лексикон.

Постановка задачи
Какими бы изящными ни были решения, а некоторые из них действительно
очень изящны, постановка задачи и ее контекста служит основанием для про
ектного шаблона. Поставить задачу намного труднее, чем выбрать какое-нибудь
4 Мартин Фаулер. Шаблоны корпоративных приложений (пер. с англ., ИД “Вильямс”,
2009 г.).

228

ЧАСТЬ III

ШАБЛОНЫ

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

Решение
Решение сначала кратко описывается вместе с задачей. Оно также описыва
ется подробно, как правило, с помощью диаграмм классов и взаимодействия на
языке UML. В шаблон обычно включается пример кода.
И хотя код может быть предоставлен, в качестве решения никогда нельзя
использовать способ вырезания и вставки. Напомним, что шаблон описывает
только подход к решению задачи, поскольку в его реализации могут проявиться
сотни нюансов. Рассмотрим в качестве примера инструкции, как сеять хлеб.
Если вы слепо выполните все эти инструкции, то, скорее всего, будете голодать
после сбора урожая. Намного более полезным оказывается основанный на ша
блоне подход, где описываются различные условия применения этого шаблона.
Основное решение задачи (вырастить хлеб) всегда будет одним и тем же (посе
ять семена, поливать, собрать урожай), но реальные шаги, которые нужно будет
предпринять, зависят от самых разных факторов, включая тип почвы, местность,
наличие вредных насекомых и т.д. Мартин Фаулер называет решения, описан
ные в шаблонах, “полуфабрикатами”, т.е. программист должен взять основной
замысел решения и самостоятельно довести его логического завершения.

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

Формат “Банды четырех”
Теперь, когда я пишу эти строки, передо мной на рабочем столе лежат пять
каталогов проектных шаблонов. Даже поверхностный взгляд на шаблоны в ка
ждом каталоге говорит о том, что ни в одном из них не используется такая же
структура, как и в других. Одни из них более формализованы, другие сильно
детализированы (содержат немало подразделов), а третьи менее упорядочены.
Существует ряд ясно определенных структур шаблонов, включая первона
чальную форму, разработанную Кристофером Александером (александрийская
форма), а также описательный подход, применяемый в Портлендском хранилище

ГЛАВА 7

НАЗНАЧЕНИЕ И ПРИМЕНЕНИЕ ПРОЕКТНЫХ ШАБЛОНОВ

229

шаблонов (Portland Pattern Repository). А поскольку “Банда четырех” имеет
большое влияние, и мы будем рассматривать многие из описанных ими ша
блонов, исследуем несколько разделов, которые они включили в свои шаблоны.
Ниже приведено краткое описание этих разделов.
$ Предназначение. Краткая формулировка цели шаблона. Необходимо уметь
с первого взгляда понять суть шаблона.

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

Применимость. Исследование различных ситуаций, в которых можно при
менить шаблон. В то время как в разделе мотивации описывается типич
ная задача, в данном разделе определяются конкретные ситуации и оцени
ваются преимущества решения в контексте каждой из них.
Структура/взаимодействие. Эти разделы могут содержать диаграммы
классов и взаимодействия, описывающие на языке UML отношения меж
ду классами и объекты в конкретном решении.

ш Реализация. В данном разделе рассматриваются подробности решения.
В нем исследуются любые вопросы, которые могут возникнуть при приме
нении предлагаемое методики, а также даются советы по ее применению.
» Пример кода. Я всегда перехожу сразу же к этому разделу, поскольку счи
таю, что простой пример кода помогает лучше разобраться в шаблоне.
Этот пример часто сведен к минимуму с целью продемонстрировать саму
суть решения. Пример может быть написан на любом объектно-ориенти
рованном языке. Разумеется, в последующих далее примерах кода всегда
будет употребляться язык РНР.

Примеры применения. Реальные системы, в которых встречается данный
шаблон (задача, контекст и решение). Существует мнение, что шаблон дол
жен присутствовать, по крайней мере, в трех широко известных контек
стах, чтобы считаться настоящим. Это называется иначе “правилом трех”.
m Связанные шаблоны. Одни шаблоны порождают другие. Применяя одно
решение, можно создать контекст, в котором станет полезным другое ре
шение. Именно такие связи исследуются в этом разделе, где могут также
обсуждаться шаблоны, некоторые сходства в задаче и решении, а также
любые предшествующие шаблоны, определенные где-нибудь еще и слу
жащие основанием для построения текущего шаблона.

Причины для применения проектных шаблонов
Так в чем же преимущества шаблонов? Учитывая, что шаблон — это постав
ленная задача и описанное решение, ответ, казалось бы, очевиден. Шаблоны
помогают решать распространенные задачи. Но шаблон — это, без сомнения,
нечто большее.

230

ЧАСТЬ III

ШАБЛОНЫ

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

Шаблоны определяют решения
Определив и осознав возникшее затруднение (и убедившись, что оно дей
ствительно составляет проблему), вы получаете с помощью проектного шабло
на доступ к решению, а также к анализу последствий его применения. И хотя
шаблон совсем не избавляет вас от необходимости рассмотреть последствия
выбранного решения, вы, по крайней мере, будете уверены, что пользуетесь
проверенной методикой.

Шаблоны не зависят от языка программирования
Проектные шаблоны определяют объекты и решения в терминах ООП. Это
означает, что многие шаблоны одинаково применимы во многих языках про
граммирования. Начав пользоваться проектными шаблонами, я изучал приме
ры кода на C++ и Smalltalk и реализовывал свои решения на Java. На другие
языки шаблоны переносятся с некоторыми изменениями в их реализации или
в получаемых результатах, но они всегда остаются правомерными. В любом
случае проектные шаблоны помогают при переходе от одного языка к другому.
Аналогично приложение, написанное на четких принципах объектно-ориенти
рованного проектирования, легко перенести с одного языка на другой (хотя при
этом всегда остаются трудности, которые приходится разрешать).

Шаблоны определяют словарь
Предоставляя разработчикам названия методик, шаблоны обогащают процесс
общения и передачи информации. Представим совещание, посвященное вопро
сам проектирования. Я уже описал мое решение с помощью шаблона Abstract
Factory и теперь должен изложить стратегию обработки данных, которые со
бирает система. Я рассказываю о своих планах Бобу в следующем диалоге.
Я: Я собираюсь применить шаблон Composite.

Боб: Мне кажется, ты не продумал это как следует.

Что ж, Боб не согласен со мной. Он никогда со мной не согласен. Но он
знает, о чем я говорю и почему моя идея плоха. А теперь проиграем эту сцену
еще раз без применения словаря.
Я: Я собираюсь использовать три объекта с одним и тем же общим типом
данных. В интерфейсе этого типа данных будут определены методы для до
бавления дочерних объектов собственного типа. Таким образом, мы можем

ГЛАВА 7 ® НАЗНАЧЕНИЕ И ПРИМЕНЕНИЕ ПРОЕКТНЫХ ШАБЛОНОВ

231

построить сложную комбинацию реализованных объектов во время выполнения
программы.
Боб: Да?

Шаблоны или методики, которые в них описаны, имеют тенденцию к вза
имодействию. Так, шаблон Composite взаимодействует с шаблоном Visitor.
Я: А затем можно воспользоваться шаблоном Visitor для получения ито
говых данных.
Боб: Ты упустил суть.
Не будем обращать внимание на Боба, долго и мучительно описывая версию
этого разговора без употребления терминологии проектных шаблонов. Подроб
нее о шаблоне Composite речь пойдет в главе 10„ “Шаблоны для программи
рования гибких объектов”, а о шаблоне Visitor — в главе И, “Выполнение
задач и представление результатов”.
Дело в том, что эти методики можно применять и без терминологии проект
ных шаблонов. Сами методики всегда появляются до того, как им будет присво
ено название, и они будут организованы в виде шаблона. Если же такой шаблон
отсутствует, его можно создать. А любое инструментальное средство, которое
применяется достаточно часто, в конце концов получит свое название.

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

Шаблоны предназначены для совместной работы
По своему характеру проектные шаблоны должны быть порождающими и со
ставляемыми. Это означает возможность применить один шаблон и тем самым
создать условия, подходящие для применения другого шаблона. Иначе говоря,
используя шаблон, можно обнаружить открывающиеся новые перспективы.

232

ЧАСТЬ III Й ШАБЛОНЫ

Каталоги шаблонов обычно разрабатываются с расчетом на такого рода совмест
ную работу, а возможность составления шаблонов всегда документируется в са
мом шаблоне.

Шаблоны способствуют удачным проектам
В проектных шаблонах демонстрируются и применяются принципы объек
тно-ориентированного проектирования. Поэтому изучение проектных шаблонов
может дать больше, чем конкретное решение в определенном контексте. Это
может привести к новому представлению, как объединить объекты и классы для
достижения поставленной цели.

Шаблоны применяются в распространенных каркасах
В данной книге процесс проектирования описан практически с самого нача
ла. Принципы и проектные шаблоны, рассмотренные в ней, должны побудить
вас к созданию ряда собственных базовых каркасов, которые лягут в основу
всех ваших проектов. Ведь лень иногда оказывается во благо, и поэтому вы мо
жете вполне воспользоваться такими стандартными каркасами, как Zend, Code
Igniter или Symfony, или же скопировать код из готовых проектов. Ясное пони
мание основ проектных шаблонов поможет вам быстро освоить программный
интерфейс API этих каркасов.

РНР и проектные шаблоны
В этой главе мало что относится непосредственно к РНР, что в некоторой
степени характерно для рассматриваемой в ней темы. Большинство проектных
шаблонов применимо во многих языках программирования, где имеются воз
можности манипулирования объектами и достаточно решить лишь некоторые
вопросы реализации, если они вообще возникают.
Но это, конечно, не всегда именно так. Некоторые шаблоны корпоративных
приложений отлично подходят для тех языков, где прикладной процесс не оста
навливает свою работу в перерывах между запросами к серверу. Но сценарии
на РНР действуют иначе, поскольку для обработки каждого поступившего за
проса сценарий запускается заново. Это означает, что некоторые шаблоны тре
буют более аккуратного обращения. Например, для реализации шаблона Front
Controller часто требуется довольно много времени. Хорошо, если инициа
лизация имеет место один раз при запуске приложения, но гораздо хуже, если
она происходит при каждом запросе. Но это совсем не означает, что применять
данный шаблон нельзя. В своей практике я применял его с очень хорошими
результатами. При обсуждении шаблона мы просто должны принять во внима
ние вопросы, связанные с РНР. Именно язык РНР формирует контекст для всех
шаблонов, которые исследуются в данной книге.

ГЛАВА 7 е НАЗНАЧЕНИЕ И ПРИМЕНЕНИЕ ПРОЕКТНЫХ ШАБЛОНОВ

233

Ранее в этом разделе уже упоминались языки программирования, в которых
имеется возможность манипулировать объектами. А в РНР можно программи
ровать, вообще не определяя никаких классов. Но объекты и принципы ООП
положены, за некоторыми исключениями, в основу большинства проектов и би
блиотек на РНР.

Резюме
В этой главе были представлены проектные шаблоны, рассмотрена их струк
тура (с помощью формата “Банды четырех”) и проанализирован ряд причин,
по которым у вас может возникнуть необходимость пользоваться проектными
шаблонами в своих сценариях.
Не следует, однако, забывать, что проектные шаблоны — это не готовые
решения, которые можно объединять, как компоненты, при создании проекта.
Шаблоны — это предлагаемые подходы к решению распространенных задач.
В этих решениях воплощены некоторые основные принципы проектирования.
Именно их мы и будем исследовать в следующей главе.

ГЛАВА 8

Яши

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

в Композиция. Использование агрегирования объектов для достижения боль
шей гибкости, чем с помощью одного только наследования.
» Развязка. Сокращение взаимной зависимости элементов в системе.
» Потенциальные возможности интерфейса. Шаблоны и полиморфизм.
» Категории шаблонов. Типы шаблонов, описываемых в данной книге.

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

236

ЧАСТЬ III w ШАБЛОНЫ

В то время все книги на моем рабочем столе были посвящены возможностям
языков программирования и многочисленным интерфейсам API, доступным про
граммирующему на Java. Если не считать краткого определения полиморфизма,
в этих книгах почти не было попыток исследовать стратегии проектирования.
Одни только возможности языка не порождают объектно-ориентированные
проекты. Хотя мои проекты удовлетворяли их функциональным требованиям,
тип проекта, который можно было создать с помощью наследования, инкапсу
ляции и полиморфизма, по-прежнему ускользал от меня.
Мои иерархии наследования становились все более обширными и глубокими,
поскольку я пытался создавать новые классы по каждому поводу. Структура
моих систем затрудняла передачу сообщений от одного уровня к другому таким
образом, чтобы не давать промежуточным классам слишком много сведений об
их окружении, не привязывать их к приложению и не делать их непригодными
в новом контексте.
И только открыв для себя упоминавшуюся ранее книгу Design Patterns, ко
торая иначе называется книгой “Банды четырех”, я понял, что упустил целый
аспект проектирования. К тому времени я уже самостоятельно открыл несколь
ко основных шаблонов, но знакомство с другими шаблонами изменило мой об
раз мышления.
Я выяснил, что в своих проектах дал наследованию слишком много привиле
гий, пытаясь придать классам слишком много функций. Но где еще требуются
функциональные возможности в объектно-ориентированной системе?
Ответ я нашел в композиции. Программные компоненты можно определять
во время выполнения путем комбинирования объектов, находящихся в гибких
отношениях. “Банда четырех” сформулировала это в следующем принципе:
“Предпочитайте композицию наследованию”. Шаблоны описывали способы
объединения объектов во время выполнения программы с целью достичь уровня
гибкости, который невозможен при применении только одного дерева наследо
вания.

Композиция и наследование
Наследование — это эффективный способ описания меняющихся обстоя
тельств или контекста. Но за счет этого можно потерять в гибкости, особенно
если на классы возложено несколько функциональных обязанностей.

Проблема
Как вам, должно быть, известно, дочерние классы наследуют методы и свой
ства родительских классов, при условии, что они относятся к открытым или
защищенным элементам. Этим фактом можно воспользоваться для создания до
черних классов, обладающих особыми функциональными возможностями.
На рис. 8.1 приведен простой пример наследования, демонстрируемого с по
мощью диаграммы UML.

ГЛАВА 8 в НЕКОТОРЫЕ ПРИНЦИПЫ ДЕЙСТВИЯ ШАБЛОНОВ

237

Рис. 8.1. Родительский класс и два дочерних класса

Абстрактный класс Lesson на рис. 8.1 моделирует занятие в колледже и опре
деляет абстрактные методы cost() и chargeType (). На диаграмме показаны
два реализующих их класса, FixedPriceLesson и TimedPriceLesson, которые
обеспечивают разные механизмы оплаты занятий.
С помощью этой схемы наследования можно без особого труда изменить реали
зацию занятия. А в клиентском коде будет лишь известно, что он имеет дело с объ
ектом типа Lesson, поэтому подробности механизма оплаты будут прозрачными.
Но что произойдет, если потребуется внедрить новый ряд специализаций?
Допустим, потребуется работать с такими элементами, как лекции и семинары.
Они подразумевают разные способы регистрации учащихся и создания рабочих
материалов к занятиям, для них нужны отдельные классы. Поэтому у нас теперь
имеются две движущие силы проекта. В частности, нам потребуется обращаться
со стратегиями оплаты и разделить лекции и семинары.
На рис. 8.2 показано решение задачи “в лоб”.

Рис. 8.2. Неудачная структура наследования

238

ЧАСТЬ III

ШАБЛОНЫ

На рис. 8.2 приведена явно неудачная иерархия. Такое дерево наследования
нельзя в дальнейшем использовать для того, чтобы управлять механизмами
оплаты, не дублируя большие блоки функциональных средств. Эти механизмы
оплаты повторяются в семействах классов Lecture и Seminar.
На данном этапе необходимо рассмотреть применение условных операторов
в суперклассе Lesson, чтобы избавиться от дублирования. В сущности, мы пол
ностью удаляем логику оплаты из дерева наследования, перемещая ее вверх по
иерархии в суперкласс. Это полная противоположность традиционному рефак
торингу, когда условные операторы заменяются полиморфизмом. Ниже показа
но, как выглядит исправленный в итоге класс Lesson.
// Листинг 08.01

abstract class Lesson
{

protected $duration;
const
FIXED = 1;
const
TIMED = 2;
private
$costtype;

public function __ construct(int $duration,
int $costtype = 1)
{

$this->duration = $duration;
$this->costtype = $costtype;
}

public function cost(): int
{

switch ($this->costtype) {
case self::TIMED:
return (5 ★ $this->duration);
break;
case self::FIXED:
return 30;
break;
default:
$this->costtype = self::FIXED;
return 30;
}
}

public function chargeType(): string
{
switch ($this->costtype) {
case self::TIMED:
return ’’Почасовая оплата";
break;
case self::FIXED:
return "Фиксированная ставка";
break;
default:
$this->costtype = self: .’FIXED;

ГЛАВА 8 * НЕКОТОРЫЕ ПРИНЦИПЫ ДЕЙСТВИЯ ШАБЛОНОВ
return ’’Фиксированная ставка”;

}
}

// Другие методы из класса Lesson. . .
}
// Листинг 08.02
class Lecture extends Lesson

{

// Реализации, характерные для класса Lecture...
}
// Листинг 08.03

class Seminar extends Lesson

{
// Реализации, характерные для класса Seminar...

}

А вот как следует обращаться с этими классами.
// Листинг 08.04

$lecture = new Lecture(5, Lesson::FIXED);
print ”{$lecture->cost()} ({ $lecture->chargeType()})\n”;

$seminar = new Seminar(3, Lesson::TIMED);
print ”{$seminar->cost()} ({ $seminar->chargeType ()})\n”;

В итоге мы получим следующий результат:

30 (Фиксированная ставка)
15 (Почасовая оплата)
Диаграмма нового класса показана на рис. 8.3.

Рис. 8.3. Иерархия наследования улучшена в результате
удаления расчетов стоимости занятий из подклассов

239

240

ЧАСТЬ III

ШАБЛОНЫ

Мы сделали структуру класса намного более управляемой, хотя и дорогой
ценой. Употребление условных операторов в рассматриваемом здесь коде — это
шаг назад. Как правило, условный оператор лучше заменить полиморфизмом,
а здесь мы поступили наоборот. Как видите, это вынудило нас продублировать
условный оператор в методах chargeType () и cost (). Похоже, что мы обре
чены на дублирование кода.

Применение композиции
Для решения данной задачи можно воспользоваться шаблоном Strategy,
который служит для перемещения ряда алгоритмов в отдельный тип данных.
Перемещая код для расчета стоимости занятия в другой класс, можно упростить
тип Lesson (рис. 8.4).

Рис. 8.4. Перемещение алгоритмов в отдельный тип данных

Мы создали еще один абстрактный класс Coststrategy, в котором опреде
лены абстрактные методы cost () и chargeType (). Методу cost () необходимо
передать экземпляр класса Lesson, который он будет использовать для расчета
стоимости занятия. Мы предоставляем две реализации класса Coststrategy.
Объекты типа Lesson оперируют только типом Coststrategy, а не конкретной
реализацией, поэтому можно в любое время добавить новые алгоритмы расчета
стоимости, создавая подклассы на основе класса Coststrategy. И для этого не
придется вносить вообще никаких изменений в классы Lesson.
Приведем упрощенную версию нового класса Lesson, показанного на рис. 8.4.
// Листинг 08.05
abstract class Lesson
{

private $duration;
private $costStrategy;

ГЛАВА 8 ® НЕКОТОРЫЕ ПРИНЦИПЫ ДЕЙСТВИЯ ШАБЛОНОВ

241

public function __ construct(int $duration,
Coststrategy $strategy)
{

$this->duration = $duration;
$this->costStrategy = $strategy;
}

public function cost(): int
{

return $this->costStrategy->cost($this);

}
public function chargeType () : string
{

return $this->costStrategy->chargeType ();
}

public function getDuration(): int

return $this->duration;

}
// Другие методы класса из Lesson...

// Листинг 08.06
class Lecture extends Lesson
{

// Реализации, характерные для класса Lecture...

// Листинг 08.07

class Seminar extends Lesson
{

// Реализации, характерные для класса Seminar...
}

Конструктору класса Lesson передается объект типа Coststrategy, кото
рый он сохраняет в виде свойства. В методе Lesson: :cost () просто делается
вызов Coststrategy: :cost (). Аналогично в методе Lesson: :chargeType ()
делается вызов Cost Strategy: : chargeType (). Такой явный вызов метода из
другого объекта для выполнения запроса называется делегированием. В рассма
триваемом здесь примере объект типа Coststrategy является делегатом клас
са Lesson. А класс Lesson снимает с себя ответственность за расчет стоимо
сти занятия и возлагает эту обязанность на реализацию класса Coststrategy.
Ниже показано, каким образом осуществляется делегирование.
public function cost () : int
{

return $this->costStrategy->cost($this);

242

ЧАСТЬ III ® ШАБЛОНЫ

Ниже приведено определение класса Coststrategy вместе с реализующими
его дочерними классами.
// Листинг 08.08

abstract class Coststrategy

{

abstract public function cost(Lesson $lesson): int;
abstract public function chargeType(): string;
}
// Листинг 08.09

class TimedCostStrategy extends Coststrategy
{

public function cost(Lesson $lesson): int
{

return ($lesson->getDuration()

* 5);

}

public function chargeType(): string

{
return "Почасовая оплата";
}

}
// Листинг 08.10

class FixedCostStrategy extends Coststrategy

{
public function cost(Lesson $lesson): int
{

return 30;
}

public function chargeType () : string
{

return "Фиксированная ставка";

}
}

Теперь во время выполнения программы можно легко изменить способ рас
чета стоимости занятий, выполняемый любым объектом типа Lesson, передав
ему другой объект типа Coststrategy. Такой подход способствует созданию
довольно гибкого кода. Вместо того чтобы статично встраивать функциональ
ность в структуры кода, можно комбинировать объекты и менять их сочетания
динамически.
// Листинг 08.11

$lessons[] = new Seminar(4, new TimedCostStrategy());
$lessons[] = new Lecture(4, new FixedCostStrategy());
foreach ($lessons as $lesson)

{

ГЛАВА 8 » НЕКОТОРЫЕ ПРИНЦИПЫ ДЕЙСТВИЯ ШАБЛОНОВ

243

print ’’Оплата за занятие {$lesson->cost()}. ’’;
print ” Тип оплаты: {$lesson->chargeType()}\п";
}

Выполнение данного фрагмента кода приведет к следующему результату:
Оплата за занятие 20. Тип оплаты: Почасовая оплата
Оплата за занятие 30. Тип оплаты: Фиксированная ставка

Как видите, одно из следствий принятия такой структуры состоит в том, что
мы распределили обязанности классов. Объекты типа Coststrategy ответ
ственны только за расчет стоимости занятия, а объекты типа Lesson управляют
данными занятия.
Итак, композиция позволяет сделать код намного более гибким, поскольку
можно комбинировать объекты и решать задачи динамически намного большим
количеством способов, чем при использовании одной лишь иерархии наследо
вания. Но при этом исходный код может стать не удобочитаемым. В результате
композиции, как правило, создается больше типов данных с отношениями, кото
рые не настолько предсказуемы, как отношения наследования. Поэтому понять
отношения в такой системе немного труднее.

Развязка
Как пояснялось в главе 6, “Объекты и проектирование”, имеет смысл соз
давать независимые компоненты, поскольку систему, состоящую из зависимых
классов, намного труднее сопровождать. Дело в том, что внесение изменений в
одном месте программы может повлечь за собой ряд соответствующих измене
ний в других частях кода программы.

Проблема
Повторное использование — одна из основных целей объектно-ориентиро
ванного проектирования, а тесная связь вредит этой цели. Тесная связь воз
никает, когда изменение в одном компоненте системы ведет к необходимости
вносить множество изменений повсюду. Необходимо стремиться создавать не
зависимые компоненты, чтобы можно было вносить изменения, не опасаясь эф
фекта цепной реакции непредвиденных последствий. Когда изменяется компо
нент, степень его независимости влияет на вероятность того, что эти изменения
вызовут ошибки в других частях системы.
На рис. 8.2 был наглядно показан пример тесной связи. В частности, логи
ка схем оплаты занятий повторяется в типах Lecture и Seminar, и поэтому
изменения в компоненте типа TimedPriceLecture приведут к необходимости
внесения параллельных изменений в ту же самую логику в компоненте типа
TimedPriceSeminar. Обновляя один класс и не обновляя другой, мы нарушаем
нормальную работу системы. При этом интерпретатор РНР не выдает никакого

244

ЧАСТЬ III « ШАБЛОНЫ

предупреждения. Поэтому наше первое решение употребить условный оператор
породило аналогичную зависимость между методами cost () и chargeType ().
Применяя шаблон Strategy, мы преобразовали алгоритмы оплаты занятий в
тип Coststrategy, разместили их за общим интерфейсом и реализовали каж
дый из них только один раз. Тесная связь другого рода может возникнуть в
том случае, если в системе многие классы внедрены явным образом в платфор
му или в среду. Допустим, требуется создать систему, которая работает с ба
зой данных MySQL. Для запросов к серверу базы данных можно вызвать метод
mysqli::query().
Но если же понадобится развернуть систему на сервере, который не под
держивает базу данных MySQL, для этого придется внести изменения в весь
проект, чтобы использовать базу данных, например, SQLite. При этом изменения
придется вносить по всему коду, а это сулит неприятную перспективу поддер
живать две параллельные версии приложения.
И дело здесь не в зависимости системы от внешней платформы. Такая зави
симость неизбежна, поскольку приходится работать с кодом, который связывает
ся с базой данных. Проблема возникает в том случае, когда такой код разбросан
по всему проекту. Взаимодействие с базами данных — это не главная обязан
ность большинства классов в системе, поэтому наилучшая стратегия состоит
в том, чтобы выделить такой код и сгруппировать его за общим интерфейсом.
И это будет способствовать независимости классов. В то же время собирание
кода шлюза в одном месте создает условия для более легкого перехода на но
вую платформу, где не придется вносить изменения в остальную часть системы.
Такой процесс сокрытия реализации за ясным интерфейсом называется инкапсу
ляцией, Данную проблему позволяет разрешить библиотека баз данных Doctrine
из проекта DBAL (Database Abstraction Layer, или абстрактный уровень базы дан
ных), где предоставляется единственная точка доступа ко многим базам данных.
В частности, в классе DriverManager определен статический метод
getConnection (), которому в качестве аргумента передается аргумента мас
сив параметров. В соответствии со структурой этого массива данный метод воз
вращает конкретную реализацию интерфейса в классе Doctrine\DBAL\Driver.
Структура этого класса приведена на рис. 8.5.

I

PDOSqliteXDriver

PDOMySqIXDriver

Рис. 8.5. Пакет DBAL развязывает клиентский код от объектов базы данных

ГЛАВА 8 я НЕКОТОРЫЕ ПРИНЦИПЫ ДЕЙСТВИЯ ШАБЛОНОВ

245

Пакет DBAL позволяет развязать прикладной код от конкретных особенно
стей платформы базы данных. Это дает возможность организовать взаимодей
ствие одной системы с MySQL, SQLite, MSSQL и прочими базами данных, не
изменяя ни одной строки кода, разумеется, кроме параметров конфигурации.

Ослабление связанности
Чтобы сделать код взаимодействия с базой данных гибким и управляемым,
необходимо развязать логику приложения от конкретных особенностей платфор
мы базы данных. Такая развязка компонентов позволит извлечь немало выгод в
разрабатываемых проектах.
Допустим, что в рассматриваемую здесь систему автоматизации учебного
процесса требуется включить регистрационный компонент, в обязанности ко
торого входит ввод в систему новых занятий. Процедура регистрации должна
предусматривать рассылку уведомлений администратору после ввода нового за
нятия. Но пользователи данной системы никак не могут решить, в каком виде
эти уведомления должны рассылаться: по электронной почте или в виде корот
ких текстовых сообщений (SMS). На самом деле они так любят спорить, что от
них можно вполне ожидать изменения формы общения в ближайшем будущем.
Более того, они могут потребовать, чтобы уведомления рассылались всеми воз
можными видами связи. Поэтому изменение режима уведомления в одном месте
кода может повлечь за собой аналогичные изменения во многих других местах
системы.
Если использовать в коде явные ссылки на классы Mailer или Texter, то
система станет жестко привязанной к конкретному типу рассылки уведомлений.
Это примерно то же самое, что и привязаться к конкретному типу платформы
базы данных, используя в коде вызовы ее специализированных функций из ин
терфейса API.
Ниже приведен фрагмент кода, где подробности реализации конкретной си
стемы уведомления скрыты от кода, в котором она используется.
// Листинг 08.12
class RegistrationMgr
{

public function register(Lesson $lesson)
{

// Сделать что-нибудь с классом Lesson...
//а теперь отправить кому-нибудь сообщение
$notifier = Notifier::getNotifier ();
$notifier->inform (’’Новое занятие: стоимость -

}
}

// листинг 08.13

({ $lesson->cost ()})”) ;

246

ЧАСТЬ III » ШАБЛОНЫ

abstract class Notifier
{
public static function getNotifier (): Notifier
{
// получить конкретный класс в соответствии с
// конфигурацией или другой логикой
if (rand(l, 2) === 1) {
return new MailNotifier();
} else {
return new TextNotifier ();
}
}
abstract public function inform($message);
}
// Листинг 08.14

class MailNotifier extends Notifier
{
public function inform($message)
{
print "Уведомление по электронной почте:
}
}

{$message}\n";

// Листинг 08.15
class TextNotifier extends Notifier
{
public function inform($message)
{
print "Текстовое уведомление: {$message}\n";
}
}

В данном примере мы создали класс RegistrationMgr, который является
простым клиентским классом для классов типа Notifier. Несмотря на то что
класс Notifier объявлен как абстрактный, в нем реализован статический ме
тод getNotif ier (), который создает и возвращает конкретный объект типа
Notifier (TextNotifier или MailNotifier) в зависимости от сложившейся
ситуации. В реальном проекте выбор конкретного типа объекта должен опре
деляться каким-нибудь гибким способом, например, параметром в файле кон
фигурации. Здесь же мы немного слукавили, выбрав тип объекта случайным
образом. Классы MailNotifier и TextNotifier практически ничего не дела
ют. Они просто выводят с помощью метода inform () сведения, полученные в
качестве параметра, дополняя их идентификатором, чтобы было видно, из како
го класса делается вызов.
Обратите внимание на то, что только в методе Notifier: :getNotifier ()
известно, какой именно объект типа Notifier должен быть создан. В итоге
уведомления можно посылать из самых разных мест системы, а при изменении
типа уведомлений соответствующие коррективы потребуется внести только в
один метод из класса Notifier.

ГЛАВА 8 W НЕКОТОРЫЕ ПРИНЦИПЫ ДЕЙСТВИЯ ШАБЛОНОВ

247

Ниже приведен фрагмент кода, где вызывается метод register() из класса
RegistrationMgr.
// Листинг 08.16
$lessonsl = new Seminar(4, new TimedCostStrategy());
$lessons2 = new Lecture(4, new FixedCostStrategy());
$mgr = new RegistrationMgr();
$mgr->register($lessonsl);
$mgr->register($lessons2) ;

Выполнение данного фрагмента кода приведет к следующему результату:
Текстовое уведомление: Новое занятие: стоимость - (20)
Уведомление по электронной почте: Новое занятие: стоимость - (30)

На рис. 8.6 показана диаграмма классов в проектируемой системе. Обратите
внимание на то, что структура, приведенная на рис. 8.6, очень сильно напоми
нает структуру компонентов Doctrine,представленную на рис. 8.5.

Рис. 8.6. Класс Notifier развязывает клиентский код
от различных реализаций уведомителей

Программируйте на основе
интерфейса, а не его реализации
Этот принцип служит одним из главных лейтмотивов данной книги, прони
зывая весь ее материал. Как было показано в главе 6, “Объекты и проектиро
вание”, и в предыдущем разделе, разные реализации можно скрыть за общим
интерфейсом, определенным в суперклассе. В итоге появляется возможность
оперировать в клиентском коде объектом, относящимся к суперклассу, а не к
реализующему его классу, не особенно заботясь о его конкретной реализации.
Параллельно употребляемые условные операторы, подобные введенным в
методы Lesson:: cost () и Lesson: : chargeType (), служат явным признаком,
что необходимо прибегнуть к полиморфизму. Условные операторы усложняют
сопровождение кода, потому что изменение в одном условном выражении ведет
к необходимости изменений во всех родственных ему выражениях. Об условных
операторах иногда говорят, что они реализуют “сымитированное наследование”.

248

ЧАСТЬ III Ж ШАБЛОНЫ

Размещая алгоритмы оплаты в отдельных классах, реализующих интерфейс
Coststrategy, мы избавляемся от дублирования. Мы также намного упрощаем
процесс внедрения новых стратегий оплаты, если возникнет такая потребность.
С точки зрения клиентского кода иногда полезно потребовать, чтобы в параме
трах метода задавались абстрактные или общие типы данных. А требуя более
конкретные типы, можно ограничить гибкость кода во время выполнения про
граммы.
Но, конечно, степень обобщенности, выбираемая при объявлении типов ар
гументов, требует рассудительности. Если выбрать слишком обобщенный вари
ант, то метод может стать менее безопасным. А если потребовать конкретные
функциональные возможности от подтипа, то передача методу совершенно ина
че оснащенного родственного элемента может оказаться рискованной. Но если
выбрать слишком ограниченные объявления типов аргументов, то потеряются
все преимущества полиморфизма. Рассмотрим следующий видоизмененный
фрагмент кода из класса Lesson:
// Листинг 08.17
public function __ construct(
int $duration, FixedCostStrategy $strategy)
{

$this->duration = $duration;
$this->costStrategy = $strategy;
}

Проектное решение, демонстрируемое в данном примере, вызывает два во
проса. Во-первых, объект типа Lesson теперь привязан к определенной стра
тегии стоимости, и поэтому мы больше не можем формировать динамические
компоненты. И во-вторых, явная ссылка на класс FixedPriceStrategy вы
нуждает нас поддерживать эту конкретную реализацию.
Требуя общий интерфейс, можно сочетать объект типа Lesson с любой реа
лизацией интерфейса Coststrategy.
// Листинг 08.18

public function __ construct (
int $duration, Coststrategy $strategy)

{
$this->duration = $duration;
$this->costStrategy = $strategy;
}

Иными словами, мы развязали класс Lesson от особенностей расчетов сто
имости занятия. Здесь самое главное — это интерфейс и гарантия, что предо
ставленный объект будет соответствовать ему.
Безусловно, программирование на основе интерфейса зачастую позволяет
лишь отложить на время вопрос, как создавать экземпляры объектов. Когда мы

ГЛАВА 8 « НЕКОТОРЫЕ ПРИНЦИПЫ ДЕЙСТВИЯ ШАБЛОНОВ

249

говорим, что во время выполнения программы объекту типа Lesson можно пе
редать любой объект, поддерживающий интерфейс Coststrategy, то уклоня
емся от вопроса: откуда возьмется объект типа Coststrategy?
При создании абстрактного суперкласса всегда возникают следующие вопро
сы: как создавать экземпляры его дочерних объектов и какой дочерний объект
выбрать и в соответствии с какими условиями? Эти вопросы образуют отдель
ную категорию в каталоге шаблонов “Банды четырех”, и мы подробнее иссле
дуем ее в следующей главе.

Меняющаяся концепция
После того как проектное решение осуществлено, его легко объяснить. Но
как знать, с чего начинать?
“Банда четырех” рекомендует “инкапсулировать меняющуюся концепцию”.
В рассматриваемом здесь примере организации занятий меняющаяся концеп
ция — это алгоритм оплаты. Но это может быть не только расчет стоимости для
одной из двух возможных стратегий оплаты, как в данном примере. Очевидно,
что эту стратегию можно расширить, введя специальные предложения, тарифы
для иностранных учащихся, вступительные скидки и другие возможности.
Мы быстро установили, что создание подклассов в условиях постоянно ме
няющейся ситуации неприемлемо, и поэтому прибегли к условным операторам.
Разместив в одном классе все варианты оплаты, мы тем самым подчеркнули его
пригодность для инкапсуляции.
“Банда четырех” рекомендует активно искать меняющиеся элементы в клас
сах и оценивать их пригодность для инкапсуляции в новом типе. Каждый аль
тернативный вариант в анализируемом условном операторе можно извлечь и
сформировать отдельный класс, расширяющий общий абстрактный родитель
ский класс. Затем этот новый тип можно использовать в тех классах, из которых
он был извлечен. В результате будет достигнуто следующее.
Сосредоточение обязанностей.

w Поддержка гибкости благодаря композиции.
ш Большая компактность и сосредоточенность иерархий наследования.
ж Сокращение дублирования.

Но как выявить изменение концепции? Одним из его признаков служит зло
употребление наследованием и, в частности, применение наследования под
одновременным воздействием разных обстоятельств (лекция/семинар и фиксированная/повременная оплата) или создание подклассов на основе алгоритма,
который является второстепенным по отношению к основной обязанности типа.
Другим признаком изменения концепции, пригодной для инкапсуляции, служит
условное выражение, как было показано выше.

250

ЧАСТЬ III S ШАБЛОНЫ

Проблемы применения шаблонов
Одна из задач, для которых не существует шаблонов, состоит в необязатель
ном или неподходящем использовании шаблонов. Такое положение вещей созда
ло проектным шаблонам плохую репутацию в некоторых кругах. Решения на
основе шаблонов изящны и ясны, и поэтому возникает искушение применять
их везде, где только можно, независимо от того, есть ли в этом реальная необ
ходимость.
Методика экстремального программирования (extreme Programming — ХР)
предлагает ряд принципов, применимых в данной ситуации. Первый принцип
гласит: “Вам это не понадобится” (обычно для его обозначения употребляется
сокращение YAGNI от You агеп У going to need it). Как правило, данный принцип
применяется к функциональным средствам приложения, но он имеет смысл и
в шаблонах.
Когда я работаю над крупными проектами на РНР, то обычно разбиваю при
ложение на уровни, отделяя логику приложения от представления данных и
уровня сохранения данных. И в этом случае пользуюсь всевозможными видами
основных и промышленных шаблонов, а также их комбинациями.
Но если меня попросят создать простую форму для обратной связи неболь
шого веб-сайта, я могу запросто воспользоваться процедурным кодом, разме
стив его на одной странице с кодом HTML. В этом случае мне не требуется
гибкость в крупных масштабах, потому что я не буду что-либо строить на этой
первоначальной основе. Мне не потребуются и шаблоны, позволяющие решать
соответствующие задачи в более крупных системах. Поэтому я применяю вто
рой принцип экстремального программирования: “Делайте самое простое, что
только может работать”.
Работая с каталогом шаблонов, думайте о структуре и процессе решения, об
ращая внимание на пример кода. Но прежде чем применить шаблон, подумайте
о том, когда его использовать, найдите соответствующий раздел и прочитайте о
результатах применения шаблона. В некоторых контекстах лечение может ока
заться хуже болезни.

Шаблоны
Эта книга — не каталог шаблонов. Тем не менее в последующих главах мы
рассмотрим несколько основных проектных шаблонов, которые применяются в
настоящее время, предоставив примеры их реализации на РНР и обсудив их в
широком контексте программирования на РНР.
Описываемые здесь шаблоны взяты из основных каталогов, включая упо
минавшиеся ранее книги Design Patterns и Patterns of Enterprise Application
Architecture Мартина Фаулера и Core J2EE Patterns Дипака Алура. В качестве
отправной точки далее используется разделение шаблонов на категории, приня
тое “Бандой четырех”.

ГЛАВА 8 ж НЕКОТОРЫЕ ПРИНЦИПЫ ДЕЙСТВИЯ ШАБЛОНОВ

251

Шаблоны для формирования объектов
Эти шаблоны предназначены для создания экземпляров объектов. Это важная
категория, если учитывать принцип кодирования на основе интерфейса. Если в
своем проекте мы работаем с абстрактными родительскими классами, то долж
ны разработать стратегии создания экземпляров объектов на основе конкретных
подклассов. Эти объекты будут передаваться по всей системе.

Шаблоны для организации объектов и классов
Эти шаблоны помогают упорядочить композиционные отношения объектов.
Проще говоря, эти шаблоны показывают, как объединять объекты и классы.

Шаблоны, ориентированные на задачи
Эти шаблоны описывают механизмы, посредством которых классы и объекты
взаимодействуют для достижения целей.

Промышленные шаблоны
Мы рассмотрим некоторые шаблоны, описывающие типичные задачи и ре
шения программирования для Интернета. Эти шаблоны, взятые в основном из
книг Patterns of Enterprise Application Architecture и Core J2EE Patterns, имеют
отношение к представлению данных и логике приложения.

Шаблоны баз данных
Мы также сделаем краткий обзор шаблонов, которые помогают сохранять и
извлекать данные из баз данных и устанавливать соответствие между объектами
базы данных и приложения.

Резюме
В этой главе мы рассмотрели некоторые принципы, лежащие в основе мно
гих проектных шаблонов. Мы обсудили применение композиции, дающей воз
можность сочетать и воссоединять объекты во время выполнения программы.
Это позволяет создавать более гибкие структуры, чем те, в которых применя
ется только наследование. Мы представили также развязку — норму практики
выделения программных компонентов из их контекста, чтобы применять их в
более обширном контексте. И, наконец, проанализировали особое значение ин
терфейса как средства развязки клиентского кода от подробностей реализации.
В последующих главах мы подробнее исследуем некоторые проектные шабло
ны, основные категории которых были вкратце описаны в этой главе.

ГЛАВА 9

я

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

Шаблон Singleton. Специальный класс, формирующий один и только
один экземпляр объекта.
Шаблон Factory Method. Создание иерархии наследования классов со
здателя.

$ Шаблон Abstract Factory. Создание групп функционально связанных
программных продуктов.
Шаблон Prototype. Применение операции clone для формирования
объектов.

Шаблон Service Locator. Запрашивание объектов у системы.

Шаблон Dependency Injection. Наделение системы полномочиями пре
доставлять объекты.

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

254

ЧАСТЬ III & ШАБЛОНЫ

эффектом такого подхода оказывается отложенный характер получения экзем
пляров объектов.
Вот класс, конструктору которого передается строка с именем сотрудника,
для которого и создается экземпляр конкретного объекта.
// Листинг 09.01
abstract class Employee
{
protected $name;

public function __ construct(string $name)
{
$this->name = $name;
}
abstract public function fire();
}
// Листинг 09.02

class Minion extends Employee
{
public function fire()
{
print "{$this->name}: я уберу co стола\п";
}
}
// Листинг 09.03

class NastyBoss
{
private Semployees =

[];

public function addEmployee(string $employeeName)
{
$this->employees[] = new Minion($employeeName);
}

public function projectFails()
{
if (count($this->employees) > 0) {
$emp = array_pop($this->employees);
$emp->fire();
}
}

}
// Листинг 09.04

$boss = new NastyBoss();
$boss->addEmployee ( ’’Игорь" );
$boss->addEmployee( "Владимир"
$boss->addEmployee( "Мария" );
$boss->projectFails();

);

ГЛАВА 9

ФОРМИРОВАНИЕ ОБЪЕКТОВ

255

В результате выполнения данного примера будет выведена приведенная ниже
строка.
Мария: я уберу со стола

Как видите, мы определяем абстрактный базовый класс Employee и ре
ализующий его класс Minion. Получив символьную строку с именем, ме
тод NastyBoss : : addEmployee () создает экземпляр нового объекта типа
Minion. Каждый раз, когда злобный начальник, представленный объектом
типа NastyBoss, попадает в неприятную ситуацию (из-за вызова метода
NastyBoss::projectFails (), т.е. провала проекта), он ищет подходящего под
чиненного, представленного объектом типа Minion, чтобы уволить его.
Создавая экземпляр объекта типа Minion непосредственно в классе NastyBoss,
мы ограничиваем гибкость последнего. Вот если бы объект NastyBoss мог опе
рировать любым экземпляром объекта типа Employee, мы могли бы сделать код
доступным для изменения непосредственно во время выполнения программы,
просто введя дополнительные специализации класса Employee. Полиморфизм,
представленный на рис. 9.1, должен показаться уже знакомым вам.

Рис. 9.1. Оперирование абстрактным типом активизирует по
лиморфизм

Если класс NastyBoss не создаст экземпляр объекта Minion, то откуда он
возьмется? Авторы кода обычно уклоняются от решения данной проблемы, огра
ничивая тип аргумента в объявлении метода, а затем с легкостью опуская демон
страцию создания экземпляров везде, за исключением тестового контекста.
// Листинг 09.05
class NastyBoss

{
private $employees =

[];

256

ЧАСТЬ III « ШАБЛОНЫ

public function addEmployee(Employee $employee)
{

$this->employees[]

= $employee;

}
public function projectFails()

{
if

(count($this->employees)) {
$emp = array_pop($this->employees);
$emp->fire() ;

}
}

}

// Листинг 09.06
// Новый класс типа Employee...
class CluedUp extends Employee
{
public function fire()
{

print "{$this->name}:

я вызову адвоката\п";

}

}

// Листинг 09.07
$boss = new NastyBossO;
$boss->addEmployee(
new Minion( "Игорь"
)
$boss->addEmployee(
new CluedUp( "Владимир" )
$boss->addEmployee(
new Minion( "Мария"
)
$boss->projectFails();
$boss->projectFails() ;
$boss->projectFails() ;

);
);
);

В результате выполнения данного примера будет выведена приведенная ниже
строка.
Мария: я уберу со стола
Владимир: я вызову адвоката
Игорь: я уберу со стола

Несмотря на то что новая версия класса NastyBoss оперирует типом
Employee и поэтому получает выгоды от полиморфизма, мы все еще не опре
делили стратегию создания объекта. Получение экземпляров объектов — ма
лоприятная, но необходимая процедура. В этой главе речь пойдет о классах и
объектах, которые оперируют конкретными классами таким образом, чтобы из
бавить остальные классы от этой обязанности.
И если здесь требуется сформулировать принцип, то он должен гласить: “де
легировать получение экземпляров объекта”. Мы сделали это неявно в преды
дущем примере, потребовав, чтобы методу NastyBoss: :addEmployee () пере
давался объект типа Employee. Но мы могли бы точно так же делегировать

ГЛАВА 9

ФОРМИРОВАНИЕ ОБЪЕКТОВ

257

эту функцию отдельному классу или методу, который принимает на себя от
ветственность формировать объекты типа Employee. Итак, введем статический
метод в класс Employee, где и реализована стратегия создания объекта.
// Листинг 09.08
abstract class Employee

{
protected $name;
private static $types =

['Minion', 'CluedUp',
'WellConnected'];

public static function recruit(string $name)

{
$num = rand(l, count(self::$types)) - 1;
$class = __ NAMESPACE__ . ”\\".self::$types[$num];
return new $class($name);
}

public function __ construct(string $name)

{
$this->name = $name;

}
abstract public function fire();
}

// Листинг 09.09
// новый класс типа Employee...
class WellConnected extends Employee
{

public function fire()

{
print "{$this->name}:

я позвоню папе\п";

}

}

Как видите, данному методу передается символьная строка с именем сотруд
ника, которая служит для получения экземпляра конкретного подтипа Employee,
выбранного случайным образом. Теперь мы можем делегировать подробности
получения экземпляра объекта методу recruit () из класса Employee.
// Листинг 09.10

$boss = new NastyBoss();
$boss->addEmployee( Employee::recruit(
$boss->addEmployee( Employee::recruit(
$boss->addEmployee( Employee::recruit(
$boss->projectFails ();
$boss->projectFails ();
$boss->projectFails();

"Игорь"
"Владимир"
"Мария"

)
)
)

);
);
);

258

ЧАСТЬ III В ШАБЛОНЫ

В результате выполнения данного примера будет выведена приведенная ниже
строка. Не забывайте, что формирование объектов типа Employee делалось ме
тодом recruit () случайным образом. Поэтому у вас могут получиться другие
результаты, которые будут изменяться при каждом запуске программы.
Мария: я вызову адвоката
Владимир: я вызову адвоката
Игорь: я позвоню папе

Простой пример подобного класса уже демонстрировался в главе 4, "Расши
ренные средства”. Если помните, тогда мы разместили статический метод под
названием getlnstance () в классе ShopProduct.
НА ЗАМЕТКУ. В этой главе часто употребляется термин фабрика. Фабрика — это класс

или метод, отвечающий за формирование объектов.

Метод getlnstance () отвечал за формирование подходящего подкласса,
производного от класса ShopProduct, на основании данных, полученных в ре
зультате запроса к базе данных. Поэтому класс ShopProduct выполняет двой
ную роль. Он определяет тип ShopProduct и действует как фабрика по созда
нию конкретных объектов этого типа, как показано ниже.
public static function getlnstance(int $id,
ShopProduct

PDO $pdo):

{.
$stmt = $pdo->prepare("select ★ from products where id=?");
$result = $stmt->execute([$id]);
$row = $stmt->fetch() ;
if (empty($row) ) {
return null;

}
if

($row['type'] == "book") {
// получить экземпляр объекта типа BookProduct

}

elseif ($row' ['type'] === "cd") {
// получить экземпляр объекта типа CdProduct

}

else {
// получить экземпляр объекта типа ShopProduct

}
$product->setld($row['id']);
$product->setDiscount($row['discount']);
return $product;
}

В методе getlnstance () используется довольно крупный условный опера
тор с целью определить конкретные подклассы для получения их экземпляров.
Подобные условные операторы распространены в коде фабрик. Обычно в про
ектах следует избавляться от крупных условных операторов, но такие действия

ГЛАВА 9 ® ФОРМИРОВАНИЕ ОБЪЕКТОВ

259

часто приводят к тому, что выполнение условных операторов откладывается до
момента формирования объектов. Как правило, это не представляет серьезных
трудностей, потому что параллельные условные операторы удаляются из ис
ходного кода, чтобы приурочить принятие решение к данному моменту. В этой
главе мы исследуем некоторые из основных шаблонов “Банды четырех” для
формирования объектов.

Шаблон Singleton
Глобальная переменная — это один из самых крупных источников проблем
для разработчика, пользующегося методикой ООП. Причины этого к настояще
му моменту уже должны быть вам понятны. Глобальные переменные привязы
вают классы к их контексту, подрывая основы инкапсуляции (более подробно об
этом см. в главах 6, “Объекты и проектирование”, и 8, “Некоторые принципы
действия шаблонов”). Если в классе применяется глобальная переменная, то его
невозможно извлечь из одного приложения и применить в другом, не убедив
шись сначала, что в новом приложении определяются такие же глобальные пе
ременные.
Незащищенный характер глобальных переменных может стать причиной се
рьезных осложнений, несмотря то, что ими удобно пользоваться. Как только
вы начнете пользоваться глобальными переменными, останется только ждать,
когда в одной из библиотек будет объявлена глобальная переменная, которая
в конечном счете вступит в конфликт с другой глобальной переменной, объяв
ленной где-нибудь еще. Мы уже отмечали, что язык РНР уязвим к конфликтам
имен классов, но конфликт глобальных переменных оказывается намного бо
лее серьезным. Ведь интерпретатор РНР не предупредит вас, когда произойдет
такой конфликт. Вы узнаете об этом только тогда, когда ваша программа нач
нет вести себя ненормально. А еще хуже, если вы вообще не заметите никаких
затруднений на стадии разработки. Но, используя глобальные переменные, вы
потенциально подвергаете пользователей угрозе новых конфликтов, когда они
попытаются воспользоваться вашей библиотекой вместе с другими ресурсами.
Но искушение воспользоваться глобальными переменными все равно оста
ется. Дело в том, что иногда недостатки глобальных переменных становятся
именно той ценой, которую приходится платить за предоставление всем классам
доступа к объекту.
Как пояснялось выше, избежать подобного рода затруднений частично помо
гают пространства имен. Они, по крайней мере, позволяют собрать переменные
в отдельном пакете, а это означает, что библиотеки сторонних разработчиков
уже в меньшей степени будут вступать в конфликт с исходным кодом проекти
руемой системы. Но даже в таком случае существует риск возникновения кон
фликтов в самом пространстве имен.

260

ЧАСТЬ III Я ШАБЛОНЫ

Проблема
Как правило, в удачно спроектированных системах экземпляры объектов передаются в виде параметров при вызове методов. При этом каждый класс со
храняет свою независимость от более обширного контекста и взаимодействует
с другими частями системы через очевидные каналы связи. Но иногда можно
обнаружить, что некоторые классы приходится использовать как каналы переда
чи данных для объектов, которые не имеют к ним никакого отношения, создавая
зависимости ради грамотного проектирования.
Рассмотрим в качестве примера класс Preferences, в котором хранятся
данные, используемые в процессе выполнения приложения. Мы можем вос
пользоваться объектом типа Preferences для хранения таких параметров, как
символьные строки DSN (т.е. строки, содержащие имена источников данных,
в которых хранятся сведения о базе данных), URL сайта, пути к файлам и т.д.
Очевидно, что подобные сведения могут меняться в зависимости от конкретной
установки. Данный объект может также использоваться в качестве доски объяв
лений (или центра размещения сообщений), которые размещаются или извлека
ются объектами системы, не связанными с ним никак иначе.
Но идея передавать объект типа Preferences от одного объекта к друго
му — не всегда оказывается удачной. Многие классы, где этот объект вообще
не используется, будут вынуждены принимать его лишь для того, чтобы пере
дать его объектам, с которыми они взаимодействуют. В итоге получается лишь
другой вид тесного связи.
Мы также должны быть уверены, что все объекты в проектируемой системе
взаимодействуют с одним и тем же объектом типа Preferences. Нам не нуж
но, чтобы одни объекты устанавливали значения в каком-то объекте, тогда как
другие читали данные из совершенно иного объекта.
Итак, выделим действующие факторы рассматриваемой здесь проблемы.
Объект типа Preferences должен быть доступен любому объекту в про
ектируемой системе.
в Объект типа Preferences не должен сохраняться в глобальной перемен
ной, значение которой может быть случайно изменено.

В проектируемой системе не должно быть больше одного объекта типа
Preferences. Это означает, что объект Y может установить свойство в
объекте типа Preferences, а объект Z — извлечь то же самое значение
этого свойства, причем без непосредственного взаимодействия объектов
между собой (предполагается, что оба эти объекта имеют доступ к объек
ту типа Preferences).

Реализация
Чтобы решить данную задачу, начнем с установления контроля над полу
чением экземпляров объектов. Создадим для этого класс, экземпляр которого

ГЛАВА 9

ФОРМИРОВАНИЕ ОБЪЕКТОВ

261

нельзя получить за его пределами. На первый взгляд может показаться, что сде
лать это трудно. Но на самом деле это лишь вопрос определения закрытого
конструктора.
class Preferences
{
private $props =

[];

private function __ construct()
{
}

public function setProperty(string $key,
{
$this->props[$key] = $val;
}
public function getProperty(string $key):
{
return $this->props[$key];
}

string $val)

string

Безусловно, в данный момент класс Preferences совершенно бесполезен,
поскольку мы довели ограничение доступа до абсурдного уровня. В частности,
конструктор объявлен как private, и никакой клиентский код не сможет по
лучить с его помощью экземпляр объекта. Поэтому методы setProperty () и
getProperty () оказываются лишними.
Мы можем воспользоваться статическим методом и статическим свойством,
чтобы получить экземпляр объекта через посредника, как показано ниже.
// Листинг 09.11
class Preferences
{
private $props = [];
private static $instance;
private function __ construct()
{
}

public static function getlnstance ()
{
if (empty(self::$instance)) {
self::$instance = new Preferences ();
}
return self::$instance;
}
public function setProperty(string $key,
{
$this->props[$key] = $val;
}
public function getProperty(string $key):
{
return $this->props[$key];

string $val)

string

262

ЧАСТЬ III В ШАБЛОНЫ

Свойство $ instance объявлено закрытым и статическим, поэтому оно недо
ступно за пределами его класса, но доступно из метода getlnstance (). Ведь
этот метод объявлен как открытый и статический, а следовательно, его можно
вызвать через класс из любого места в сценарии, как показано ниже.
// Листинг 09.12

$pref = Preferences::getlnstance();
$pref->setProperty("name", "Иван");
unset($pref); // удалить ссылку
$pref2 = Preferences::getlnstance();
print $pref2->getProperty("name") ."\n";
// покажем, что значение не утрачено

В итоге будет выведено единственное значение параметра name, которое
было ранее добавлено в объект типа Preferences и получено посредством от
дельного доступа к нему.
Иван

Статический метод не может получить доступ к свойствам объектов, потому
что он по определению вызывается из класса, а не из контекста объекта. Но он
может получить доступ к статическому свойству. Когда, например, вызывается
метод getlnstance (), проверяется свойство Preferences: :$instance. Если
оно пусто, то создается экземпляр класса Preferences, который сохраняется в
этом свойстве, а ссылка на него возвращается в вызывающий код. А поскольку
статический метод getlnstance () входит в состав класса типа Preferences,
то получение экземпляра класса Preferences не вызывает особых затрудне
ний, даже несмотря на закрытый конструктор этого класса.
Действие шаблона Singleton в данном примере показано на рис. 9.2.
I

[ «создает»

!

Preferences

1

-instance

1

1_______

-_construct()
+getlnstance()
+setProperty(key:String,value:string)
+getProperty(key:String)

if ( empty(self::$instance ) ) {
self::$instance = new Preferences();
}
return self::$instance;

Рис- 9-2- Пример применения шаблона Singleton

ГЛАВА 9

ФОРМИРОВАНИЕ ОБЪЕКТОВ

263

Выводы
Насколько же хорош подход к применению шаблона Singleton по сравне
нию с глобальными переменными? Начнем с плохого. Шаблоном Singleton и
глобальными переменными часто злоупотребляют. Доступ к одноэлементным
объектам можно получить из любого места в системе, и поэтому они могут спо
собствовать созданию зависимостей, которые затрудняют отладку приложения.
А изменения в шаблоне Singleton повлияют на классы, в которых он приме
няется. Сами зависимости не представляют особых трудностей. Ведь мы соз
даем зависимость всякий раз, когда объявляем, что методу требуется передать
аргумент определенного типа. Трудность состоит в том, что глобальный харак
тер шаблона Singleton дает программисту возможность обойти каналы связи,
определяемые в интерфейсах классов. Когда применяется шаблон Singleton,
зависимость скрыта в теле метода и не объявляется в его сигнатуре. Это затруд
няет отслеживание связей в системе. Поэтому одноэлементные классы должны
применяться редко и очень осторожно.
Тем не менее я считаю, что умеренное использование шаблона Singleton
может улучшить проектирование системы, избавив ее от излишнего загромо
ждения при передаче ненужных объектов в системе. Одноэлементные объекты
по шаблону Singleton являются шагом вперед по сравнению с применением
глобальных переменных в объектно-ориентированном контексте, поскольку за
тереть такие объекты неправильными данными нельзя.

Шаблон Factory Method
В объектно-ориентированном проекте акцент делается на абстрактном клас
се, а не на его реализации, т.е. на обобщениях, а не на частностях. Шаблон
Factory Method (Фабричный метод) решает задачу получения экземпляров
объектов, когда в исходном коде применяются абстрактные типы. И в чем же
состоит решение? Оно состоит в том, чтобы поручить обязанность получения
экземпляров объектов специальным классам.

Проблема
Рассмотрим проект личного дневника. В числе прочих в нем придется иметь
дело с объектом типа Appointment, представляющего назначенную встречу.
Допустим, что бизнес-группа нашей компании установила взаимоотношения
с другой компанией, и нам поручено передать им информацию о назначенной
встрече в формате BloggsCal. Но нас предупредили, что со временем могут по
надобиться и другие форматы.
Оставаясь на уровне одного только интерфейса, мы можем сразу опреде
лить двух участников. В частности, нам потребуется кодировщик данных для
преобразования объектов типа Appointment во внутренний формат BloggsCal.
Присвоим этому классу имя ApptEncoder. Кроме того, нам потребуется

264

ЧАСТЬ III

ШАБЛОНЫ

управляющий класс, который будет производить поиск кодировщика данных, а
возможно, взаимодействовать с ним для установления связи с третьей стороной.
Присвоим этому классу имя CommsManager. Используя терминологию данно
го шаблона, можно сказать, что класс CommsManager — это производитель, а
класс Appt Encoder — продукт. Такая структура показана на рис. 9.3.

CommsManager

«создает»

ApptEncoder
+encode(): String

+getApptEncoder(): ApptEncoder

Рис. 9.3. Абстрактные классы производителя и продукта

Но как на самом деле получить конкретный объект типа ApptEncoder? Для
этого можно потребовать, чтобы объект типа ApptEncoder передавался объекту
типа CommsManager, хотя это лишь откладывает решение данной проблемы, а
нам нужно решить ее безотлагательно. Получим с этой целью экземпляр объек
та типа BloggsApptEncoder непосредственно в классе CommsManager:
// Листинг 09.13

abstract class ApptEncoder
{
abstract public function encode():
}

string;

// Листинг 09.14
class BloggsApptEncoder extends ApptEncoder
{
public function encode(): string
{
return ’’Данные о встрече закодированы в формате BloggsCal \п";
}
}

// Листинг 09.15
class MegaApptEncoder extends ApptEncoder
{
public function encode(): string
{
return ’’Данные о встрече закодированы в формате MegaCai \п”;
}
}
// Листинг 09.16

class CommsManager
{
public function getApptEncoder():
{
return new BloggsApptEncoder();

ApptEncoder

ГЛАВА 9 % ФОРМИРОВАНИЕ ОБЪЕКТОВ

265

Класс CommsManager отвечает за формирование объектов типа
BloggsApptEncoder. А когда корпоративные обязательства изменятся и нас по
просят приспособить спроектированную систему к новому формату MegaCai, мы
просто введем условный оператор в метод CommsManager: :getApptEncoder ().
Ведь это же стратегия, которой мы пользовались раньше. Итак, создадим но
вую реализацию класса CommsManager для поддержки форматов BloggsCal и
MegaCai.
// Листинг 09.17
class CommsManager

(
const BLOGGS = 1;
const MEGA = 2;
private $mode;
public function __ construct(int $mode)
{

$this->mode = $mode;
}

public function getApptEncoder(): ApptEncoder

{
switch ($this->mode) {
case (self::MEGA):
return new MegaApptEncoder();
default:
return new BloggsApptEncoder();
}

}
}

// Листинг 09.18
$man =
print
$man =
print

new CommsManager(CommsManager::MEGA);
(get_class($man->getApptEncoder())) . "\n”;
new CommsManager(CommsManager ::BLOGGS);
(get_class($man->getApptEncoder())) . ”\n";

В качестве флажков, определяющих два режима, в которых может работать
сценарий, мы используем константы класса CommsManager: MEGA и BLOGGS.
А в методе getApptEncoder () применяется оператор switch, чтобы прове
рить свойство $mode и получить экземпляр соответствующей реализации аб
страктного класса ApptEncoder.
Но описанный выше подход не совсем удачен. Использование условных
операторов иногда считается дурным тоном и признаком недоброкачественно
го кода, хотя их нередко приходится применять в какой-то момент при созда
нии объектов. Но не стоит слишком снисходительно относиться к проникнове
нию в исходный код дубликатов условных операторов. Класс CommsManager
предоставляет функциональные средства для передачи календарных данных.

266

ЧАСТЬ III

ШАБЛОНЫ

Допустим, что в используемых нами протоколах требуется вывести данные в
верхнем и нижнем колонтитулах, чтобы очертить границы каждой назначен
ной встречи. Расширим с этой целью предыдущий пример, определив метод
getHeaderText().
// Листинг 09.19

class CommsManager

{
const BLOGGS = 1;
const MEGA = 2;
private $mode;
public function __ construct(int $mode)

{
$this->mode = $mode;
}

public function getApptEncoder(): ApptEncoder
{

switch ($this->mode) {
case (self::MEGA):
return new MegaApptEncoder() ;
default:
return new BloggsApptEncoder();
}

}
public function getHeaderText():

string

(

switch ($this->mode) {
case (self::MEGA):
return ’’MegaCai верхний колонтитул \n";
default:
return "BloggsCal верхний колонтитул \n";
}

}
}

Как видите, необходимость в поддержке вывода данных в верхнем и нижнем
колонтитулах вынудила нас продублировать проверку типа протокола с помо
щью оператора switch уже в методе getHeaderText (). Но по мере внедрения
поддержки новых протоколов код становится все более громоздким, особенно
если ввести в него еще и метод getFooterText ().
Подытожим все, что нам удалось выяснить до сих пор в отношении рассма
триваемой здесь проблемы.

w До момента выполнения программы мы не знаем, какой тип объекта нам
понадобится создать (BloggsApptEncoder или MegaApptEncoder).
ш Мы должны иметь возможность достаточно просто добавлять новые типы
объектов (например, для поддержки протокола SyncML в соответствии с
очередным коммерческим требованием).

ГЛАВА 9

ФОРМИРОВАНИЕ ОБЪЕКТОВ

267

Каждый вид продукта связан с контекстом, где требуются другие специ
ализированные операции (например, методы getHeaderText() и
getFooterText ()).
Следует также отметить, что в данном случае употребляются условные опе
раторы, но, как было показано ранее, их можно естественным образом заменить
полиморфизмом. Шаблон Factory Method позволяет применять наследование и
полиморфизм, чтобы инкапсулировать создание конкретных продуктов. Иными
словами, для каждого протокола создается свой подкласс типа CommsManager,
в котором реализован свой метод getApptEncoder ().

Реализация
В шаблоне Factory Method классы производителей отделены от продуктов,
которые они должны формировать. Производитель — это класс фабрики, в ко
тором определен метод для формирования объекта отдельного продукта. Если
стандартной реализации этого метода не предусмотрено, то получение экзем
пляров объектов поручается дочерним классам производителя. Как правило, в
каждом подклассе производителя получается экземпляр параллельного дочерне
го класса продукта.
Переопределим класс CommsManager как абстрактный. Таким образом, мы
сохраним гибкий суперкласс и разместим весь код, связанный с конкретным
протоколом, в отдельных подклассах (рис. 9.4).

Рис. 9.4. Конкретные классы производителя и продукта

Ниже приведен пример несколько упрощенного кода.
// Листинг 09.20-

abstract class ApptEncoder

268

ЧАСТЬ III в ШАБЛОНЫ

{
abstract public function encode():

string;

}
// Листинг 09.21

class BloggsApptEncoder extends ApptEncoder
{
public function encode(): string
{
return "Данные о встрече закодированы в формате BloggsCal \п";
}
}
// Листинг 09.22

abstract class CommsManager
{
abstract public function getHeaderText () : string;
abstract public function getApptEncoder(): ApptEncoder;
abstract public function getFooterText(): string;
}
// Листинг 09.23

class BloggsCommsManager extends CommsManager
{
public function getHeaderText(): string
{
return "BloggsCal верхний колонтитул \n";
}

public function getApptEncoder(): ApptEncoder
{
return new BloggsApptEncoder();
}
public function getFooterText(): string
{
return "BloggsCal нижний колонтитул \n";
}

}

// Листинг 09.24
$mgr = new BloggsCommsManager();
print $mgr->getHeaderText();
print $mgr->getApptEncoder()->encode();
print $mgr->getFooterText();

BloggsCal верхний колонтитул
Данные о встрече закодированы в формате BloggsCal
BloggsCal нижний колонтитул

Когда же от нас потребуют реализовать поддержку протокола MegaCai, для
этого достаточно будет написать новую реализацию абстрактных классов. Такие
классы для поддержки протокола MegaCai приведены на рис. 9.5.

ГЛАВА 9

ФОРМИРОВАНИЕ ОБЪЕКТОВ

269

Рис. 9.5. Расширение проекта для поддержки нового протокола

Выводы
Обратите внимание на то, что классы производителей отражают иерархию
продуктов. Это обычный результат, получаемый в результате применения ша
блона Factory Method. Некоторые программисты считают этот шаблон особым
видом дублирования кода и поэтому часто испытывают к нему антипатию. Еще
один недостаток шаблона Factory Method заключается в том, что он нередко
способствует ненужной подклассификации. Следовательно, если применение
шаблона Factory Method не предполагается для формирования подклассов
производителей, а иных причин для его употребления не существует, то реко
мендуется сначала хорошенько подумать. Именно поэтому мы продемонстриро
вали в приведенном выше примере ограничения, которые накладывает поддерж
ка верхнего и нижнего колонтитулов.
В данном примере мы сосредоточились только на поддержке данных для на
значенных встреч. Если же немного расширить этот пример, включив в него
элементы заданий и контактов, то мы столкнемся с новой проблемой. Нам по
надобится структура, которая должна одновременно обращаться с целым рядом
связанных реализаций. Поэтому шаблон Factory Method нередко применяется
вместе с шаблоном Abstract Factory, как поясняется в следующем разделе.

270

ЧАСТЬ III в ШАБЛОНЫ

Шаблон Abstract Factory
В крупных приложениях могут понадобиться фабрики, формирующие свя
занные вместе совокупности классов. И эту проблему позволяет решить шаблон
Abstract Factory (Абстрактная фабрика).

Проблема
Обратимся снова к примеру реализации личного дневника. Ранее мы написа
ли код для поддержки двух форматов и соответствующих протоколов BloggsCal
и MegaCai. Эту структуру можно легко нарастить по горизонтали, добавив под
держку дополнительных форматов для кодирования данных. Но как нарастить
ее по вертикали, чтобы добавить кодировщики данных для разных типов объ
ектов личного дневника? На самом деле мы уже работаем по данному шаблону.
На рис. 9.6 показаны параллельные семейства продуктов, с которыми нам
предстоит работать. Это назначенные встречи (Appt), задания (Things То Do,
Ttd) и контакты (Contact).

Рис. 9.6. Три семейства продуктов

ГЛАВА 9

ФОРМИРОВАНИЕ ОБЪЕКТОВ

271

Как видите, классы, поддерживающие формат BloggsCal, не связаны посред
ством наследования, хотя они могут реализовывать общий интерфейс. Но в то
же время они выполняют параллельные функции. Если система работает в на
стоящее время с классом BloggsTtdEncoder, то она должна работать и с клас
сом BloggsContactEncoder.
Чтобы понять, как соблюсти данное требование, начнем с интерфейса, как
мы это делали раньше, применяя шаблон Factory Method (рис. 9.7).

Рис. 9.7. Абстрактный производитель и его абстрактные продукты

Реализация
В абстрактном классе CommsManager определяется интерфейс для формиро
вания каждого из трех продуктов, представленных объектами типа ApptEncoder,
TtdEncoder и ContactEncoder. Поэтому необходимо реализовать конкретный
объект создателя, чтобы формировать конкретные объекты продуктов для опре
деленного семейства. Как это можно сделать для поддержки формата BloggsCal,
показано на рис. 9.8.
Ниже приведен вариант исходного кода для классов CommsManager и Bloggs
CommsManager.
// Листинг 09.25

abstract class CommsManager
{
: string;
abstract public function getHeaderText()
: ApptEncoder;
abstract public function getApptEncoder()
: TtdEncoder;
abstract public function getTtdEncoder()
abstract public function getContactEncoder(): ContactEncoder;
: string;
abstract public function getFooterText()

// Листинг 09.26

class BloggsCommsManager extends CommsManager
{
public function getHeaderText(): string

272

ЧАСТЬ III ® ШАБЛОНЫ
return ’’BloggsCal верхний колонтитул \п";

}

public function getApptEncoder(): ApptEncoder
{
return new BloggsApptEncoder();
}

public function getTtdEncoder():
{
return new BloggsTtdEncoder();
}

TtdEncoder

public function getContactEncoder():
{
return new BloggsContactEncoder();
}

ContactEncoder

public function getFooterText(): string
{
return ’’BloggsCal нижний колонтитул \n";
}

Рис. 9.8. Ввод конкретного производителя и некоторых конкретных
продуктов

ГЛАВА 9 ® ФОРМИРОВАНИЕ ОБЪЕКТОВ

273

Рис. 9.9. Ввод конкретных производителей и некоторых конкретных продуктов

274

ЧАСТЬ III ® ШАБЛОНЫ

Обратите внимание на то, что в данном примере применяется шаблон
Factory Method. Метод getContactEncoder () объявлен абстрактным в клас
се CommsManager и реализован в классе BloggsCommsManager. В результате
проектные шаблоны работают совместно, причем один создает контекст, кото
рый служит для другого шаблона. На рис. 9.9 показано, как добавлена поддерж
ка формата MegaCai.

Выводы
Так что же дает применение шаблона Abstract Factory?
» Во-первых, мы развязали проектируемую систему от подробностей реали
зации. В данном примере можно вводить или удалять любое количество
форматов кодирования, не опасаясь каких-нибудь осложнений.
» Во-вторых, мы ввели в действие группу функционально связан
ных элементов проектируемой системы. Поэтому применение класса
BloggsCommsManager гарантирует, что работать придется только с клас
сами, связанными с форматом BloggsCal.
« В-третьих, добавление новых продуктов может оказаться затруднительным.
Для этого нам придется не только создать конкретные реализации новых
продуктов, но и внести изменения в абстрактный класс производителя,
а также создать каждый конкретный реализатор, чтобы поддержать его.

Во многих реализациях шаблона Abstract Factory применяется шаблон
Factory Method. Возможно, причина заключается в том, что большинство при
меров написано на Java или C++. Но в языке РНР не накладываются обяза
тельные ограничения на тип, возвращаемый из метода, хотя теперь это можно
сделать. И это обеспечивает определенную гибкость, которой можно выгодно
воспользоваться.
Вместо того чтобы создавать отдельные методы для каждого объекта по ша
блону Factory Method, можно создать один метод make () и передать ему в
качестве аргумента флаг, определяющий тип возвращаемого объекта, как пока
зано ниже.
// Листинг 09.27

interface Encoder

{
public function encode():
}
// Листинг 09.28

abstract class CommsManager
{

const APPT = 1;
const TTD = 2;
const CONTACT = 3;

string;

ГЛАВА 9 кФОРМИРОВАНИЕ ОБЪЕКТОВ

275

abstract public function getHeaderText(): string;
abstract public function make(int $flag_int): Encoder;
abstract public function getFooterText(): string;
}

// Листинг 09.29
class BloggsCommsManager extends CommsManager

{

public function getHeaderText():

string

{

return "BloggsCal верхний колонтитул \n";
}

public function make(int $flag_int):

Encoder

{
switch ($flag_int) {
case self::APPT:
return new BloggsApptEncoder();
case self::CONTACT:
return new BloggsContactEncoder();
case self::TTD:
return new BloggsTtdEncoder();

}
}
public function getFooterText():

string

{

return "BloggsCal нижний колонтитул \n";
}

}

Как видите, мы сделали интерфейс класса более компактным, но заплатили
за это достаточно дорого. Используя шаблон Factory Method, мы определяем
четкий интерфейс и вынуждаем все конкретные объекты фабрики подчиняться
ему. Используя единственный метод make (), мы должны помнить о поддержке
всех объектов продуктов во всех конкретных производителях. Мы также упо
требляем параллельные условные операторы, поскольку в каждом конкретном
производителе должны быть реализованы одинаковые проверки флагов. Клиент
ский класс не может быть уверен, что конкретные производители формируют
весь набор продуктов, поскольку внутренняя организация метода make () может
отличаться в каждом отдельном случае.
С другой стороны, можно построить более гибкие производители. В базовом
классе производителя можно предусмотреть метод make(), который будет га
рантировать стандартную реализацию для каждого семейства продуктов. И тог
да конкретные дочерние классы могут избирательно видоизменять такое поведе
ние. Классам, реализующим производителя, будет предоставлено право выбора,
вызывать ли стандартный метод make () после собственной реализации или не
вызывать. Еще один вариант шаблона Abstract Factory мы рассмотрим в сле
дующем разделе.

276

ЧАСТЬ III

ШАБЛОНЫ

Шаблон Prototype
Когда применяется шаблон Factor Method, появление параллельных иерар
хий наследования может вызывать осложнения. Этот вид тесной связи вызывает
у некоторых программистов ощущение дискомфорта. Всякий раз, когда вводит
ся новое семейство продуктов, в рассматриваемом здесь примере приходится
создавать связанного с ним конкретного производителя (например, кодиров
щикам данных формата BloggsCal соответствует класс BloggsCommsManager).
В системе, которая быстро расширяется и включает в себя много продуктов,
поддержание такого рода связи может быстро стать очень трудоемким делом.
Чтобы исключить подобную зависимость, можно, в частности, воспользо
ваться ключевым словом clone языка РНР, чтобы продублировать существую
щие конкретные продукты. И тогда конкретные классы продуктов сами станут
основой для формирования их собственных объектов. Это, по существу, означа
ет действовать по шаблону Prototype (Прототип), который позволяет заменить
наследование композицией. Такой подход, в свою очередь, способствует гибко
сти во время выполнения программы и сокращает количество классов, которые
требуется создать.

Проблема
Представьте веб-игру типа “Цивилизация”, в которой элементы действуют
на клеточном поле. Каждая клетка может представлять море, равнину или лес.
Тип местности может ограничивать движение и возможности элементов занять
клетку. Допустим, у нас имеется объект типа TerrainFactory (Фабрика мест
ности), который позволяет создавать объекты типа Sea (море), Forest (лес) и
Plains (равнины). Мы решили дать пользователю возможность выбирать со
вершенно разные типы окружающей среды. Следовательно, объект типа Sea
относится к абстрактному суперклассу, реализуемому в классах Mars Sea и
EarthSea. Аналогичным образом реализуются объекты типа Forest и Plains.
В данном случае можно применить шаблон Abstract Factory. У нас имеются
различные иерархии продуктов (Sea, Forest, Plains) с сильными родствен
ными отношениями, включающими наследование (Earth, Mars). На рис. 9.10
представлена диаграмма классов, наглядно показывающая, каким образом мож
но применить шаблоны Abstract Factory и Factory Method для работы с
этими продуктами.
Как видите, мы используем наследование, чтобы сгруппировать семейство
типов местности для продуктов, которые будут произведены на фабрике. Это
подходящее решение, но оно требует крупной иерархии наследования и не обла
дает достаточной гибкостью. Если не нужны параллельные иерархии наследова
ния, но требуется максимальная гибкость во время выполнения, в таком случае
можно применить шаблон Prototype как более эффективный вариант шаблона
Abstract Factory.

ГЛАВА 9 ш ФОРМИРОВАНИЕ ОБЪЕКТОВ

277

__________________________________________________________ J
Рис. 9.10. Обращение с различными типами местности по шаблону Abstract

Factory

Реализация
Применяя шаблоны Abstract Factory и Factory Method, мы должны ре
шить в определенный момент, с каким конкретно производителем нам требуется
работать. Вероятно, это можно осуществить, проанализировав значения неко
торого флага. А поскольку мы должны это так или иначе сделать, то почему
бы не создать просто класс фабрики для хранения конкретных продуктов и их
размножения во время инициализации? Таким образом, мы можем избавиться
от нескольких классов и, как мы вскоре увидим, воспользоваться другими пре
имуществами. Ниже приведен пример простого кода, где в качестве фабрики
применяется шаблон Prototype.
// Листинг 09.30
class Sea
{
}
class EarthSea extends Sea

278

ЧАСТЬ III в ШАБЛОНЫ

{
}
class MarsSea extends Sea
{
}
class Plains
{
}
class EarthPlains extends Plains
{
}
class MarsPlains extends Plains
{
}
class Forest
{
}
class EarthForest extends Forest
{
}
class MarsForest extends Forest
{
}
// Листинг 09.31

class TerrainFactory
{
private $sea;
private $forest;
private $plains;
public function __ construct(Sea $sea, Plains $plains
Forest $forest)
{
$this->sea = $sea;
$this->plains = $plains;
$this->forest = $forest;
}

public function getSea () : Sea
{
return clone $this->sea;
}
public function getPlains():

Plains

{

return clone $this->plains;

}
public function getForest(): Forest
{
return clone $this->forest;

ГЛАВА 9 » ФОРМИРОВАНИЕ ОБЪЕКТОВ

279

// Листинг 09.32

$ factory = new TerrainFactory(
new EarthSea(),
new EarthPlains() ,
new EarthForest()

) ;
print_r($factory->getSea() ) ;
print_r($factory->getPlains());
print_r($factory->getForest() ) ;

EarthSea Object
(
)
EarthPlains Object

(
)
EarthForest Object
(

Как видите, в экземпляр конкретной фабрики типа TerrainFactory загру
жаются экземпляры объектов разных продуктов. Когда в клиентском коде вы
зывается метод getSea (), ему возвращается клон объекта типа Sea, который
размещается в кеше во время инициализации. В итоге нам не только удалось
сократить пару классов, но и достичь определенной гибкости. Хотите, что
бы игра происходила на новой планете с морями и лесами, как на Земле, и с
равнинами, как на Марсе? Для этого не нужно создавать новый класс произ
водителя, а достаточно изменить набор классов, который вводится в фабрику
TerrainFactory, как показано ниже.
$factory = new TerrainFactory(
new EarthSea() ,
new MarsPlains() ,
new EarthForest()

) ;

Таким образом, шаблон Prototype позволяет выгодно воспользоваться гиб
костью, которую обеспечивает композиция. Но мы получили нечто большее.
Ведь мы сохраняем и клонируем объекты во время выполнения программы,
а значит — воспроизводим состояние объектов, когда формируем новые про
дукты. Допустим, что у объектов типа Sea имеется свойство $navigability
(судоходность). От него зависит количество энергии движения, которое клетка
моря отнимает у судна. С помощью этого свойства можно регулировать уровень
сложности игры.

280

ЧАСТЬ III Я ШАБЛОНЫ

// Листинг 09.33
class Sea
{

private $navigability = 0;
public function __ construct(int $navigability)
{

$this->navigability = $navigability;

}
}

Теперь, когда инициализируется объект типа TerrainFactory, можно вве
сти объект типа Sea со свойством модификатора судоходности. И тогда это бу
дет иметь силу для всех объектов типа Sea, создаваемых с помощью фабрики
TerrainFactory. Такая гибкость становится очевидной и в том случае, когда
объект, который требуется сформировать, состоит из других объектов.
// Листинг 09.34
$factory = new TerrainFactory(
new EarthSea(-1),
new EarthPlains() ,
new EarthForest()

) ;

НА ЗАМЕТКУ. Клонирование объектов подробно пояснялось в главе 4, “Расширенные

средства”. При выполнении операции клонирования с помощью ключевого слова
clone получается неполная (или поверхностная) копия любого объекта, над которым
она выполняется. Это означает, что объект продукта будет обладать теми же самыми
свойствами, что и исходный объект. Если же какие-нибудь свойства исходного объек
та оказываются объектами, они не будут скопированы в объект продукта. Вместо это
го объект продукта будет ссылаться на те же самые свойства объекта. И вам решать,
следует ли изменить этот стандартный способ копирования объектов и применить
какой-нибудь другой способ, реализовав метод__ clone (). Этот метод вызывается
автоматически при выполнении операции клонирования с помощью ключевого слова
clone.

Все объекты типа Sea могут содержать объекты типа Resource (FishResource, OilResource и т.д.). В соответствии со значением свойства можно
определить, что по умолчанию все объекты типа Sea содержат объекты типа
FishResource. Но не следует забывать, что если в продуктах имеются ссылки
на другие объекты, следует реализовать метод__ clone (), чтобы создать пол
ную (или глубокую ) копию этого продукта.
class Contained

ГЛАВА 9 « ФОРМИРОВАНИЕ ОБЪЕКТОВ

281

class Container

{
public $contained;

function __ construct ()

{
$this->contained = new Contained();
}

function __ clone()

{
// Обеспечить, чтобы клонированный объект
// содержал клон объекта, хранящегося в
// свойстве self::$contained,
// а не ссылку на него
$this->contained = clone $this->contained;

}
}

Доведение до крайности: шаблон

Service Locator
Как было обещано, в этой главе должна идти речь о логике создания объек
тов, а не о конкретных примерах ООП. Но в некоторых рассмотренных здесь
шаблонах имеется ловко скрытое принятие решений о создании объектов, если
не само создание объектов.
Шаблон Singleton в этом обвинить нельзя. Встроенная в него логика созда
ния объектов совершенно однозначна. В шаблоне Abstract Factory создание
семейств продуктов группируется в разных конкретных классах производите
лей. Но как правильно выбрать конкретного производителя? Аналогичное за
труднение возникает, когда применяется шаблон Prototype. Оба эти шаблона
занимаются созданием объектов, но они откладывают решение, какой именно
объект (или группу объектов) следует создавать.
Решение о выборе конкретного производителя обычно принимается в соот
ветствии с заданным значением параметра конфигурации. Этот параметр может
находиться в базе данных, в файле конфигурации или в файле на сервере (на
пример, в файле конфигурации уровня каталогов на сервере Apache; обычно он
называется .htaccess) или может быть даже жестко закодирован в виде пере
менной или свойства в РНР. А поскольку конфигурацию приложений на РНР
приходится изменять по каждому запросу, то инициализация сценария должна
происходить как можно более безболезненно. Поэтому я нередко прибегаю к
жесткому кодированию значений флагов конфигурации в коде РНР. Это мож
но сделать вручную или написать сценарий для автоматического формирования
файла класса. Ниже приведен пример конфигурационного класса, в который
включен параметр для обозначения типа календарного протокола.

282

ЧАСТЬ III * ШАБЛОНЫ

// Листинг 09.35

class Settings
{

static $COMMSTYPE =

’Bloggs';

}

А теперь, когда имеется значение параметра, хотя это и сделано не совсем
изящно, можно создать класс, в котором данный параметр используется при
принятии решения, какой объект типа CommsManager следует предоставить по
запросу. В подобных случаях нередко применяется шаблон Singleton в соче
тании с шаблоном Abstract Factory, поэтому так и поступим.
// Листинг 09.36
class AppConfig
{

private static $instance;
private $CommsManager;
private function __ construct ()
{
// будет выполнено только один раз
$this->init();

}

private function init()
{

switch (Settings::$COMMSTYPE) {
case ’Mega’:
$this->commsManager * new MegaCommsManager();
break;
default:
$this->commsManager « new BloggsCommsManager();

}
}

public static function getlnstance (): AppConfig
{
if (empty(self::$instance)) {
self::$instance = new self();
}
return self::$instance;
}

public function getCommsManager():

CommsManager

{
return $this->commsManager;
}
}

Класс AppConfig — это стандартный одноэлементный класс (синглтон).
Поэтому мы можем легко получить ссылку на экземпляр класса AppConfig в
любом месте нашей программы, и это всегда будет ссылка на один и тот же

ГЛАВА 9

ФОРМИРОВАНИЕ ОБЪЕКТОВ

283

экземпляр. Метод init () вызывается конструктором класса и поэтому выпол
няется только один раз в процессе выполнения программы. В этом методе про
веряется значение свойства Settings: :$COMMSTYPE, и в соответствии с ним
создается экземпляр конкретного объекта типа CommsManager, как показано
ниже. Теперь в сценарии можно получить объект типа CommsManager и опери
ровать им, даже не зная о его конкретных реализациях или конкретных классах,
которые он формирует.
$commsMgr = AppConfig::getlnstance()->getCommsManager();
print $conunsMgr->getApptEncoder()->encode();

Класс AppConf ig организует поиск и создание компонентов автоматически,
и поэтому он служит характерным примером применения шаблона Service
Locator (Определитель служб). Это изящный шаблон (подробнее о нем речь
пойдет в главе 12, “Шаблоны корпоративных приложений”), хотя он и вносит
зависимость в менее легкой форме, чем при непосредственной инициализации.
В любых классах, где применяется столь монолитная служба, созданная по та
кому шаблону, приходится явным образом вызывать ее, что привязывает их к
остальной системе в более обширном контексте. Именно поэтому некоторые
предпочитают выбрать другой подход.

Блестящее одиночество: шаблон

Dependency Injection
В примере из предыдущего раздела для выбора на обслуживание одного из
классов, расширяющих класс CommsManager, был использован специальный
признак и условный оператор, хотя такое решение оказалось не таким гибким,
как хотелось бы. Доступные для выбора классы были жестко закодированы в
одном определителе служб, а выбор обоих компонентов встроен в условный
оператор. Но подобная негибкость является скорее недостатком продемонстри
рованного выше кода, а не самого шаблона Service Locator. В данном при
мере можно было бы воспользоваться любым количеством стратегий, чтобы
найти, получить экземпляр и возвратить объекты от имени клиентского кода.
Но истинная причина, по которой шаблон Service Locator нередко вызывает
подозрения, заключается в том, что определитель служб должен вызываться в
компоненте явным образом. Такой подход кажется несколько глобальным, а ведь
разработчики объектно-ориентированных приложений с большим подозрением
относятся ко всему глобальному.

Проблема
Всякий раз, когда выполняется операция new, закрывается возможность для
полиморфизма в данной области видимости. Рассмотрим в качестве примера
следующий метод, в котором применяется жестко закодированный объект типа
BloggsApptEncoder:

284

ЧАСТЬ III ® ШАБЛОНЫ

// Листинг 09.37

class AppointmentMaker
{
public function makeAppointment()

{
$encoder = new BloggsApptEncoder() ;
return $encoder->encode();
}

}

Этого может оказаться достаточно для первоначальных потребностей, но пе
рейти к любой другой реализации класса ApptEncoder во время выполнения
программы все же не удастся. Тем самым ограничиваются возможности приме
нения данного класса и затрудняется его тестирование. Преодолению именно
такой негибкости и посвящена большая часть этой главы. Но, как отмечалось
вскользь в предыдущем разделе, экземпляр должен быть получен в каком-то
другом месте, несмотря на применение шаблона Prototype или Abstract
Factory. Ниже приведен еще один фрагмент кода, где объект создается по ша
блону Prototype.
// Листинг 09.32

$factory = new TerrainFactory(
new EarthSea(),
EarthPlains() ,
new EarthForest()
) ;

Обращение к классу TerrainFactory — это шаг в правильном направле
нии. Для получения его экземпляра требуются обобщенные типы Sea, Plains и
Forest. Этот класс предоставляет клиентскому коду самостоятельно выбирать,
какую именно его реализацию следует предоставить. Но как это сделать?

Реализация
В большей части рассматриваемого здесь кода требуется обращение к фа
брикам. И, как было показано ранее, именно такая модель называется шабло
ном Service Locator, по которому метод делегирует поставщику, которому он
вполне доверяет, обязанность найти и обслужить требующийся тип данных. Со
всем иначе дело обстоит в примере применения шаблона Prototype, где просто
ожидается, что во время вызова в коде получения экземпляра будут предостав
лены соответствующие реализации. И в этом нет ничего необычного, посколь
ку нужно лишь указать требующиеся типы данных в сигнатуре конструктора
вместо того, чтобы создавать их в самом методе. А иначе можно предоставить
методы установки, чтобы клиенты смогли передать объекты, прежде чем вызы
вать метод, в котором они применяются.
Внесем следующие коррективы в класс AppointmentMaker:

ГЛАВА 9 » ФОРМИРОВАНИЕ ОБЪЕКТОВ

285

// Листинг 09.38
class AppointmentMaker2

{
private $encoder;
public function __ construct(ApptEncoder $encoder)
$this->encoder = $encoder;

{

}

public function makeAppointment()

{
return $this->encoder->encode();
}
}

Итак, мы добились искомой гибкости благодаря тому, что класс
AppointmentMaker2 вернул управление — объект типа BloggsApptEncoder
в нем больше не создается. Но каким же образом действует логика создания
объектов и где находятся внушающие трепет операторы new? Для выполнения
этих обязанностей потребуется компонент-сборщик. Как правило, с этой целью
применяется файл конфигурации, где определяются конкретные реализации для
получения экземпляров. И хотя здесь можно было бы воспользоваться вспомо
гательными инструментальными средствами, данная книга посвящена тому, как
выходить из подобных затруднительных положений самостоятельно. Поэтому
попробуем сначала создать весьма прямолинейную реализацию, начав с неза
мысловатого файла конфигурации формата XML, где описываются отношения
между классами в проектируемой системе и конкретные типы данных, которые
должны быть переданы их конструкторам.

Здесь описаны два класса, TerrainFactory и AppointmentMaker2, упоми
наемые в этой главе. Нам требуется, чтобы экземпляр класса TerrainFactory
был получен с помощью объектов типа EarthSea, Mars Plains и EarthForest
и чтобы классу AppointmentMaker2 был передан объект типа BloggsApptEn
coder.
Ниже приведен очень простой пример класса сборщика, читающего данные
конфигурации и получающего экземпляры объектов по требованию.

286

ЧАСТЬ III ■ ШАБЛОНЫ

// Листинг 09.39
class ObjectAssembler
{

private $components =

[];

public function __ construct(string $conf)
{

$this->configure($conf);
}

private function configure(string $conf)
{

$data = simplexml_load_file($conf);
foreach ($data->class as $class) {
$args = [];
$name = (string)$class['name’];
foreach ($class->arg as $arg) {
$argclass = (string)$arg[’inst;
$args[(int)$arg[’num’]] = $argclass;

}
ksort($args);
$this->components[$name] =
function () use ($name, $args)
Sexpandedargs = [];
foreach ($args as $arg) {
$expandedargs[ ] = new $arg();

{

}
$rclass = new \ReflectionClass($name);
return $rclass->newInstanceArgs($expandedargs);

};
}

}
public function getComponent(string $class)
{

if

(! isset($this->components[$class])) {
throw new \Exception("Неизвестный компонент

^class'");

}
$ret = $this->components[$class] () ;
return $ret;
}

}

Это весьма незамысловатая, хотя на первый взгляд и немного трудная для
понимания реализация, поэтому рассмотрим ее вкратце. Основное действие
происходит в методе configure (), которому передается путь к файлу конфи
гурации, полученный из конструктора. Для синтаксического анализа XML-фай
ла конфигурации в нем применяется расширение simplexml. Если в реальном
проекте потребуется более основательная обработка ошибок, то в данном при
мере мы вполне доверяем содержимому анализируемого XML-файла конфигу
рации. Из каждого элемента разметки сначала извлекается полностью

ГЛАВА 9

ФОРМИРОВАНИЕ ОБЪЕКТОВ

287

определенное имя класса, которое сохраняется в переменной $name. Затем из
подчиненных элементов разметки извлекаются аргументы, соответствую
щие именам требуемых отдельных классов. Они сохраняются в массиве $args
и упорядочиваются по значению аргумента XML-разметки num. Полученные в
итоге данные упаковываются в анонимной функции, сохраняемой в свойстве
$ components. В этой функции получается экземпляр запрашиваемого класса
и всех требующихся его объектов, и поэтому она вызывается лишь тогда, ког
да метод getComponent () вызывается с правильным именем класса. Благо
даря этому в классе ObjectAssembler может храниться довольно небольшой
фрагмент собранной информации. Обратите внимание на применение замыка
ния. В частности, анонимная функция получает доступ к переменным $name и
$args, объявленным в области видимости при ее создании, благодаря употре
блению ключевого слова use.
Это, конечно, экспериментальный код. Помимо усовершенствованной обра
ботки ошибок, для надежной его реализации придется учесть, что самим объ
ектам, внедряемым в компонент, могут потребоваться аргументы. А возможно,
придется решать и вопросы кеширования. Например, следует ли получать эк
земпляр объекта при каждом вызове или только один раз?
НА ЗАМЕТКУ. Если вы собираетесь создать сборщик/контейнер по шаблону Dependency
injection, рассмотрите следующие возможные средства: Pimple и Symfony DI. Под
робнее о контейнере Pimple можно узнать по адресу http: / /pimple, sensiolabs.
огд/, а о компоненте Symfony DI — по адресу http://symfony.com/doc/
current/components/dependency inj ection/introduction. html.

Как бы там ни было, но гибкость компонентов можно все же сохранить,
организуя получение экземпляров в динамическом режиме. Опробуем класс
ObjectAssembler в следующем примере кода:
// Листинг 09.40

$assembler = new ObjectAssembler("objects.xml”);
$apptmaker - $assembler->getComponent("AppointmentMaker2");
$out = $apptmaker->makeAppointment();
print $out;

При наличии класса ObjectAssembler для получения экземпляра объекта
достаточно единственного оператора. Теперь класс AppointmentMaker2 сво
боден от прежней жестко закодированной зависимости от экземпляра класса
ApptEncoder. А разработчик может воспользоваться файлом конфигурации,
чтобы проконтролировать те классы, которые применяются во время выполне
ния, а также протестировать класс AppointmentMaker2 отдельно от остальной
системы в более обширном контексте.

288

ЧАСТЬ III

ШАБЛОНЫ

Выводы
Мы рассмотрели две возможности создания объектов. С одной стороны,
класс AppConfig послужил примером применения шаблона Service Locator,
предоставляя возможность обнаруживать компоненты или службы от имени его
клиента. Безусловно, внедрение зависимости способствует написанию более из
ящного кода. Так, в классе AppointmentMaker2 ничего неизвестно о страте
гиях создания объектов. Он просто выполняет свои обязанности, что, конечно,
идеально для любого класса. Мы стремимся проектировать классы, способные
сосредоточиваться на своих обязанностях в как можно большей степени обосо
бленно от остальной системы. Но такая чистота не достигается бесплатно, по
скольку для этой цели требуется отдельный компонент сборщика, выполняющий
все необходимые действия. Его можно рассматривать в качестве “черного ящи
ка”, доверяя ему создавать объекты как по волшебству от нашего имени. И если
такое волшебство действует исправно, то нас это вполне устраивает. Но в то же
время будет нелегко отладить неожиданное поведение такого “черного ящика”.
А с другой стороны, шаблон Service Locator проще, хотя он вынужда
ет встраивать компоненты в остальную систему. Впрочем, шаблон Service
Locator не затрудняет тестирование и не делает систему негибкой, если он
применяется должным образом. Определитель служб по шаблону Service
Locator можно настроить на обслуживание произвольных компонентов для це
лей тестирования или в соответствии с заданной конфигурацией. Но жестко за
кодированный вызов определителя служб делает компонент зависимым от него.
А поскольку такой вызов делается в теле метода, то взаимосвязь клиентского
кода с целевым компонентом, предоставляемым по шаблону Service Locator,
оказывается в какой-то степени скрытой. Ведь такая взаимосвязь объявляется в
сигнатуре метода конструктора.
Какой же подход лучше выбрать? В какой-то мере это дело личных предпо
чтений. Я лично предпочитаю начинать с простейшего решения, постепенно
усложняя его по мере надобности. Именно поэтому я обычно выбираю шаблон
Service Locator, создаю класс по шаблону Registry (Реестр) в нескольких
строках кода и затем повышаю его гибкость в соответствии с конкретными тре
бованиями. Разрабатываемые мной компоненты осведомлены друг о друге чуть
больше, чем мне бы хотелось, но поскольку я редко переношу классы из одной
системы в другую, то не особенно страдаю от эффекта встраивания. Переме
стив системный класс в отдельную библиотеку, я, например, не обнаружил ни
каких трудностей в устранении зависимости, возникшей по шаблону Service
Locator.
Шаблон Dependency Injection обеспечивает чистоту, но он требует опре
деленного рода встраивания и вынуждает полагаться на сборщика. Если вы
пользуетесь каркасом, где подобные функциональные возможности уже предо
ставляются, вам вряд ли стоит отказываться от его услуг. Например, компонент
Symfony DI предоставляет гибридное решение по шаблонам Service Locator

ГЛАВА 9 * ФОРМИРОВАНИЕ ОБЪЕКТОВ

289

и Dependency Injection, где первый из них служит в качестве контейнера
службы, который организует формирование экземпляров объектов в соответ
ствии с заданной конфигурацией (или кодом, если угодно) и предоставляет
клиентам интерфейс для получения этих объектов. Такой контейнер службы
допускает даже пользоваться фабриками для создания объектов. Но если вы
предпочитаете пользоваться только своими разработками или же компонентами
из различных каркасов, то, возможно, пожелаете упростить дело, хотя и за счет
некоторого изящества.

Резюме
В этой главе мы рассмотрели ряд приемов, которыми вы можете воспользо
ваться для формирования объектов. Сначала мы рассмотрели шаблон Singleton,
предоставляющий глобальный доступ к единственному экземпляру объекта, а
затем шаблон Factory Method, в котором для формирования объектов при
меняется принцип полиморфизма. Далее мы исследовали сочетание шаблонов
Factory Method и Abstract Factory для формирования классов производи
телей, которые получают экземпляры наборов связанных объектов. Кроме того,
мы рассмотрели шаблон Prototype и показали, каким образом клонирование
объектов позволяет воспользоваться композицией для формирования объектов.
И, наконец, обсудили две стратегии создания объектов по шаблонам Service
Locator и Dependency Injection.

ГЛАВА 10
1М

Шаблоны для
программирования
гибких объектов
После исследования стратегии формирования объектов можно рассмотреть
ряд стратегий структурирования классов и объектов. В этой главе мы, в частно
сти, уделим основное внимание принципу, согласно которому композиция пре
доставляет большую гибкость, чем наследование. Исследуемые здесь шаблоны
снова взяты из каталога “Банды четырех”.
В этой главе мы рассмотрим следующие вопросы.
в Шаблон Composite. Создание структур, в которых группы объектов мож
но использовать так, как будто это отдельные объекты.

1 Шаблон Decorator. Гибкий механизм комбинирования объектов во время
выполнения программы для расширения функциональных возможностей.

Шаблон Facade. Создание простого интерфейса для сложных или изме
няющихся систем.

Структурирование классов для
повышения гибкости объектов
Как пояснялось в главе 4, “Расширенные средства”, начинающие программи
сты часто путают объекты и классы, а остальные — время от времени чешут в
недоумении затылки, разглядывая диаграммы классов на языке UML и пытаясь
согласовать статичные структуры наследования с динамическими отношениями,
в которые могут вступать объекты.
Помните принцип действия шаблонов “Предпочитайте композицию на
следованию”? В нем подчеркивается напряженность, возникающая между

292

ЧАСТЬ III Ж ШАБЛОНЫ

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

Шаблон Composite
Шаблон Composite (Компоновщик) — это, вероятно, самый крайний пример
наследования, которое применяется для обслуживания композиции. У этого ша
блона простая, но удивительно изящная конструкция. И вместе с тем он очень
полезен. Но имейте в виду: из-за всех этих преимуществ у вас может возник
нуть искушение слишком часто пользоваться им.
Шаблон Composite — это простой способ сначала объединить группы по
хожих объектов, а затем и управлять ими. В итоге отдельный объект для кли
ентского кода становится неотличимым от коллекции объектов. На самом деле
это очень простой шаблон, хотя и нередко вводящий в заблуждение. Объясня
ется это, в частности, простой структурой классов по данному шаблону для
организации его объектов. Иерархии наследования представляют собой деревья,
корнем которых является суперкласс, а ветвями — специализированные под
классы. Иерархическое дерево наследования классов, построенное по шаблону
Composite, предназначено для того, чтобы упростить формирование объектов
и их обход по дереву.
Если вы еще не знакомы с этим шаблоном, то можете теперь почувствовать
некоторое замешательство. Обратимся к аналогии, чтобы проиллюстрировать,
каким образом отдельные объекты можно трактовать как коллекции предметов.
Имея такие ингредиенты, как крупа и мясо (или соя, в зависимости от пред
почтений), можно произвести пищевой продукт, например колбасу. И тогда с
полученным результатом можно обращаться, как с единой сущностью. Подоб
но мясу, мы можем покупать, готовить и есть колбасу, одним из ингредиентов
которой является мясо. Мы можем сочетать колбасу с другими ингредиентами,
чтобы приготовить пиццу, тем самым включив одну составную часть в другую,
более крупную. Таким образом, мы обращаемся с коллекциями таким же обра
зом, как и с их составными частями. Шаблон Composite помогает моделиро
вать отношение между коллекциями и компонентами в прикладном коде.

Проблема
Управление группами объектов может быть довольно сложной задачей, осо
бенно если эти объекты содержат также собственные объекты. Это очень рас
пространенная проблема в программировании. Представьте счет-фактуру, где

ГЛАВА 10 В ШАБЛОНЫ ДЛЯ ПРОГРАММИРОВАНИЯ ГИБКИХ ОБЪЕКТОВ

293

указаны дополнительные товары или услуги, или список назначенных для вы
полнения дел, где элементы сами содержат несколько подзадач. Управляя со
держимым, можно оперировать деревьями подразделов, страниц, статей и муль
тимедийных компонентов. Но внешнее управление этими структурами может
быстро превратиться в очень сложную задачу.
Вернемся к сценарию, описанному в предыдущей главе. Напомним, что мы
проектируем систему на основе игры “Цивилизация”. Игрок может передвигать
элементы по сотням клеток на игровом поле, которые составляют карту. При
этом отдельные объекты можно группировать, чтобы перемещаться, сражаться
и защищаться так, как будто это единый элемент. Определим пару типов боевых
единиц (так называемых юнитов).
// Листинг 10.01

abstract class Unit
{

abstract public function bombardstrength () : int;
}

class Archer extends Unit
{
public function bombardstrength () : int

{
return 4;
}
}

class LaserCannonUnit extends Unit
{

public function bombardstrength () : int
{

return 44;
}
}

В классе Unit определен абстрактный метод bombardstrength (), где за
дается атакующая сила юнита, обстреливающего соседнюю клетку. Этот метод
реализуется в классах Archer и LaserCannonUnit, которые могут также содер
жать сведения о перемещении и возможностях защиты. Но остановимся пока на
самом простом варианте. Мы можем определить отдельный класс для группиро
вания юнитов следующим образом:
// Листинг 10.02
class Army

{
private $units = [];
public function addUnit(Unit $unit)
{

array push($this->units,

$unit);

294

ЧАСТЬ III SS ШАБЛОНЫ

public function bombardstrength () : int
{

$ret = 0;
foreach ($this->units as $unit) {
$ret += $unit->bombardStrength();
}
return $ret;
}
}

// Листинг 10.03
$unitl = new ArcherO;
$unit2 = new LaserCannonUnit ();
$army = new Army () ;
$army->addUnit($unitl);
$army->addUnit($unit2) ;
print $army->bombardStrength();

У класса Army имеется метод addUnit (), которому передается объект типа
Unit. Объекты типа Unit сохраняются в массиве свойств $units. Мы вычисля
ем объединенную силу нашей армии в методе bombardstrength (). Для этого
перебираются объединенные объекты типа Unit и для каждого из них вызыва
ется метод bombardstrength().
Такая модель оказывается идеальной до тех пор, пока задача остается на
столько простой. Но что будет, если мы введем ряд новых требований? Допу
стим, что одна армия должна быть способна объединяться с другими армиями.
При этом каждая армия должна сохранять свою индивидуальность, чтобы впо
следствии она могла выйти из более крупного соединения. Сегодня у храбрых
вояк эрцгерцога может быть общая с генералом Соамсом причина атаковать не
защищенный фланг армии врага, но восстание у себя на родине может заставить
его армию в любой момент поспешить домой. Поэтому мы не можем просто
переместить подразделения из каждой армии в новое воинское соединение.
Сначала мы можем внести коррективы в класс Army таким образом, чтобы
оперировать в нем как объектами типа Army, так и типа Unit.
// Листинг 10.04

public function addArmy(Army $army)
{
array_push($this->armies, $army);
}

Затем нужно внести приведенные ниже изменения в метод bombaгdStrength (), чтобы производить перебор по всем армиям и объектам типа Unit.

ГЛАВА 10 » ШАБЛОНЫ ДЛЯ ПРОГРАММИРОВАНИЯ ГИБКИХ ОБЪЕКТОВ

295

// Листинг 10.05
public function bombardstrength(): int

{
$ret = 0;
foreach ($this->units as $unit) {
$ret 4-= $unit->bombardStrength () ;
}
foreach ($this->armies as $army) {
$ret += $army->bombardStrength();

}
return $ret;

}

Дополнительная сложность в данный момент не представляет особых трудно
стей. Но помните, что мы должны сделать нечто подобное и с другими методами,
определяющими, например, защитную силу в методе defensivestrength(),
диапазон перемещения в методе movementRange () и т.д. Рассматриваемая
здесь игра обещает быть функционально богатой. Командование уже вызывает
военно-транспортные самолеты, которые могут вмещать до десяти юнитов, что
бы быстро перебросить войска и улучшить свои позиции в некоторых районах.
Очевидно, что военно-транспортный самолет подобен армии в том отношении,
что в нем группируются объекты типа Unit. Но у него могут быть и свои ха
рактеристики. Мы можем снова внести коррективы в класс Army, чтобы управ
лять военно-транспортными самолетами (объектами типа TroopCarrier). Но
ведь может появиться необходимость и в других типах группирования объектов
типа Unit. Очевидно, что для этой цели нам потребуется более гибкая модель.
Рассмотрим еще раз модель, которую мы создаем. Всем созданным ранее
классам требуется метод bombardStrength (). В действительности клиентско
му коду не нужно различать армию, юнит или военно-транспортный самолет,
поскольку они функционально идентичны, т.е. должны уметь перемещаться,
атаковать и защищаться. А одним объектам, которые содержат другие объекты,
требуются методы добавления и удаления. И эти сходные черты приводят нас
к неизбежному выводу: объекты-контейнеры имеют общий интерфейс с объек
тами, которые они содержат, и поэтому они должны, что вполне естественно,
относиться к одному семейству типов.

Реализация
В шаблоне Composite определяется единственная иерархия наследования,
которая устанавливает два различных набора функциональных обязанностей.
Мы их уже видели в рассматриваемом здесь примере. Классы по этому шабло
ну должны поддерживать общий набор операций как основную обязанность,
и в данном случае это метод bombardstrength (), а также методы для добав
ления и удаления объектов.
На рис. 10.1 показана диаграмма класса, наглядно демонстрирующая приме
нение шаблона Composite для решения рассматриваемой здесь задачи.

296

ЧАСТЬ III ж ШАБЛОНЫ

Рис. 10.1. Шаблон Composite в действии

Как видите, все элементы рассматриваемой здесь модели являются произво
дными от класса Unit. Поэтому клиентский код может быть уверен, что любой
объект типа Unit будет поддерживать метод bombardstrength (). А это озна
чает, что с объектом типа Army можно обращаться таким же образом, как и с
объектом типа Archer.
Классы Army и TroopCarrier относятся к составным типам данных и
предназначены для того, чтобы содержать объекты типа Unit. Классы Archer
и LaserCannon относятся к листьям, предназначенным для поддержки опера
ций над объектами типа Unit. В них не могут содержаться другие объекты
типа Unit. И здесь возникает вопрос: должны ли листья подчиняться тому же
интерфейсу, что и составные типы, как показано на диаграмме, приведенной
на рис. 10.1? Как следует из этой диаграммы, в классах TroopCarrier и Army
агрегируются другие объекты типа Unit, хотя в классах листьев необходимо
также реализовать метод addUnit (). Мы еще вернемся к данному вопросу, а
до тех пор определим абстрактный класс Unit.
// Листинг 10.06

abstract class Unit
{
abstract public function addUnit(Unit $unit);
abstract public function removeUnit(Unit $unit);
abstract public function bombardstrength () : int;
}

Как видите, мы определили основные функции для всех объектов типа Unit.
А теперь покажем, как реализовать эти абстрактные методы в составном объ
екте.
// Листинг 10.07
class Army extends Unit

{
private $units = [];

ГЛАВА 10 Я ШАБЛОНЫ ДЛЯ ПРОГРАММИРОВАНИЯ ГИБКИХ ОБЪЕКТОВ

297

public function addUnit(Unit $unit)
{
if (in_array($unit,
return;

$this->units, true))

{

}
$this->units [ ] = $unit;

}
public function removeUnit(Unit $unit)

{
$idx = array_search($unit, $this->units, true);
if (is_int($idx)) {
array_splice($this->units, $idx, 1, []);
}
}

public function bombardstrength () : int

{
$ret = 0;
foreach ($this->units as $unit) {
$ret += $unit->bombardStrength();
}
return $ret;

}
}

Объект типа Unit, переданный методу addUnit () в качестве параметра, со
храняется в закрытом массиве свойств $units. Перед этим проверяется, чтобы
в массиве $units не было дубликатов объектов типа Unit. Аналогичная про
верка производится и в методе removeUnit (), и если объект типа Unit обна
ружен, то он удаляется из закрытого массива свойств $units.
В объектах типа Army могут храниться ссылки на любые объекты типа
Unit, включая другие объекты типа Army, а также листья типа Archer или
LaserCannonUnit. Метод bombardstrength () гарантированно поддерживает
ся во всех объектах типа Unit, и поэтому в методе Army::bombardstrength ()
перебираются все дочерние объекты типа Unit, сохраненные в свойстве $units,
и для каждого из них вызывается один и тот же метод.
У шаблона Composite имеется один серьезный недостаток: реализация
функций добавления и удаления элементов. В классическом шаблоне методы
add () и remove () размещаются в абстрактном суперклассе. Этим гарантиру
ется, что во всех классах шаблона совместно используется общий интерфейс.
Но, как показано ниже, это также означает, что в классах листьев необходимо
обеспечить его реализацию.
// Листинг 10.08
class UnitException extends \Exception

298

ЧАСТЬ III » ШАБЛОНЫ

// Листинг 10.09

class Archer extends Unit

I
public function addUnit(Unit Sunit)
{
throw new UnitException(get_class($this)
. ” относится к листьям”);

}
public function removeUnit(Unit $unit)
{

throw new UnitException(get_class($this)
. " относится к листьям”);
}

public function bombardstrength (): int
{
return 4;
}
}

Нам не требуется возможность вводить объект типа Unit в объект типа
Archer, поэтому при вызове метода addUnit () или removeUnit () генерирует
ся исключение. А поскольку это придется сделать для всех объектов листьев, то
проектное решение можно улучшить, заменив абстрактные методы addUnit ()
и removeUnit () в объекте типа Unit стандартными реализациями, как в пре
дыдущем примере.
// Листинг 10.10
abstract class Unit
(
public function addUnit(Unit $unit)
{
throw new UnitException(get_class($this)
. ” относится к листьям");
}

public function removeUnit(Unit $unit)
{
throw new UnitException(get_class($this)
. " относится к листьям");
}
abstract public function bombardstrength(): int;

// Листинг 10.11

class Archer extends Unit
{
public function bombardstrength (): int
{
return 4;
}

ГЛАВА 10

ШАБЛОНЫ ДЛЯ ПРОГРАММИРОВАНИЯ ГИБКИХ ОБЪЕКТОВ

299

Такой подход позволяет избавиться от дублирования кода в классах ли
стьях. Но у него имеется серьезный недостаток: класс составного типа не
обязан обеспечивать во время компиляции реализацию методов addUnit () и
removeUnit (), что в конечном итоге может вызвать осложнения.
Некоторые недостатки шаблона Composite мы рассмотрим подробнее в сле
дующем разделе. А этот раздел завершим, перечислив преимущества данного
шаблона.
ж Гибкость. Во всех элементах шаблона Composite используется общий
супертип, что заметно упрощает ввод новых объектов составного типа
или листьев в проектное решение, не меняя более обширный контекст
программы.
$ Простота. Клиентский код, использующий структуру шаблона
Composite, имеет простой интерфейс. Клиентскому коду не нужно про
водить различие между объектом, состоящим из других объектов, и объек
том листа, за исключением случая добавления новых компонентов. Вызов
метода Army: :bombardstrength () может стать причиной серии деле
гированных внутренних вызовов, но для клиентского кода процесс и ре
зультат оказываются точно такими же, как и при вызове метода Archer: :
bombardstrength().

st Неявная досягаемость. В шаблоне Composite объекты организованы в
древовидную структуру. В каждом составном объекте содержатся ссылки
на дочерний объект. Поэтому операция над определенной частью дерева
может иметь более обширный эффект. В частности, можно удалить один
объект типа Army из его родительского объекта типа Army и добавить к
другому объекту типа Army. Это простое действие выполняется над одним
объектом, но в конечном итоге изменяется состояние всех объектов типа
Unit, на которые ссылается объект типа Army, а также состояние их до
черних объектов.

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

Как правило, увидеть реальное проявление преимуществ шаблона Composite
можно только в клиентском коде, поэтому создадим пару армий.
// Листинг 10.12
// создать армию
$main_army = new Army();

// ввести пару боевых единиц
$main_army->addUnit( new ArcherO );
$main_army->addUnit ( new LaserCannonUnit ()

);

300

ЧАСТЬ III ts ШАБЛОНЫ

// создать еще одну армию
$sub_army = new Army();
// ввестинесколько
$sub_army->addUnit(
$sub_army->addUnit(
$sub_army->addUnit(

боевых единиц
new Archer() );
new ArcherO );
new ArcherO );

// добавить вторую армию к первой
$main_army->addUnit( $sub_army );

// Все вычисления выполняются подспудно
print ” Атакующая сила: {$main_army->bombardStrength()}\п";

В данном примере создается новый объект типа Army и в него вводится не
сколько боевых единиц типа Unit. Этот процесс повторяется для второго объек
та типа Army, который затем добавляется к первому объекту. Когда вызывается
метод Unit: : bombardstrength () для первого объекта типа Army, вся слож
ность построенной структуры оказывается полностью скрытой.

Выводы
Если вы в чем-то похожи на меня, то, увидев фрагмент исходного кода из
класса Archer, должны были сильно призадуматься. Для чего нужны лишние
методы addUnit () и removeUnit () в классах листьев, которые по логике вещей
не должны в них поддерживаться? Ответ заключается в прозрачности типа Unit.
Если клиентский код оперирует объектом типа Unit, то ему известно, что
метод addUnit () всегда присутствует. В результате выполняется принцип дей
ствия шаблона Composite, который заключается в том, что у примитивных
классов (листьев) должен быть такой же интерфейс, как и у составных классов.
Хотя это не особенно помогает, потому что мы по-прежнему не знаем, насколь
ко безопасно вызывать метод addUnit () для любого объекта типа Unit, с ко
торым мы можем столкнуться.
Если переместить эти методы добавления и удаления вниз по иерархии клас
сов, чтобы они были доступны только в классах составного типа, то при пере
даче объекта типа Unit методу возникает затруднение из-за того, что исходно
нам неизвестно, поддерживает ли он метод addUnit () или нет. Тем не менее
оставлять методы-заглушки в классах листьев кажется неправильным. Пользы
от этого никакой, а проект усложняется, поскольку интерфейс дает ложные све
дения о собственных функциональных возможностях.
Классы составного типа можно легко разделить на подтипы CompositeUnit.
Прежде всего исключим методы добавления и удаления юнитов из класса Unit.
// Листинг 10.13
abstract class Unit
{
public function getCompositeО

ГЛАВА 10 я ШАБЛОНЫ ДЛЯ ПРОГРАММИРОВАНИЯ ГИБКИХ ОБЪЕКТОВ

301

return null;
}
abstract public function bombardstrength () : int;

}

Обратите внимание на новый метод getComposite (). Мы еще вернемся к
нему некоторое время спустя. А до тех пор нам потребуется новый абстрактный
класс, в котором будут поддерживаться методы addUnit () и removeUnit ().
Мы можем обеспечить даже его стандартные реализации.
// Листинг 10.14
abstract class CompositeUnit extends Unit

{
private $units = [];
public function getComposite () : CompositeUnit
{

return $this;
}

public function addUnit(Unit $unit)

{
if (in_array($unit,
return;

$this->units,

true))

{

}
$this->units [ ] = $unit;
}

public function removeUnit(Unit $unit)

{
$idx = array_search($unit, $this->units, true);
if (is_int($idx)) {
array_splice($this->units, $idx, 1, []);
}

}
public function getUnits(): array
{

return $this->units;
}

}

Класс CompositeUnit объявлен абстрактным, несмотря на то, что в нем не
определено никаких абстрактных методов. Тем не менее он расширяет класс
Unit и в нем не реализован абстрактный метод bombardstrength (). Класс
Army и любые другие классы составного типа теперь могут расширять класс
CompositeUnit. Классы в рассматриваемом здесь примере теперь организова
ны, как показано на рис. 10.2.

302

ЧАСТЬ III

ШАБЛОНЫ

Рис. 10-2. Перемещение методов добавления и уда
ления юнитов из базового класса в отдельный класс

Итак, мы избавились от бесполезной реализации методов добавления и
удаления юнитов в классах листьев, но в клиентском коде перед вызовом ме
тода addUnit() теперь приходится проверять, относится ли объект к типу
CompositeUnit. Именно здесь и вступает в свои права метод getComposite ().
По умолчанию этот метод возвращает пустое значение. Только в классе
CompositeUnit он возвращает ссылку на объект типа CompositeUnit. Поэто
му если в результате вызова данного метода возвращается объект, у нас должна
появиться возможность вызвать для него метод addUnit (). Ниже показано, как
этим приемом можно воспользоваться в клиентском коде.
// Листинг 10.15
class UnitScript
{

public static function joinExisting(
Unit $newUnit,
Unit $occupyingUnit
) : CompositeUnit {
$comp = $occupyingUnit->getComposite();
if ( ! is_null($comp)) {
$comp->addUnit(SnewUnit);
} else {
$comp = new Army () ;
$comp->addUnit($occupyingUnit);
$comp->addUnit($newUnit) ;
}
return $comp;

ГЛАВА 10 в ШАБЛОНЫ ДЛЯ ПРОГРАММИРОВАНИЯ ГИБКИХ ОБЪЕКТОВ

303

Методу joinExisting () передаются два объекта типа Unit. Первый из
них — это объект, вновь прибывший на клетку, а второй — объект, занимав
ший клетку до этого. Если второй объект типа Unit принадлежит к классу
CompositeUnit, то первый объект попытается присоединиться к нему. В про
тивном случае будет создан новый объект типа Army, включающий в себя оба
объекта типа Unit. А поначалу мы никак не сможем выяснить, содержит ли
аргумент $occupyingUnit объект класса CompositeUnit. Но вызов мето
да getComposite () позволит разрешить данное затруднение. Если метод
getComposite () возвращает объект, мы можем непосредственно ввести в него
новый объект типа Unit. В противном случае мы создадим новый объект типа
Army и введем в него оба объекта.
С одной стороны, данную модель можно еще больше упростить, сделав так,
чтобы метод Unit: : getComposite () возвратил объект типа Army, содержащий
текущий объект типа Unit. А с другой стороны, можно вернуться к предыдущей
модели, где не было структурного разделения между объектами составного типа
и листьями, а метод Unit: :addUnit () делает то же самое, создавая объект
типа Army и вводя в него оба объекта типа Unit. Это понятно, когда предпо
лагается, что заранее известен составной тип, который требуется использовать
для объединения боевых единиц типа Unit. Предположения, которые предстоит
сделать при проектировании таких методов, как getComposite () и addUnit (),
будут определяться логикой разрабатываемого приложения.
Подобные перекосы свидетельствуют о недостатках шаблона Composite.
Простота достигается благодаря гарантии, что все классы происходят от обще
го базового класса. Но за простоту иногда приходится платить безопасностью
использования типа данных. Чем сложнее становится модель, тем больше ве
роятность, что проверку типов придется делать вручную. Предположим, у нас
имеется объект типа Cavalry (кавалерия). Если по правилам рассматриваемой
здесь игры лошади нельзя перемещать на бронетранспортере, то сделать это
автоматически по шаблону Composite не удастся.
// Листинг 10.16
class TroopCarrier extends CompositeUnit

{
public function addUnit(Unit $unit)

{

if ($unit instanceof Cavalry) {
throw new UnitException (
"Нельзя перемещать лошадь на бронетранспортере.");
}
parent::addUnit($unit);

}
public function bombardstrength () : int

{
return 0;

}
}

304

ЧАСТЬ III s ШАБЛОНЫ

Здесь мы обязаны воспользоваться операцией instanceof, чтобы проверить
тип объекта, переданного методу addUnit (). Такого рода случаев существует
слишком много, поэтому недостатки шаблона Composite начинают перевеши
вать его преимущества. Шаблон Composite наиболее эффективен, когда боль
шинство компонентов являются взаимозаменяемыми.
Еще один вопрос, о котором не следует забывать, имеет отношение к за
тратности некоторых операций, выполняемых по шаблону Composite. Харак
терным тому примером служит метод Army: :bombardstrength (), иницииру
ющий целый ряд вызовов одного и того же метода вниз по иерархическому
дереву. Для крупного иерархического дерева с множеством вложенных армий
единственный вызов может стать причиной целой лавины внутренних вызовов.
Метод bombardstrength () сам по себе не является слишком затратным, но
что произойдет, если в некоторых листьях дерева должны выполняться сложные
вычисления для получения возвращаемых значений? Этот вопрос можно раз
решить, сохранив результат вызова подобного метода в родительском объекте,
чтобы последующие вызовы не были столь затратными. Но здесь следует про
явить особое внимание, следя за тем, чтобы сохраненное значение не устарело.
Необходимо выработать стратегии удаления всех сохраненных значений, когда
в иерархическом дереве выполняются какие-нибудь операции. Для этого, воз
можно, придется предоставить дочерним объектам ссылки на их родительские
объекты.
И, наконец, сделаем замечание по поводу сохраняемости. Шаблон Composite
довольно изящен, но не слишком пригоден для сохранения в реляционной базе
данных. Причина в том, что по умолчанию обращение ко всей структуре проис
ходит только по целому ряду ссылок. Поэтому придется сделать немало затрат
ных запросов к базе данных, чтобы построить естественным образом структуру
по шаблону Composite. Эту задачу можно решить, присвоив идентификатор
всему иерархическому дереву, чтобы все компоненты можно было сразу извлечь
из базы данных. Но даже получив все нужные объекты, все равно придется вос
создавать ссылки типа “родитель-потомок”, которые, в свою очередь, должны
сохраняться в базе данных. Это несложное, но довольно хлопотное занятие.
Как упоминалось ранее, составные объекты нелегко сохранять в реляцион
ной базе данных, но в то же время они отлично подходят для сохранения в
формате XML. Эго объясняется тем, что элементы XML-разметки, как правило,
сами состоят из деревьев вложенных элементов.

Краткие ВЫВОДЫ по шаблону Composite
Шаблон Composite оказывается полезным, когда требуется обращаться
с коллекцией объектов таким же образом, как и с отдельным объектом, или
потому, что такая коллекция, по существу, такая же, как и компонент (напри
мер, армии и лучники), или же потому, что контекст придает коллекции такие
же характеристики, как и у компонента (например, позиции в счете-фактуре).

ГЛАВА 10 s ШАБЛОНЫ ДЛЯ ПРОГРАММИРОВАНИЯ ГИБКИХ ОБЪЕКТОВ

305

Составные объекты, создаваемые по шаблону Composite, организованы в виде
иерархических деревьев, и поэтому операция над целым деревом может затро
нуть отдельные его части, где данные явно доступны для всего дерева. Шаблон
Composite делает такие операции и запросы прозрачными для клиентского
кода. К тому же иерархические деревья легко обходить, как будет показано в
следующей главе. Структуры, созданные по шаблону Composite, нетрудно до
полнить новыми типами компонентов.
Недостаток шаблона Composite заключается в том, что составные объекты
зависят от сходства их частей. Стоит лишь ввести сложные правила, опреде
ляющие, какие именно компоненты могут содержать составные объекты, как
прикладной код станет трудно управляемым. Составные объекты не совсем под
ходят для сохранения в реляционной базе данных, но в то же время они вполне
пригодны для сохранения в файлах формата XML.

Шаблон Decorator
Если шаблон Composite помогает создавать гибкое представление из сово
купности компонентов, то в шаблоне Decorator (Декоратор) применяется сход
ная структура для оказания помощи в видоизменении функциональных возмож
ностей отдельных компонентов. И в этом шаблоне особая роль принадлежит
композиции во время выполнения программы. Наследование — это ясный спо
соб создания объектов по характеристикам, заложенным в родительском классе.
Но такая ясность может привести к жесткому кодированию вариантов в иерар
хиях наследования, что, как правило, становится причиной негибкости.

Проблема
Внедрение всех функциональных возможностей в структуру наследования
может привести к бурному росту количества классов в проектируемой системе.
Хуже того, попытки внести аналогичные изменения в разных ветвях иерархиче
ского дерева наследования, скорее всего, приведут к дублированию.
Вернемся к рассматривавшейся ранее игре, определив класс Tile и его про
изводный тип следующим образом:
// Листинг 10.17

abstract class Tile
{

abstract public function getWealthFactor () : int;
}
// Листинг 10.18

class Plains extends Tile

{
private $wealthfactor = 2;

306

ЧАСТЬ III S8 ШАБЛОНЫ

public function getWealthFactor () :

int

{

return $this->wealthfactor;

}
}

Итак, мы определили класс Tile, представляющий квадратную клетку, в кото
рой могут находиться боевые единицы. У каждой клетки имеются определенные
характеристики. В данном случае мы определили метод getWealthFactor (),
влияющий на доход, который может вырабатывать определенная клетка, если ею
владеет игрок. Как видите, у объектов типа Plains коэффициент благосостояния
равен 2. Но у клеток, конечно, могут быть и другие характеристики. Они могут
также хранить ссылку на сведения об изображении для рисования игрового поля.
Постараемся и в этом случае не усложнять стоящую перед нами задачу.
Нам необходимо видоизменить поведение объекта типа Plains (равнины),
чтобы обрабатывать сведения о природных ресурсах и губительном воздействии
на природу человеческого фактора. В частности, нам требуется смоделировать
месторождение алмазов на местности, а также вред, наносимый загрязнением
окружающей среды. Один из подходов состоит в том, чтобы воспользоваться
наследованием от объекта типа Plains.
// Листинг 10.19

class DiamondPlains extends Plains
{

public function getWealthFactor () : int
{

return parent::getWealthFactor()

+ 2;

}

}
// Листинг 10.20

class PollutedPlains extends Plains
{

public function getWealthFactor () : int
{

return parent::getWealthFactor ()

- 4;

}

}

Теперь можно легко получить загрязненную клетку.
// Листинг 10.21

$tile = new PollutedPlains();
print $tile->getWealthFactor ();

ГЛАВА 10 Ж ШАБЛОНЫ ДЛЯ ПРОГРАММИРОВАНИЯ ГИБКИХ ОБЪЕКТОВ

307

Диаграмма классов для данного примера показана на рис. 10.3.

Рис. 10.3. Построение видоизмененного ва

рианта иерархического дерева наследования

Очевидно, что этой структуре недостает гибкости. Мы можем получить рав
нины с алмазами, а также загрязненные равнины. Но можно ли получить и то
и другое? Очевидно, нет, если только мы не хотим создать нечто ужасное вро
де PollutedDiamondPlains. Ситуация становится еще хуже, когда мы вводим
класс Forest, в котором также могут быть алмазы и загрязнения.
Это, конечно, пример самого крайнего случая, но он наглядно демонстриру
ет суть дела. Если при определении функциональных возможностей полагаться
только на наследование, это приведет к резкому увеличению количества классов
и проявится тенденция к дублированию.
А теперь рассмотрим более общий пример. Серьезным веб-приложениям
обычно требуется выполнить ряд действий после поступления запроса, до того
как инициируется задача для формирования ответа на запрос. Например, нужно
аутентифицировать пользователя и зарегистрировать запрос в системном жур
нале. Вероятно, мы должны как-то обработать запрос, чтобы создать структуру
данных на основе необработанных исходных данных. И, наконец, мы должны
осуществить основную обработку данных. Таким образом, перед нами встала
та же самая задача.
Мы можем расширить функциональные возможности на основе класса
ProcessRequest с дополнительной обработкой в производном классе LogRequest, в классе StructureRequest, а также в классе AuthenticateRequest.
Эта иерархия классов показана на рис. 10.4.
Но что произойдет, если потребуется выполнить регистрацию и аутентифи
кацию, но не подготовку данных? Не создать ли нам класс LogAndAuthenticateProcessor? Очевидно, настало время найти более гибкое решение.

308

ЧАСТЬ III

ШАБЛОНЫ

Рис. 10.4. Дополнительные жестко закодированные вариации

Реализация
Для решения задачи меняющихся функциональных возможностей вместо од
ного только наследования в шаблоне Decorator применяется композиция и де
легирование. По существу, в классах, создаваемых по шаблону Decorator, хра
нится экземпляр другого класса его собственного типа. По шаблону Decorator
реализуется сам процесс выполнения операции и вызывается аналогичная опе
рация над объектом, на который у него имеется ссылка (до или после выполне
ния собственных действий). Таким образом, во время выполнения программы
можно создать конвейер объектов по шаблону Decorator. Чтобы продемон
стрировать это, перепишем рассматриваемый здесь пример игры следующим
образом:
abstract class Tile

{
abstract public function getWealthFactor (): int;
}

class Plains extends Tile
{

private $wealthfactor = 2;
public function getWealthFactor () : int
{

return $this->wealthfactor;

ГЛАВА 10 ® ШАБЛОНЫ ДЛЯ ПРОГРАММИРОВАНИЯ ГИБКИХ ОБЪЕКТОВ

309

// Листинг 10.22
abstract class TileDecorator extends Tile
{

protected $tile;

public function __ construct(Tile $tile)
{

$this->tile = $tile;

}
}

В данном случае мы объявили классы Tile и Plains, как и прежде, но в
то же время ввели новый класс TileDecorator. В нем не реализуется метод
getWealthFactor (), поэтому он должен быть объявлен абстрактным. Кроме
того, мы определили конструктор, которому передается объект типа Tile, а
ссылка на него сохраняется в свойстве $tile. Мы объявили это свойство за
щищенным (protected), чтобы сделать его доступным из дочерних классов.
Переопределим далее классы Pollution и Diamond.
// Листинг 10.23
class DiamondDecorator extends TileDecorator

{
public function getWealthFactor () : int

{
return $this->tile->getWealthFactor () + 2;

}
}
// Листинг 10.24

class PollutionDecorator extends TileDecorator

{
public function getWealthFactor () : int

{
return $this->tile->getWealthFactor () - 4;
}
}

Каждый из этих классов расширяет класс TileDecorator. Это означа
ет, что у них имеется ссылка на объект типа Tile. Когда вызывается метод
getWealthFactor (), каждый из этих классов сначала вызывает такой же ме
тод по ссылке на объект типа Tile, а затем выполняет собственную коррекцию
значения.
Используя композицию и делегирование подобным образом, мы легко можем
комбинировать объекты во время выполнения программы. Все объекты, созда
ваемые по данному шаблону, расширяют класс Tile, поэтому клиентскому коду
совсем не обязательно знать, какой именно комбинацией объектов он оперирует.
Можно быть уверенным, что метод getWealthFactor () доступен для любого

310

ЧАСТЬ III 1 ШАБЛОНЫ

объекта типа Tile, независимо от того, декорирует ли он подспудно другой
объект или нет.
// Листинг 10.25

$tile = new Plains();
print $tile->getWealthFactor(); // выводится значение 2

Класс Plains является компонентом системы, поэтому его конструктор про
сто возвращает значение 2.
// Листинг 10.26
$tile = new DiamondDecorator( new Plains () );
print $tile->getWealthFactor() ; // выводится значение 4

В объекте типа DiamondDecorator хранится ссылка на объект типа
Plains. Перед прибавлением собственного значения 2 он вызывает метод
getWealthFactor () из объекта типа Plains.
// Листинг 10.27

$tile = new PollutionDecorator(new DiamondDecorator( new Plains()
print $tile->getWealthFactor() ; // выводится значение 0

));

В объекте типа PollutionDecorator хранится ссылка на объект типа Dia
mondDecorator, а у того — собственная ссылка на другой объект типа Tile.
Диаграмма классов для данного примера показана на рис. 10.5.

Рис. 10.5. Диаграмма классов по шаблону Decorator

Данную модель очень легко расширять. В нее совсем не трудно добавлять но
вые декораторы и компоненты. Имея в своем распоряжении декораторы, можно

ГЛАВА 10

ШАБЛОНЫ ДЛЯ ПРОГРАММИРОВАНИЯ ГИБКИХ ОБЪЕКТОВ

311

строить очень гибкие структуры во время выполнения. Класс компонентов си
стемы (в данном примере — Plains) можно заметно видоизменить разными
способами, не прибегая к встраиванию всей совокупности видоизменений в ие
рархию классов. Проще говоря, это означает, что можно создать загрязненную
равнину (объект типа Plains) с месторождением алмазов, не создавая объект
типа PollutedDiamondPlains.
По шаблону Decorator строятся конвейеры, очень удобные для создания
фильтров. В пакете java, io языка Java очень эффективно используются классы
декораторов, созданные по шаблону Decorator. Программист, разрабатываю
щий клиентский код, может комбинировать объекты декораторов с основными
компонентами, чтобы внедрить фильтрацию, буферизацию, сжатие и прочие
операции в основные методы вроде read (). В рассматриваемом здесь примере
веб-запрос может быть также преобразован в конфигурируемый конвейер. Ниже
приведен пример простой реализации, где применяется шаблон Decorator.
// Листинг 10.28
class RequestHelper

{
}

// Листинг 10.29
abstract class ProcessRequest

{
abstract public function process(RequestHelper $req);
}

// Листинг 10.30
class MainProcess extends ProcessRequest

{
public function process(RequestHelper $req)
{

print __ CLASS__

.

выполнение запроса \n";

}

}

// Листинг 10.31
abstract class DecorateProcess extends ProcessRequest
{

protected $processrequest;
public function__ construct(ProcessRequest $pr)

{
$this->processrequest = $pr;

312

ЧАСТЬ III Я ШАБЛОНЫ

Как и прежде, мы определяем абстрактный суперкласс (ProcessRequest),
конкретный компонент (MainProcess) и абстрактный декоратор (DecorateProcess). Метод MainProcess::process () не делает ничего, кроме вывода сооб
щения, что он был вызван. В классе DecorateProcess сохраняется ссылка на
объект типа ProcessRequest, указывающая на один из его дочерних объектов.
Ниже приведены примеры простых классов конкретных декораторов.
// Листинг 10.32

class LogRequest extends DecorateProcess
{
public function process(RequestHelper $req)
{
print __ CLASS__ .
регистрация запроса \n”;
$this->processrequest->process($req);
}
}
// Листинг 10.33

class AuthenticateRequest extends DecorateProcess
{
public function process(RequestHelper $req)
{
print __ CLASS__ . ”: аутентификация запроса \n";
$this->processrequest->process($req);
}
}
// Листинг 10.34

class StructureRequest extends DecorateProcess
{
public function process(RequestHelper $req)
{
print __ CLASS__ .
формирование данных запроса \n”;
$this->processrequest->process($req);
}
}

Каждый метод process () выводит сообщение, прежде чем вызвать соб
ственный метод process () объекта типа ProcessRequest, на который дела
ется ссылка. Теперь экземпляры этих классов можно комбинировать во время
выполнения программы, чтобы создавать фильтры, выполняющие различные
действия по запросу, причем в разном порядке. Ниже приведен пример кода
для комбинирования объектов из всех упоминаемых здесь конкретных классов
в одном фильтре.
// Листинг 10.35
$process = new AuthenticateRequest(new StructureRequest(
new LogRequest(new MainProcess()
)
) ) ;
$process->process(new RequestHelper() ) ;

ГЛАВА 10 а ШАБЛОНЫ ДЛЯ ПРОГРАММИРОВАНИЯ ГИБКИХ ОБЪЕКТОВ

313

Выполнение данного фрагмента кода приведет к следующему результату:
AuthenticateRequest: аутентификация запроса
StructureRequest: формирование данных запроса
LogRequest: регистрация запроса
MainProcess: выполнение запроса

НА ЗАМЕТКУ. На самом деле мы привели пример шаблона корпоративных приложений

intercepting Filter. Этот шаблон описан в упоминавшейся ранее книге Core
J2EE Patterns: Best Practices and Design Strategies.

Выводы
Как и шаблон Composite, шаблон Decorator может показаться трудным
для понимания. Важно помнить, что композиция и наследование вступают в
действие одновременно. Поэтому класс LogRequest наследует свой интерфейс
от класса ProcessRequest, но, в свою очередь, он служит в качестве оболочки
для другого объекта типа ProcessRequest.
Объект декоратора формирует оболочку вокруг дочернего объекта, поэтому
очень важно поддерживать интерфейс настолько разреженным, насколько это
возможно. Если создать базовый класс с многими функциональными возмож
ностями, то объекты декораторов будут вынуждены делегировать эти функции
всем открытым методам того объекта, который они содержат. Это можно сде
лать в абстрактном классе декоратора, но в конечном итоге образуется такая
тесная связь, которая может привести к программным ошибкам.
Некоторые программисты создают декораторы, не разделяющие общий тип
с объектами, которые они видоизменяют. И до тех пор, пока они работают в
рамках того же интерфейса, где и эти объекты, такая стратегия оказывается эф
фективной. При этом можно выгодно пользоваться встроенными методами-пе
рехватчиками для автоматизации делегирования, реализовав метод__ call (),
чтобы перехватывать вызовы несуществующих методов и автоматически вызы
вать тот же самый метод для дочернего объекта. Но в конечном счете теряется
безопасность, которую обеспечивает проверка типа класса. В приведенных до
сих пор примерах клиентский код мог потребовать в своем списке аргументов
объект типа Tile или ProcessRequest и быть уверенным в его интерфейсе
независимо от того, является ли этот объект сильно декорированным.

Шаблон Facade
Вам, возможно, уже приходилось встраивать сторонние системы в свои про
екты. И независимо от того, является ли сторонний код объектно-ориентиро
ванным, он, как правило, очень сложный, длинный и непонятный. А ваш код
может, в свою очередь, вызвать трудности у программиста клиентского кода,
которому требуется всего лишь получить доступ к нескольким функциональным

314

ЧАСТЬ III « ШАБЛОНЫ

средствам. Шаблон Facade — это удобный способ предоставить простой и по
нятный интерфейс для сложных систем.

Проблема
Обычно в процессе проектирования системы объем исходного кода, который
на самом деле полезен только в пределах самой системы, постепенно увеличи
вается. В удачно спроектированных системах разработчики с помощью классов
определяют понятный общедоступный интерфейс и прячут поглубже внутрен
нее содержание системы. Но не всегда очевидно, какие именно части системы
должны использоваться в клиентском коде, а какие лучше скрыть.
Работая с такими подсистемами, как веб-форумы или приложения для соз
дания галерей, вам, возможно, приходилось делать вызовы, сильно углубляясь
в логику работы кода. Если исходный код подсистемы должен со временем ме
няться, а ваш код взаимодействует с ним в самых разных местах, то по мере
развития подсистемы у вас могут возникнуть серьезные трудности при сопро
вождении вашего кода.
Аналогично, когда вы создаете собственные системы, имеет смысл разнести
отдельные ее части на разные уровни. Как правило, первый уровень отвечает за
логику приложения, второй — за взаимодействие с базой данных, третий — за
представление данных и т.д. Вы должны стремиться поддерживать эти уровни
независимыми друг от друга, насколько это возможно, чтобы изменение в одной
части проекта минимально отражалось на других частях. Если код одного уров
ня тесно интегрирован в код другого уровня, то трудно будет достичь этой цели.
Ниже приведен пример специально запутанного процедурного кода, где про
стая задача получения информации из текстовых файлов и преобразования ее в
данные объекта превращается в нечто очень сложное.
// Листинг 10.36

function getProductFileLines ( $file )
return file( $file );
}

{

function getProductObjectFromld( $id, $productname )
// сделать запрос к базе данных
return new Product( $id, $productname );
}

function getNameFromLine( $line ) {
if (preg_match("/.*-(.*)\s\d+/", $line, $array))
return str_replace(
$array[l] );
}
return ’ ’ ;
}
function getIDFromLine($line) {
if (preg_match(”/л(\d{1,3})-/",
return $array[l];

$line,

$array))

{

{

{

ГЛАВА 10 я ШАБЛОНЫ ДЛЯ ПРОГРАММИРОВАНИЯ ГИБКИХ ОБЪЕКТОВ

315

return -1;

}
class Product {
public $id;
public $name;

function __ construct ( $id,
$this->id = $id;
$this->name = $name;
}

$name )

{

}

Допустим, что внутреннее содержимое приведенного выше кода сложнее,
чем оно есть на самом деле, и нам придется воспользоваться им, чтобы не пе
реписывать его заново. Допустим также, что приведенные ниже строки из файла
требуется преобразовать в массив объектов.
234-Свитер_женский 55
532-Шляпа_мужская 44

С этой целью нам придется вызвать все упомянутые выше функции (ради
краткости мы не извлекаем из исходных строк последнее число, обозначающее
цену на товар).
// Листинг 10.37
$lines = getProductFileLines(__ DIR__ . ’/test2.txt’);
$objects = [ ] ;
foreach ($lines as $line) {
$id = getlDFromLine($line);
$name = getNameFromLine($line);
$objects[$id] = getProductObjectFromlD($id, $name);
}

Если мы вызовем эти функции непосредственно в проекте, как показано
выше, то наш код будет тесно вплетен в подсистему, которая в нем использу
ется. И это может вызвать осложнения, если подсистема изменится или если
мы решим отказаться от нее полностью. Поэтому нам следует внедрить шлюз
между системой и остальным кодом.

Реализация
В качестве примера ниже приведено определение простого класса, предо
ставляющего интерфейс для процедурного кода, упоминавшегося в предыдущем
разделе.
// Листинг 10.38
class ProductFacade
{

private $products = [];

316

ЧАСТЬ III Я ШАБЛОНЫ

public function __ construct(string $file)
{

$this->file = $file;
$this->compile ();
}

private function compile ()
{

$lines = getProductFileLines($this->file);
foreach ($lines as $line) {
$id = getIDFromLine($line);
$name = getNameFromLine($line);
$this->products[$id] =
getProductObjectFromID($id, $name);

}
}
public function getProducts(): array
{

return $this->products;
}

public function getProduct(string $id):

\Product

{
if (isset($this->products[$id]))
return $this->products[$id];

{

}
return null;

}
}

С точки зрения клиентского кода доступ к объектам типа Product из тексто
вого файла теперь намного упрощен.
// Листинг 10.39

$facade = new ProductFacade(__ DIR__ . ’/test2.txt’);
$object = $facade->getProduct ( "234’’) ;

Выводы
В основу шаблона Facade на самом деле положено очень простое понятие,
которое означает создание единственной точки входа на другой уровень или в
подсистему. В итоге мы получаем ряд преимуществ, поскольку отдельные части
проекта отделяются одна от другой. Программистам клиентского кода полезно
и удобно иметь доступ к простым методам, которые выполняют понятные и
очевидные действия. Это дает возможность сократить количество ошибок, со
средоточив обращение к подсистеме в одном месте, и тогда изменения в этой
подсистеме вызовут сбой в предсказуемом месте. Кроме того, классы, создавае
мые по шаблону Facade, сводят к минимуму ошибки в сложных подсистемах,

ГЛАВА 10 ж ШАБЛОНЫ ДЛЯ ПРОГРАММИРОВАНИЯ ГИБКИХ ОБЪЕКТОВ

317

где внутренние функции могли бы в противном случае неверно использоваться
в клиентском коде.
Несмотря на всю простоту шаблона Facade, можно очень легко забыть вос
пользоваться им, особенно если вы знакомы с подсистемой, с которой работа
ете. Но здесь необходимо, конечно, найти золотую середину. С одной стороны,
преимущества создания простых интерфейсов для сложных систем очевидны, а
с другой — можно необдуманно абстрагировать сначала системы, а затем сами
абстракции. Если вы делаете значительные упрощения для пользы клиентского
кода и/или ограждаете его от систем, которые могут изменяться, то у вас, веро
ятно, есть все основания для реализации шаблона Facade.

Резюме
В этой главе мы рассмотрели несколько способов организации классов и объ
ектов в системе. В частности, мы остановились на том, что композицию можно
использовать для обеспечения гибкости там, где этого не может дать наследова
ние. В шаблонах Composite и Decorator наследование применяется для под
держки композиции и определения общего интерфейса, который дает гарантии
для клиентского кода.
Мы также показали, что в этих шаблонах эффективно используется деле
гирование. И, наконец, рассмотрели простой, но очень эффективный шаблон
Facade. Это один из тех проектных шаблонов, которыми программисты поль
зуются годами, даже не зная, что он так называется. Шаблон Facade позволяет
создать удобную и понятную точку входа для уровня или подсистемы. В языке
РНР шаблон Facade применяется также для создания объектов-оболочек, в ко
торые инкапсулированы блоки процедурного кода.

ГЛАВА 11

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

в Шаблон Strategy. Определение алгоритмов в системе и их инкапсуляция
в собственные типы.

в Шаблон Observer. Создание перехватчиков для извещения несовмести
мых объектов о событиях в системе.
в Шаблон Visitor. Выполнение операции над всеми узлами иерархическо
го дерева объектов.
в Шаблон Command. Создание командных объектов, которые можно сохра
нять и передавать.
в Шаблон Null Object. Применение бездействующих объектов вместо пу
стых значений.

Шаблон Interpreter
Компиляторы и интерпретаторы языков программирования обычно пишутся
на других языках программирования (по крайней мере, так было с самого на
чала). Например, сам интерпретатор языка РНР написан на языке С. Аналогич
но, как это ни покажется странным, на языке РНР можно определить и создать
интерпретатор собственного языка. Безусловно, любой интерпретатор, созда
ваемый подобным образом, будет работать сравнительно медленно и окажется

320

ЧАСТЬ III

ШАБЛОНЫ

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

Проблема
Создавая на РНР интерфейсы для веб или командной строки, мы, по суще
ству, предоставляем пользователю доступ к функциональным средствам. При
разработке интерфейса приходится находить компромисс между эффективно
стью и простотой использования. Как правило, чем больше возможностей пре
доставляется пользователю, тем более усложненным и запутанным становится
интерфейс. Это, конечно, поможет делу, если удачно спроектировать интерфейс.
Но если 90% пользователей употребляют один и тот же ряд функций (пример
но треть от общего их числа), то вряд ли стоит расширять функциональные
возможности приложения. Возможно, будет даже решено упростить систему в
расчете на большинство пользователей. Но как быть с 10% пользователей, ис
пользующих расширенные возможности системы? Им, вероятно, можно помочь
как-то иначе. В частности, предложив таким пользователям предметно-ориенти
рованный язык программирования, который обычно называется Domain Specific
Language (DSL), можно действительно повысить потенциал приложения.
На самом деле в нашем распоряжении уже имеется язык программирования,
который называется РНР. Ниже показано, как разрешить пользователям созда
вать на нем сценарии в проектируемой системе.
$form_input = $_REQUEST['form_input'];
// Через поле формы на сервер передан следующий код:
// "print file_get_contents(’/etc/passwd’);"
eval( $form_input );

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

ГЛАВА 11 S ВЫПОЛНЕНИЕ ЗАДАЧ И ПРЕДСТАВЛЕНИЕ РЕЗУЛЬТАТОВ

321

Ниже приведен пример вопроса такой викторины.
Сколько членов в группе разработки проектных шаблонов?

В качестве правильных ответов можно принять "четыре" или "4". Можно
даже создать веб-интерфейс, позволяющий создателям викторины применить
регулярное выражение для оценки ответов.
А4|четыре$

Но, к сожалению, не все создатели владеют регулярными выражениями.
И чтобы облегчить их задачу, можно реализовать более удобный для пользова
телей механизм оценки ответов.
$input equals ”4” or $input equals ’'четыре”

В данном случае предлагается язык, в котором поддерживаются перемен
ные, операция equals и булева логика (логические операции or и and). Про
граммисты любят все как-то называть, поэтому назовем такой язык MarkLogic.
Этот язык должен легко расширяться, поскольку нетрудно предвидеть немало
запросов на более сложные функции. Оставим пока что в стороне вопрос син
таксического анализа входных данных и сосредоточимся на механизме соеди
нения отдельных элементов вместе во время выполнения программы для фор
мирования ответа. Именно здесь, как и следовало ожидать, пригодится шаблон
Interpreter (Интерпретатор).

Реализация
Мини-язык MarkLogic состоит из выражений, вместо которых подставляются
некоторые значения. Как следует из табл. 11.1, даже в таком скромном языке,
как MarkLogic, приходится отслеживать немало элементов.
Таблица 11.1. Элементы грамматики мини-языка MarkLogic

Описание

Имя EBNF

Переменная variable

Имя класса

Пример

VariableExpression

$input
’’четыре”

Строковый
литерал

LiteralExpression

Логическое
И

andExpr

BooleanAndExpression $input equals ’ 4 ’ and
$other equals ’ 6 ’

Логическое
ИЛИ

orExpr

BooleanOrExpression

$input equals ’ 4 ’ or
$other equals ’ 6 ’

EqualsExpression

$input equals ’4'

Проверка на equalsExpr
равенство

В табл. 11.1 приведены имена в форме EBNF. А что такое EBNF? Это обо
значение, которое можно использовать для описания грамматики языка. Со
кращение EBNF обозначает Extended Backus-Naur Form (расширенная форма

322

ЧАСТЬ III в ШАБЛОНЫ

Бэкуса-Наура). Она состоит из набора строк, которые называются продукция
ми. Каждая продукция состоит из имени и описания, которое принимает форму
ссылок на другие продукции и на терминалы (т.е. элементы, которые сами не
состоят из ссылок на другие продукции). Ниже показано, как можно описать
грамматику мини-языка MarkLogic с помощью формы EBNF.
expr
= operand { orExpr | andExpr }
operand = ( ' (' expr ' ) ' I ? string literal ?
orExpr
= 'or’ operand
andExpr = ’and' operand
eqExpr
= 'equals’ operand
variable = ' $' , ? word ?

| variable )

{ eqExpr }

Некоторые знаки имеют специальный смысл (они должны быть вам знакомы
по регулярным выражениям), например, знак ’ * ’ означает “нуль или больше”,
а знак ’ | ’ — “или”. Группировать элементы можно с помощью скобок. Так, в
приведенном выше примере выражение (expr) состоит из лексемы operand,
за которой следует нуль или больше лексем, orExpr или andExpr. В качестве
лексемы operand может служит выражение в скобках, строковая константа
(продукция для него опущена) или переменная, после которой следует нуль или
больше лексем eqExpr. Как только вы поймете, как ссылаться в одной продук
ции на другую, форма EBNF станет очень простой для чтения и понимания.
На рис. 11.1 элементы грамматики рассматриваемого здесь языка представ
лены в виде диаграммы классов.

Рис. 11.1. Классы, образующие мини-язык MarkLogic по шаблону interpreter

ГЛАВА 11 ш ВЫПОЛНЕНИЕ ЗАДАЧ И ПРЕДСТАВЛЕНИЕ РЕЗУЛЬТАТОВ

323

Как видите, класс BooleanAndExpression и родственные ему классы унас
ледованы от класса OperatorExpression. Дело в том, что все эти классы вы
полняют операции над другими объектами типа Expression. А объекты типа
VariableExpression и LiteralExpression оперируют непосредственно зна
чениями.
Во всех объектах типа Expression реализован метод interpret (), опреде
ленный в абстрактном базовом классе Expression. Методу interpret () пере
дается объект типа Interpretercontext, который служит в качестве общего
хранилища данных. Каждый объект типа Expression может сохранять данные
в объекте типа Interpretercontext, который затем передается другим объек
там типа Expression. В базовом классе Expression реализован также метод
getKey (), возвращающий уникальный дескриптор и упрощающий извлечение
данных из объекта типа Interpretercontext. Рассмотрим практическое при
менение мини-языка MarkLogic на примере реализации класса Expression.
// Листинг 11.01
abstract class Expression

{
private static $keycount = 0;
private $key;
abstract public function interpret (
Interpretercontext $context);

public function getKey()
{
if (! isset($this->key)) {
self::$keycount++;
$this->key = self::$keycount;

}
return $this->key;
}

}

// Листинг 11.02
class LiteralExpression extends Expression

{
private $value;

public function __ construct($value)
{

$this->value = $value;
}

public function interpret(Interpretercontext $context)
{

$context->replace($this, $this->value);

324

ЧАСТЬ III

ШАБЛОНЫ

// Листинг 11.03

class Interpretercontext
{
private $expressionstore = [];

public function replace(Expression $exp,

$value)

{

$this->expressionstore[$exp->getKey ()] = $value;

}
public function lookup(Expression $exp)
{
return $this->expressionstore[$exp->getKey()];
}
}
// Листинг 11.04

$context = new Interpretercontext();
$literal = new LiteralExpression('четыре’);
$literal->interpret($context);
print $context->lookup(Sliteral) . "\n";

И вот что получится в результате выполнения приведенного выше фрагмента
кода:
четыре

Начнем анализ данного примера кода с класса Interpretercontext. Как
видите, он на самом деле представляет собой только внешний интерфейс для
ассоциативного массива $expressionstore, который служит для хранения
данных. Методу replace () передаются ключ и значение, которые сохраняют
ся в ассоциативном массиве $expressionstore. В качестве ключа использу
ется объект типа Expression, а значение может быть любого типа. В классе
Interpretercontext также реализован метод lookup () для извлечения данных.
В классе Expression определены абстрактный метод interpret () и
конкретный метод getKeyO, оперирующий статическим значением счет
чика. Именно оно и возвращается в качестве дескриптора выражения.
Этот метод используется в методах Interpretercontext:: lookup () и
Interpretercontext: : replace () для индексирования данных.
В классе LiteralExpression определен конструктор, которому переда
ется значение аргумента. А методу interpret () необходимо передать объ
ект типа Interpretercontext. В нем просто вызывается метод replace ()
этого объекта, которому передаются ключ (ссылка на сам объект типа
LiteralExpression) и значение переменной $value. В методе replace ()
объекта типа Interpretercontext для определения численного значения
ключа используется метод getKey (). По мере исследования других классов

ГЛАВА 11

ВЫПОЛНЕНИЕ ЗАДАЧ И ПРЕДСТАВЛЕНИЕ РЕЗУЛЬТАТОВ

325

типа Expression подобный шаблонный подход станет для вас уже привыч
ным. Метод interpret () всегда сохраняет свои результаты в объекте типа
Interpretercontext.
В приведенный выше пример включен также фрагмент клиентского кода, в ко
тором создаются экземпляры объектов типа Interpretercontext и LiteralEx
pression (со значением ’четыре’)- Объект типа Interpretercontext пере
дается методу LiteralExpression:: interpret (). Этот метод сохраняет пару
"ключ-значение” в объекте типа Interpretercontext, из которого затем из
влекается значение, вызывая метод lookup ().
Определим далее оставшийся конечный класс VariableExpression. Этот
класс немного сложнее.
// Листинг 11.05
class VariableExpression extends Expression
{

private $name;
private $val;
public function __ construct($name,

$val = null)

{

$this->name = $name;
$this->val = $val;
}

public function interpret(Interpretercontext $context)

{
if (1 is_null($this->val)) {
$context->replace($this, $this->val);
$this->val = null;

}
}

public function setvalue($value)
{

$this->val = $value;

}
public function getKey()

{
return $this->name;
}

}
// Листинг 11.06

$context = new Interpretercontext();
$myvar = new VariableExpression('input’,
$myvar->interpret($context);
print $context->lookup($myvar) . ”\n";
// выводится: четыре

’четыре’);

326

ЧАСТЬ III ® ШАБЛОНЫ

$newvar = new VariableExpression(’input’);
$newvar->interpret($context) ;
print $context->lookup($newvar) . ”\n”;
// выводится: четыре

$myvar->setValue("пять’’);
$myvar->interpret($context);
print $context->lookup($myvar)
// выводится: пять
print $context->lookup($newvar)
// выводится: пять

.

"\n";

.

"\n";

Конструктору класса VariableExpression передаются два аргумента (имя
и значение), которые сохраняются в свойствах объекта. В данном классе реали
зован метод setvalue () для того, чтобы значение переменной можно было в
любой момент изменить в клиентском коде.
В методе interpret () проверяется, имеет ли свойство $val ненулевое
значение. Если в свойстве $val имеется некоторое значение, оно сохраняется
в объекте типа Interpretercontext. Далее в свойстве $val устанавливает
ся пустое значение null. Это делается для того, чтобы при повторном вызове
метода interpret () не нарушилось значение переменной с тем же именем,
сохраненной в объекте Interpretercontext другим экземпляром объек
та VariableExpression. Возможности этой переменной довольно ограни
чены, поскольку ей могут быть присвоены только строковые значения. Если
бы потребовалось расширить мини-язык MarkLogic, то пришлось бы сделать
так, чтобы он работал с другими объектами типа Expression, содержащи
ми результаты выполнения логических и других операций. Но пока что класс
VariableExpression будет делать именно то, что от него требуется. Обрати
те внимание на то, что метод getKey () был переопределен, чтобы значения
переменных были связаны с их именами, а не с произвольными статическими
идентификаторами.
В мини-языке MarkLogic все операторные выражения оперируют двумя дру
гими объектами типа Expression. Поэтому имеет смысл, чтобы они расширяли
общий суперкласс. Ниже приведено определение класса OperatorExpression.
// Листинг 11.07
abstract class OperatorExpression extends Expression
{
protected $l_op;
protected $r_op;

public function __ construct(Expression $l_op,
Expression $r_op)
{
$this->l_op = $l_op;
$this->r op = $r op;

ГЛАВА 11 а ВЫПОЛНЕНИЕ ЗАДАЧ И ПРЕДСТАВЛЕНИЕ РЕЗУЛЬТАТОВ

327

public function interpret(Interpretercontext Scontext)
{

$this->l_op->interpret(Scontext);
$this->r_op->interpret(Scontext) ;
Sresult_l = $context->lookup($this->l_op);
$result_r = $context->lookup($this->r_op);
$this->dolnterpret(Scontext, $result_l, $result_r);

}

abstract protected function dolnterpret (
Interpretercontext Scontext,
$result_l,
$result_r
) ;

}

В абстрактном классе OperatorExpression реализован метод interpret (),
а также определен абстрактный метод dolnterpret (). Конструктору этого
класса передаются два объекта типа Expression для левого и правого операн
дов ($1_ор и $г_ор), которые он сохраняет в свойствах объекта.
Выполнение метода interpret () начинается с вызовов методов inter
pret () для обоих операндов, хранящихся в свойствах (если вы читали пре
дыдущую главу, то, вероятно, заметили, что здесь был получен экземпляр
класса по шаблону Composite). После этого в методе interpret () опре
деляются значения левого и правого операндов с помощью вызова метода
Interpretercontext:: lookup () для каждого из них. Затем вызывается метод
dolnterpret (), чтобы дочерние классы могли решить, какую именно опера
цию необходимо выполнить над полученными значениями операндов.
НА ЗАМЕТКУ. Метод dolnterpret () служит характерным примером применения ша

блона Template Method. По этому шаблону в родительском классе определяется и
вызывается абстрактный метод, реализация которого оставляется дочерним классам.
Это может упростить разработку конкретных классов, поскольку совместно исполь
зуемыми функциями управляет суперкласс, оставляя дочерним классам задачу скон
центрироваться на ясных и понятных целях.
Ниже приведено определение класса EqualsExpression, где проверяется
равенство двух объектов типа Expression.
// Листинг 11.08
class EqualsExpression extends OperatorExpression
{

protected function dolnterpret (
Interpretercontext Scontext,
$result_l,
$result_r
)

{
$context->replace (Sthis,

$result_l == $result_r);

328

ЧАСТЬ III

ШАБЛОНЫ

В классе EqualsExpression реализован только метод dolnterpret ().
В нем проверяется равенство значений двух операндов, переданных из метода
interpret () и полученных из объекта типа Interpretercontext.
Чтобы завершить набор классов типа Expression, приведем определение
классов BooleanOrExpression и BooleanAndExpression.
// Листинг 11.09

class BooleanOrExpression extends OperatorExpression
{
protected function dolnterpret (
Interpretercontext $context,
$result_l,
$result_r
) {
$context->replace($this, $result_l || $result_r);
}
}
// Листинг 11.10

class BooleanAndExpression extends OperatorExpression
{
protected function dolnterpret (
Interpretercontext $context,
$result_l,
$result_r
) {
$context->replace ($this, $result_l && $result_r);
}
}

Вместо проверки на равенство в классе BooleanOrExpression использу
ется логическая операция ИЛИ, а полученный результат сохраняется в кон
тексте с помощью метода Interpretercontext:: replace (). В классе
BooleanAndExpression, естественно, используется логическая операция И.
Итак, мы получили код, с помощью которого можно интерпретировать фраг
мент приведенного ранее выражения на мини-языке MarkLogic. Повторим его
еще раз.
$input equals "4" or $input equals ’’четыре"

Ниже показано, как описать это выражение с помощью классов типа
Expression.
// Листинг 11.11
$context = new Interpretercontext();
$input = new VariableExpression('input’);
Sstatement = new BooleanOrExpression(
new EqualsExpression($input,
new LiteralExpression(’четыре')),
new EqualsExpression($input,
new LiteralExpression(’4’))

) ;

ГЛАВА 11 Ж ВЫПОЛНЕНИЕ ЗАДАЧ И ПРЕДСТАВЛЕНИЕ РЕЗУЛЬТАТОВ

329

В данном случае сначала создается переменная экземпляра $ input,
но ей пока еще не присваивается значение. Затем создается объект типа
BooleanOrExpression, предназначенный для сравнения результатов, получае
мых из двух объектов типа EqualsExpression. В первом случае сравнивается
объект типа VariableExpression, который сохраняется в переменной $input,
с объектом типа LiteralExpression, содержащим символьную строку "четы
ре”. А во втором случае сравнивается значение переменной $ input с объектом
типа LiteralExpression, содержащим символьную строку "4".
Теперь, имея подготовленный оператор, мы подошли к тому, чтобы присво
ить значение переменной $ input и выполнить код.
// Листинг 11.12
foreach ([’’четыре”, "4”, ”52’’] as $val)
$input->setValue($val);
print ”$val:\n";
$statement->interpret($context);
if ($context->lookup($statement)) {
print ’’Правильный ответ !\n\n”;
} else {
print "Вы ошиблись!\n\n";

{

}
}

Фактически код запускается на выполнение три раза с тремя разными зна
чениями. Но первый раз во временной переменной $val устанавливается
значение ’’четыре”, которое затем присваивается переменной $ input типа
VariableExpression. Для этого вызывается метод setValue(). Далее вы
зывается метод interpret () для объекта типа Expression самого верхнего
уровня (т.е. объекта типа BooleanOrExpression, который содержит ссылки на
все другие выражения в операторе). Рассмотрим поэтапно, что же происходит
непосредственно в этом вызове.

it Вызывается метод interpret () для свойства $1_ор объекта по ссылке в
переменной $statement (это первый объект типа EqualsExpression).
® Вызывается метод interpret () для свойства $1_ор первого объекта
типа EqualsExpression (в нем содержится ссылка на объект типа Vari
ableExpression (переменная $input), для которого в настоящий момент
установлено значение ’’четыре”).

& Объект типа VariableExpression, содержащийся в переменной
$ input, записывает свое текущее значение в предоставленный объект
типа Interpretercontext, вызывая метод Interpretercontext::
replace ().
ш Вызывается метод interpret () для свойства $г_ор первого объекта
типа EqualsExpression (объекту типа LiteralExpression присвоено
значение ’’четыре”).

330

ЧАСТЬ III

ШАБЛОНЫ

Объект типа LiteralExpression регистрирует имя и значение своего
ключа в объекте типа Interpretercontext.

в Первый объект типа EqualsExpression извлекает значения для свойств
$1_ор ("четыре") и $г_ор ("четыре") из объекта типа InterpreterContext.

и Первый объект EqualsExpression сравнивает эти два значения, прове
ряя их на равенство, и регистрирует результат (логическое значение true)
вместе с именем ключа в объекте типа Interpretercontext.

» На вершине иерархического дерева для объекта типа BooleanOrExpression
в переменной $statement вызывается метод interpret () для его свой
ства $г_ор. В итоге значение (в данном случае это логическое значение
false) получается таким же образом, как при использовании свойства
$1_ор.
в Объект в переменной $ statement извлекает значения для каждого из
своих операндов из объекта Interpretercontext и сравнивает их в
логической операции I |. В итоге сравниваются логические значения
true и false, и поэтому в результате будет получено логическое зна
чение true. И этот окончательный результат сохраняется в объекте типа
Interpretercontext.

И все это лишь первый шаг рассматриваемого здесь цикла. Окончательный
результат приведен ниже.
четыре:
Правильный ответ!
4:
Правильный ответ!

52:
Вы ошиблись !

Возможно, вам придется прочитать этот раздел несколько раз, прежде чем
все станет ясно. Вас может смутить здесь давний вопрос различения иерархи
ческих деревьев классов и объектов. Если классы Expression организуются
в иерархию при наследовании, то объекты типа Expression объединяются в
иерархическое дерево во время выполнения программы. Не забывайте об этом
отличии, когда будете снова просматривать код из данного примера.
На рис. 11.2 показана полная диаграмма классов для рассматриваемого здесь
примера.

ГЛАВА 11 в ВЫПОЛНЕНИЕ ЗАДАЧ И ПРЕДСТАВЛЕНИЕ РЕЗУЛЬТАТОВ

331

Рис. 11.2. Пример применения шаблона Interpreter

Трудности реализации шаблона interpreter
Как только основные классы будут подготовлены к реализации шаблона
Interpreter, расширить их иерархию будет нетрудно. Цена, которую за это
приходится платить, определяется лишь количеством классов, которые необхо
димо создать. Поэтому шаблон Interpreter пригоден в большей степени для
разработки относительно небольших языков. А если требуется полноценный
язык программирования, то для этой цели лучше поискать сторонние инстру
ментальные средства.
Классы, созданные по шаблону Interpreter, нередко выполняют очень схо
жие задачи, поэтому стоит следить за создаваемыми классами, чтобы не допу
стить их дублирования. Многие из тех, кто в первый раз обращается к шаблону
Interpreter, после некоторых начальных экспериментов разочаровываются,
обнаружив, что он не позволяет выполнять синтаксический анализ. Это означа
ет, что мы пока еще не можем предложить пользователям хороший и удобный
мини-язык. В приложении Б, “Простой синтаксический анализатор”, приведен
примерный вариант кода, иллюстрирующего одну из стратегий синтаксического
анализа мини-языка.

332

ЧАСТЬ III S ШАБЛОНЫ

Шаблон Strategy
Разработчики часто пытаются наделить классы слишком большими обязан
ностями. И это понятно, поскольку вы обычно создаете класс, выполняющий
ряд связанных вместе действий. Как и код, некоторые из этих действий прихо
дится иногда изменять в зависимости от обстоятельств. В то же время классы
необходимо разбивать на подклассы. И прежде чем вы это поймете, ваш проект
начнет рассыпаться как карточный домик.

Проблема
В предыдущем разделе мы создали интерпретатор мини-языка, поэтому об
ратимся снова к примеру с викториной. Для викторин нужны вопросы, поэтому
мы создали класс Question и реализовали в нем метод mark(). Но все это
замечательно до тех пор, пока не придется поддерживать разные механизмы
оценки.
Допустим, нас попросили поддержать простой мини-язык MarkLogic, в ко
тором оценка получается в результате простого сравнения отличий в ответах,
а также с помощью регулярных выражений. Первой мыслью, вероятно, будет
создание подклассов, в которых учитываются подобные отличия (рис. 11.3).

Рис. 11.3. Определение подклассов в соответствии
со стратегиями оценки

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

ГЛАВА 11 а ВЫПОЛНЕНИЕ ЗАДАЧ И ПРЕДСТАВЛЕНИЕ РЕЗУЛЬТАТОВ

333

Рис. 11.4. Определение подклассов на основе двух внешних факторов

Реализация
Как и все лучшие шаблоны, шаблон Strategy одновременно прост и эф
фективен. Если классы должны поддерживать несколько реализаций интерфейса
(например, несколько механизмов оценки), то зачастую эти реализации лучше
всего выделить и разместить в классе отдельного типа, а не расширять перво
начальный класс, чтобы оперировать им.
Так, в рассматриваемом здесь примере алгоритм оценки можно разместить
в классе Marker. Полученная в итоге новая структура приведена на рис. 11.5.

Рис. 11.5. Выделение алгоритмов в их класс отдельного типа

334

ЧАСТЬ III № ШАБЛОНЫ

Помните принцип “Банды четырех”: “отдавайте предпочтение композиции,
а не наследованию”? Данный пример наглядно демонстрирует этот принцип.
Определяя и инкапсулируя алгоритмы оценки, мы сокращаем количество созда
ваемых подклассов и повышаем степень гибкости. Мы можем в любой момент
добавить новые стратегии оценки, причем для этого нам не потребуется изме
нять классы Question. Этим классам известно лишь то, что в их распоряжении
имеется экземпляр класса Marker и что через свой интерфейс он гарантиро
ванно поддерживает метод mark(), а подробности реализации — это вообще
не их дело.
Ниже приведено определение семейства классов Question, представленное
в исходном коде.
// Листинг 11.13

abstract class Question
{
protected $prompt;
protected $marker;

public function __ construct(string $prompt, Marker $marker)
{
$this->prompt = $prompt;
$this->marker = $marker;
}

public function mark(string $response): bool
{
return $this->marker->mark($response);
}
}
// Листинг 11.14

class TextQuestion extends Question
{
// обработать вопрос в текстовой форме
}

// Листинг 11.15
class AVQuestion extends Question
{
// обработать вопрос в мультимедийной форме
}

Как видите, реализация отличительных особенностей классов TextQuestion
и AVQuestion оставлена на ваше усмотрение. Все необходимые функции обе
спечиваются в базовом классе Question, где, кроме всего прочего, хранится
свойство, содержащее вопрос и объект типа Marker. Когда вызывается метод
Question: :mark() с ответом конечного пользователя, этот метод просто пору
чает решение задачи своему объекту Marker.

ГЛАВА 11 Я ВЫПОЛНЕНИЕ ЗАДАЧ И ПРЕДСТАВЛЕНИЕ РЕЗУЛЬТАТОВ

А теперь определим ряд простых объектов типа Marker.
// Листинг 11.16
abstract class Marker
{

protected $test;
public function __ construct(string $test)
{

$this->test = $test;

abstract public function mark(string $response) : bool;

// Листинг 11.17
class MarkLogicMarker extends Marker
{

private $engine;
public function __ construct(string $test)
{

parent::__ construct($test);
$this->engine = new MarkParse($test);

public function mark(string Sresponse): bool
{

return $this->engine->evaluate($response);

// Листинг 11.18

class MatchMarker extends Marker

{
public function mark(string $response) : bool
{

return ($this->test == $response);

// Листинг 11.19
class RegexpMarker extends Marker
{

public function mark(string $response) : bool

{
return

(preg_match("$this->test",

$response) === 1);

335

336

ЧАСТЬ III

ШАБЛОНЫ

Как видите, в классах Marker нет, в общем, ничего неожиданного. Обратите
внимание на то, что объект типа MarkParse предназначен для работы с про
стым синтаксическим анализатором, простая реализация которого приведена в
приложении Б, “Простой синтаксический анализатор”. Самое главное здесь —
определить структуру, а не подробности реализации самих стратегий. Можно,
например, заменить класс RegexpMarker на MatchMarker, и это никак не по
влияет на класс Question.
Разумеется, необходимо еще решить, каким образом выбирать конкретные
объекты типа Marker. На практике для решения этой задачи применяются два
подхода. В первом случае для выбора предпочитаемой стратегии оценки употре
бляются кнопки-переключатели, а во втором — сама структура условия оценки,
где операция сравнения остается простой. Так, для оценки "пять" перед опе
ратором мини-языка MarkLogic ставится двоеточие:
:$input equals ’five'

а в регулярном выражении употребляются знаки косой черты.
/П.ть/

Ниже приведен код, позволяющий проверить классы Marker на практике.
// Листинг 11.20
$markers = [
new RegexpMarker("/П.ть/"),
new MatchMarker("Пять"),
new MarkLogicMarker('$input equals "Пять"')

];

foreach ($markers as $marker) {
print get_class($marker)."\n";
$question = new TextQuestion(
"Сколько лучей у Кремлевской звезды?",
foreach (["Пять", "Четыре"] as $response) {
print " Ответ: $response: ";
if ($question->mark($response)) {
print "Правильно!\n";
} else {
print "Неверно!\n";

$marker);

}
}
}

Мы создали три объекта, содержащие стратегии оценки ответов, которые по
очереди используются для создания объекта типа TextQuestion. Затем объект
типа TextQuestion проверяется по двум вариантам ответа. Выполнение приве
денного выше фрагмента кода приведет к следующему результату:

ГЛАВА 11 я ВЫПОЛНЕНИЕ ЗАДАЧ И ПРЕДСТАВЛЕНИЕ РЕЗУЛЬТАТОВ

337

RegexpMarker
Ответ: Пять: Правильно!
Ответ: Четыре: Неверно!
MatchMarker
Ответ: Пять: Правильно!
Ответ: Четыре: Неверно!
MarkLogicMarker
Ответ: Пять: Правильно!
Ответ: Четыре: Неверно!

В этом примере мы передали введенные пользователем данные (они содер
жатся в переменной $response) от клиента к объекту стратегии оценки через
метод mark (). Но иногда возникают ситуации, когда заранее неизвестно, сколь
ко информации потребуется объекту стратегии оценки для выполнения своих
обязанностей. Поэтому решение, какие именно данные следует получать, можно
поручить самому объекту стратегии оценки, передав ему экземпляр клиентского
объекта. И тогда объект стратегии оценки сам запросит у клиента нужные ему
данные.

Шаблон Observer
Преимущества ортогональности уже обсуждались раньше. Одной из целей
разработчиков должно быть создание компонентов, которые можно изменять
или перемещать с минимальным воздействием на другие компоненты. Если ка
ждое изменение, которое вносится в один компонент, влечет за собой необхо
димость изменений в других местах кодовой базы, то задача разработки быстро
раскрутится по спирали до внесения и устранения программных ошибок.
Разумеется, об ортогональности можно только мечтать, как о недостижи
мой цели. Компоненты проектируемой системы должны содержать встроен
ные ссылки на другие компоненты. Но для сведения таких ссылок к минимуму
можно применить различные стратегии. Ранее были продемонстрированы раз
личные примеры употребления полиморфизма, где клиентскому коду понятен
интерфейс компонента, но сам конкретный компонент может меняться во время
выполнения программы.
Но иногда может возникнуть потребность вбить еще больший клин между
компонентами. Рассмотрим в качестве примера следующий класс, отвечающий
за управление доступом пользователя к системе:
// Листинг 11.21

class Login

{
const LOGIN_USER_UNKNOWN = 1;
const LOGIN_WRONG_PASS = 2;
const LOGIN_ACCESS = 3;

private $status = [];

338

ЧАСТЬ III ■ ШАБЛОНЫ

public function handleLogin(string $user,
string $ip): bool

string $pass,

{
$isvalid=false;
switch (rand(l, 3)) {
case 1:
$this->setStatus(self::LOGIN_ACCESS, $user,
$isvalid = true;
break;
case 2:
$this->setStatus(self::LOGIN_WRONG_PASS,
$user, $ip) ;
$isvalid = false;
break;
case 3:
$this->setStatus(self::LOGIN_USER_UNKNOWN,
$user, $ip) ;
$isvalid = false;
break;

$ip) ;

}

print ’’возвращается ” . ( ($isvalid) ?"истина” : "ложь" ) . "\n";

return $isvalid;
}

private function setstatus(int $status, string $user,
string $ip)
{
$this->status = [$status, $user, $ip];
}

public function getStatusQ: array
{

return $this->status;
}

}

Разумеется, в реальном примере метод handleLogin () должен проверять
учетные данные пользователя, хранящиеся где-нибудь в системе. Но в данном
случае класс Login имитирует процесс входа в систему с помощью функции
rand(). Возможны три разных результата вызова метода handleLogin ().
В частности, код состояния устанавливается в соответствии со значением кон
станты LOGIN_ACCESS, LOGIN_WRONG_PASS или LOGIN_USER_UNKNOWN.
Класс Login выполняет функции привратника, охраняющего сокровища и
тайны коммерческой деятельности вашей компании, и поэтому он может при
влекать большое внимание как на стадии проектирования системы, так и при
последующей ее эксплуатации. Например, вас могут вызвать в отдел маркетинга
и попросить организовать ведение журнала регистрации IP-адресов пользовате
лей системы. С этой целью вы можете добавить вызов соответствующего мето
да из класса Logger в вашей системе, как показано ниже.

ГЛАВА 11 « ВЫПОЛНЕНИЕ ЗАДАЧ И ПРЕДСТАВЛЕНИЕ РЕЗУЛЬТАТОВ

339

// Листинг 11.22

public function handleLogin(string $user, string $pass,
string $ip): bool
{

switch (rand(l, 3)) {
case 1:
$this->setStatus(self::LOGIN_ACCESS, $user, $ip) ;
$isvalid = true;
break;
case 2:
$this->setStatus(self::LOGIN_WRONG_PASS, $user, $ip) ;
$isvalid = false;
break;
case 3:
$this->setStatus(self::LOGIN_USER_UNKNOWNZ
$user, $ip);
$isvalid = false;
break;
}

Logger::loglP($user,

$ip,

$this->getStatus());

return $isvalid;
}

Заботясь о безопасности, системные администраторы могут попросить вас
вести учет неудачных попыток входа в систему. И в этом случае вы можете
вернуться к методу управления входом в систему и добавить новый вызов.
// Листинг 11.23

if ( ! $isvalid) {
Notifier:imailWarning(
$user,
$ip,
$this->getStatus()
) ;
}

В отделе развития коммерческой деятельности могут объявить о ее привязке
к конкретному поставщику услуг Интернета (ISP) и попросить, чтобы после
входа определенных пользователей в систему им высылались cookie-файлы.
И так далее и тому подобное.
Все эти требования нетрудно удовлетворить, хотя и за счет изменений про
ектного решения. Класс Login вскоре станет очень плотно встроенным в дан
ную конкретную систему. Его уже нельзя будет извлечь и включить в другой
программный продукт, не проанализировав построчно его исходный код и не
удалив все, что связано с прежней системой. Безусловно, это не так уж и труд
но сделать, но в конечном счете вы скатитесь на путь простого копирования
и вставки. Теперь, когда у вас имеются два похожих, но все же разных класса

340

ЧАСТЬ III

ШАБЛОНЫ

Login в ваших системах, вы обнаружите, что улучшение в одном классе приве
дет к необходимости аналогичных изменений в другом классе. И так будет про
должаться до тех пор, пока эти классы неизбежно перестанут быть похожими.
Так что же можно сделать, чтобы как-то спасти класс Login? Призвать на
помощь шаблон Observer.

Реализация
В основу шаблона Observer положен принцип отвязки клиентских элемен
тов (наблюдателей) от центрального класса (субъекта). Наблюдатели должны
быть осведомлены, когда происходят события, о которых известно субъекту.
В то же время нежелательно, чтобы у субъекта была жестко закодированная
связь с классами его наблюдателей.
Чтобы достичь этого, можно разрешить регистрировать наблюдателей в
субъекте. С этой целью введем в класс Login три новых метода, attach(),
detach () и notify (), с помощью интерфейса Observable, как показано ниже.
// Листинг 11.24
interface Observable

{

public function attach(Observer $observer);
public function detach(Observer Sobserver);
public function notify();
}

// Листинг 11.25
class Login implements Observable
{

private $observers = [];
private $storage;

const LOGIN JJSER_UNKNOWN = 1;
const LOGIN_WRONG_PASS = 2;
const LOGIN_ACCESS = 3;
public function attach(Observer $observer)
{

$this->observers [ ] = $observer;
}

public function detach(Observer $observer)
(

$this->observers = array_filter (
$this->observers,
function ($a) use ($observer) {
return (! ($a === $observer ));

ГЛАВА 11 ® ВЫПОЛНЕНИЕ ЗАДАЧ И ПРЕДСТАВЛЕНИЕ РЕЗУЛЬТАТОВ

341

public function notify()
{

foreach ($this->observers as $obs)
$obs->update($this);

{

}
}
// ...

}

Итак, класс Login управляет списком объектов наблюдателей. Они могут
быть введены в этот список третьей стороной с помощью метода attach () и
удалены из него с помощью метода detach(). Метод notify () вызывается,
чтобы сообщить наблюдателям, что произошло нечто интересное. Этот метод
просто перебирает в цикле список наблюдателей, вызывая для каждого из них
метод update ().
В самом классе Login метод notify () вызывается из его метода handle
Login (), определяемого следующим образом:
// Листинг 11.26
public function handleLogin(string $user,
string $ip)

string $pass,

{

switch (rand(l, 3)) {
case 1:
$this->setStatus(self::LOGIN_ACCESS, $user, $ip) ;
$isvalid = true;
break;
case 2:
$this->setStatus(self::LOGIN_WRONG_PASS, $user, $ip) ;
$isvalid = false;
break;
case 3:
$this->setStatus(self::LOGIN_USER_UNKNOWN,
$user, $ip);
$isvalid = false;
break;
}
$this->notify();
return $isvalid;
}

А теперь определим интерфейс для класса Observer.
// Листинг 11.27

interface Observer
{

public function update(Observable $observable);
}

Любой объект, использующий этот интерфейс, можно ввести в класс Login
с помощью метода attach (). Ниже приведен конкретный пример.

342

ЧАСТЬ III а ШАБЛОНЫ

// Листинг 11.28

class LoginAnalytics implements Observer
{
public function update(Observable $observable)
(
//не обеспечивает типовую безопасность!
$status = $observable->getStatus ();
print __ CLASS
. ": обрабатываем информацию о полученном состоянии \п";

}
}

Обратите внимание на то, как в объекте наблюдателя используется передан
ный ему экземпляр типа Observable, чтобы получить дополнительные сведе
ния о событии. Класс субъекта должен предоставить методы, которые могут
вызвать наблюдатели, чтобы узнать о состоянии субъекта. В данном случае мы
определили метод getStatus (), который наблюдатели могут вызвать, чтобы
получить сведения о текущем состоянии субъекта.
Но такое дополнение выявляет также следующее затруднение. При вызове
метода Login: :getStatus () классу LoginAnalytics передается больше све
дений, чем требуется для их безопасного использования. Этот вызов делается
для объекта типа Observable, но нет никакой гарантии, что это также будет
объект типа Login. Выйти из такой ситуации можно двумя путями. С одной
стороны, можно расширить интерфейс Observable, включив в него объявление
метода getStatus (). При этом, вероятно, придется переименовать интерфейс в
нечто вроде ObservableLogin, чтобы показать, что он связан непосредственно
с классом Login.
С другой стороны, можно сохранить интерфейс Observable общим, но сде
лать так, чтобы классы наблюдателей типа Observer были ответственными за
работу с субъектами правильного типа. Они даже могут выполнять работу по
присоединению себя к своему субъекту. А поскольку у нас будет не один на
блюдатель типа Observer и мы собираемся выполнять некоторые служебные
операции, общие для всех наблюдателей, то создадим абстрактный суперкласс,
который будет заниматься этой рутинной работой.
// Листинг 11.29
abstract class Loginobserver implements Observer
{
private $login;

public function __ construct(Login $login)
{

$this->login = $login;
$login->attach($this);

ГЛАВА 11 и ВЫПОЛНЕНИЕ ЗАДАЧ И ПРЕДСТАВЛЕНИЕ РЕЗУЛЬТАТОВ

343

public function update(Observable $observable)
{

if ($observable === $this->login)
$this->doUpdate($observable);

{

}
}
abstract public function doUpdate(Login $login);

}

Конструктору класса Loginobserver необходимо передать объект типа
Login. Он сохраняет ссылку на него и вызывает метод Login: :attach().
При вызове метода update () класса Loginobserver сначала проверяется, что
ему передана правильная ссылка на объект типа Observable. Затем вызыва
ется шаблонный метод doUpdate (). Теперь можно создать ряд объектов типа
Loginobserver, и все они могут быть уверены, что работают с объектом типа
Login, а не только с любым прежним объектом, поддерживающим интерфейс
Observable.
// Листинг 11.30

class SecurityMonitor extends Loginobserver
{

public function doUpdate(Login $login)
{

$status = $login->getStatus ();
if ($status[0] == Login::LOGIN_WRONG_PASS) {
// послать сообщение по электронной почте
// системному администратору
print __ CLASS__ .
Отправка почты системному администратору\п";
}

}
}

// Листинг 11.31
class GeneralLogger extends Loginobserver
{

public function doUpdate(Login $login)

{
$status = $login->getStatus () ;
// записать данные регистрации в системный журнал
print __ CLASS__ .
Регистрация в системном журнале\п";

}
}

// Листинг 11.32

class PartnershipTool extends Loginobserver

{
public function doUpdate(Login $login)
{

$status = $login->getStatus () ;
// проверяем IP-адрес

344

ЧАСТЬ III я ШАБЛОНЫ
// отправим cookie-файл, если адрес соответствует списку
print __ CLASS__ .
Отправка cookie-файла, если адрес соответствует списку\п";

}
}

Теперь создание и подключение к субъекту класса типа Loginobserver вы
полняются сразу во время создания его экземпляра.
$login = new Login();
new SecurityMonitor($login);
new GeneralLogger($login);
new PartnershipTool($login);

Таким образом, мы установили гибкую связь классов субъектов и наблюда
телей. Диаграмма классов для рассматриваемого здесь примера приведена на
рис. 11.6.

Рис. 11.6. Пример применения шаблона Observer

ГЛАВА 11 S ВЫПОЛНЕНИЕ ЗАДАЧ И ПРЕДСТАВЛЕНИЕ РЕЗУЛЬТАТОВ

345

В языке РНР обеспечивается встроенная поддержка шаблона Observer че
рез входящее в комплект стандартное расширение SPL (Standard РНР Library,
или стандартная библиотека РНР), которое является набором инструменталь
ных средств, помогающих решать распространенные задачи ООП. Расширение
SPL как универсальный аспект шаблона Observer состоит из следующих трех
элементов: SplObserver, SplSubject и SplObjectStorage. В частности,
SplObserver и SplSubject — это интерфейсы, которые являются точной ана
логией интерфейсов Observer и Observable из примера, приведенного ранее в
данном разделе, a SplObj ectStorage — вспомогательный класс, обеспечиваю
щий улучшенное сохранение и удаление объектов. Ниже приведена измененная
версия реализации шаблона Observer.
// Листинг 11.33
class Login implements \SplSubject

{
private $storage;
// ...

public function __ construct ()

{
$this->storage = new \SplObjectStorage ();
}

public function attach(\SplObserver Sobserver)
{
$this->storage->attach(^observer);
}

public function detach(\SplObserver Sobserver)
{
$this->storage->detach($observer);
}

public function notify ()
{
foreach ($this->storage as $obs)
$obs->update($this);
}
}
// ...

{

}

// Листинг 11.34
abstract class Loginobserver implements \SplObserver

{
private $login;

public function __ construct(Login $login)
{
$this->login = $login;
$login->attach($this);

346

ЧАСТЬ III И ШАБЛОНЫ

public function update(\SplSubject $subject)
{
if ($subject === $this->login) {
$this->doUpdate($subject);
}
}
abstract public function doUpdate(Login $login);
}

Что касается интерфейсов SplObserver и SplSubject, то не существует
никаких реальных их отличий от интерфейсов Observer и Observable, за ис
ключением, конечно, того, что больше не нужно объявлять интерфейсы, а только
изменить указания типов в параметрах методов в соответствии с новыми имена
ми. А класс SplObj ectStorage предоставляет действительно полезные услуги.
Вы, вероятно, заметили, что в первоначальном примере при реализации метода
Login: :detach () мы перебирали в цикле все объекты типа Observable, со
храненные в массиве $observable, чтобы найти и удалить объект аргумен
та. Класс SplObj ectStorage выполняет всю эту рутинную работу подспудно.
В нем реализованы методы attach () и detach (), а его объект можно указать
в цикле foreach для перебора подобно массиву.
НА ЗАМЕТКУ. За более подробными сведениями о расширении SPL обращайтесь к до

кументации на РНР по адресу http://www.php.net/spl. Там вы, в частности,
найдете немало инструментальных средств итераторов. А о встроенном в РНР интер
фейсе Iterator речь пойдет в главе 13, “Шаблоны баз данных”.

Еще один подход к решению задачи взаимодействия субъекта типа
Observable с наблюдателем типа Observer состоит в том, что методу
update () можно передать конкретные сведения о состоянии, а не экземпляр
субъекта типа Observable. Такой подход обычно выбирается в качестве ско
роспелого решения, поэтому в данном примере методу update () следовало бы
передать код состояния, имя пользователя и IP-адрес (возможно, в массиве ради
переносимости), а не экземпляр класса Login. Благодаря этому нам не при
шлось бы создавать в классе Login отдельный метод для получения состояния.
Но поскольку в классе субъекта сохраняется немало сведений о состоянии, то
передача его экземпляра методу update () дает наблюдателям возможность дей
ствовать намного более гибко.
Кроме того, тип аргумента можно зафиксировать полностью, чтобы класс
Login оперировал только классом наблюдателя определенного типа (вероят
но, типа Loginobserver). Для этого следует предусмотреть во время выпол
нения программы проверку типов объектов, переданных методу attach ().
В противном случае, возможно, придется полностью пересмотреть интерфейс
Observable.

ГЛАВА 11 « ВЫПОЛНЕНИЕ ЗАДАЧ И ПРЕДСТАВЛЕНИЕ РЕЗУЛЬТАТОВ

347

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

Шаблон Visitor
Как было показано ранее, многие шаблоны предназначены для создания
структур данных во время выполнения программы, следуя принципу, по кото
рому композиция обладает большей гибкостью, чем наследование. Характерным
тому примером служит вездесущий шаблон Composite. Когда вы работаете с
коллекциями объектов, вам может понадобиться выполнять над структурой раз
личные операции, в результате которых задействуется каждый ее отдельный
компонент. Такие операции могут быть встроены в сами компоненты. Ведь ком
поненты зачастую лучше всего предназначены для взаимного вызова.
Такой подход не лишен недостатков. У вас не всегда имеются сведения обо
всех операциях, которые, возможно, потребуется выполнить над структурой.
Если вы добавляете поддержку новых операций в классы от случая к случаю,
то в результате ваш интерфейс может обрасти ненужными функциями, которые
на самом деле не характерны для него. Как вы уже, вероятно, догадались, эти
недостатки позволяет устранить шаблон Visitor.

Проблема
Напомним пример применения шаблона Composite из предыдущей главы,
где для игры мы создали армию компонентов таким образом, чтобы можно было
попеременно обращаться как с целым, как и с отельными его частями. В дан
ном примере было показано, что операции можно встраивать в компоненты. Как
правило, объекты листьев выполняют операцию, а составные объекты вызывают
свои дочерние объекты, чтобы выполнить эту операцию, как показано ниже.
// Листинг 11.35

class Army extends CompositeUnit
{
public function bombardstrength () : int

{
$strength = 0;
foreach ($this->units () as $unit) {
$strength += $unit->bombardStrength();
}
return $strength;

348

ЧАСТЬ III В ШАБЛОНЫ

// Листинг 11.36

class LaserCannonUnit extends Unit
{
public function bombardstrength () : int

{
return 44;
}

}

Если конкретная операция является неотъемлемой частью и входит в обязан
ности класса составного типа, то никакого затруднения не возникает. Но ведь
существуют и более второстепенные задачи, которые могут не так удачно впи
саться в интерфейс.
Ниже приведен пример операции, выводящей текстовую информацию о ли
стовых узлах. Ее можно добавить в качестве метода в абстрактный класс Unit:
// Листинг 11.37

abstract class Unit
{
// ...
public function textDump($num = 0): string
{
$txtout =
$pad = 4*$num;
$txtout .= sprintf(”%{$pad}s", "");
$txtout .= get_class($this).": " ;
$txtout .= "Огневая мощь: ".$this->bombardStrength()."\n";
return $txtout;
}
// ...
}

Данный метод можно затем переопределить в классе CompositeUnit следу
ющим образом:
// Листинг 11.38

abstract class CompositeUnit extends Unit
{
// . . .
public function textDump($num = 0): string
{
$txtout = parent::textDump($num);
foreach ($this->units as $unit) {
$txtout .= $unit->textDump($num + 1);
}
return $txtout;
}
}

Теперь, продолжая в том же духе, мы должны создать методы для подсчета
количества боевых единиц в иерархическом дереве для сохранения компонентов
в базе данных и для подсчета количества единиц пищи, потребленной армией.

ГЛАВА 11

ВЫПОЛНЕНИЕ ЗАДАЧ И ПРЕДСТАВЛЕНИЕ РЕЗУЛЬТАТОВ

349

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

Реализация
Начнем с интерфейсов и определим в абстрактном классе Unit метод
accept().
// Листинг 11.39
abstract class Unit
{
protected $depth = 0;

// ...
public function accept(ArmyVisitor $visitor)
{

$refthis = new \ReflectionClass(get_class($this) ) ;
$method = "visit".$refthis->getShortName();
$visitor->$method($this);
}

protected function setDepth($depth)
{

$this->depth=$depth;
}

public function getDepth()
{

return $this->depth;
}
}

Как видите, метод accept () ожидает, что ему будет передан объект типа
ArmyVisitor. В языке РНР можно динамически указать метод в объекте типа
ArmyVisitor, который требуется вызвать. Поэтому мы составили имя такого
метода на основании имени текущего класса и вызвали его для переданного в ка
честве параметра объекта типа ArmyVisitor. Так, если текущим является класс
Army, вызывается метод ArmyVisitor: :visitArmy (), а если это класс TroopCarrier, то вызывается метод ArmyVisitor: :visitTroopCarrier() и т.п.

350

ЧАСТЬ III ж ШАБЛОНЫ

Это дает возможность не реализовывать метод accept () на каждом листо
вом узле иерархии классов. Для большего удобства мы ввели еще два метода,
getDepth() и setDepthQ, чтобы сохранять и извлекать величину глубины
вложенности элемента в иерархическом дереве. В частности, метод set Depth ()
вызывается из метода CompositeUnit: :addUnit () родителем элемента, когда
тот вводит его в иерархическое дерево:
// Листинг 11.40

abstract class CompositeUnit extends Unit
{

protected $units = array();
/ / ...

public function addUnit(Unit $unit)
{
foreach ($this->units as $thisunit)
if ($unit === $thisunit) {
return;

{

}
}

$unit->setDepth($this->depth+l);
$this->units[] = $unit;
}

public function accept(ArmyVisitor $visitor)
{

parent::accept($visitor) ;
foreach ($this->units as $thisunit)
$thisunit->accept($visitor) ;

{

}
}
}

В приведенный выше фрагмент кода было также введено определение ме
тода accept (). Вызов метода Unit:: accept () аналогичен вызову метода
visit () для предоставляемого объекта типа ArmyVisitor. На самом деле ме
тод accept () переопределяет аналогичную операцию в родительском классе,
поэтому данный метод позволяет делать следующее:
ж вызывать подходящий метод visit () для текущего компонента;

ж передавать объект посетителя всем текущим дочерним элементам с по
мощью метода accept (), при условии, что текущий компонент является
составным.

Но мы должны еще определить интерфейс для класса ArmyVisitor. И каку
ю-то информацию для этого должны предоставить методы accept (). В классе
посетителя должны быть определены методы accept () для каждого конкрет
ного класса в иерархии. Это позволит обеспечить разные функциональные воз
можности для различных объектов. В приведенной ниже версии данного класса

ГЛАВА 11 в ВЫПОЛНЕНИЕ ЗАДАЧ И ПРЕДСТАВЛЕНИЕ РЕЗУЛЬТАТОВ

351

определен также стандартный метод visit (), который вызывается автомати
чески, если в реализующих его классах принимается решение не выполнять
специальную обработку для определенных классов Unit.
// Листинг 11.41
abstract class ArmyVisitor

{
abstract public function visit(Unit $node);
public function visitArcher(Archer $node)

{
$this->visit($node);
}

public function visitCavalry(Cavalry $node)
{

$this->visit($node);

}
public function visitLaserCannonUnit(LaserCannonUnit $node)

{
$this->visit($node);

}
public function visitTroopCarrierUnit(TroopCarrierUnit $node)

{
$this->visit($node);

}
public function visitArmy(Army $node)

{
$this->visit($node);

}
}

Теперь остается только вопрос предоставления реализаций класса
ArmyVisitor, и мы готовы его решить. Ниже приведен простой пример кода,
выводящего текстовую информацию и заново реализованного на основе объекта
типа ArmyVisitor.
// Листинг 11.42
class TextDumpArmyVisitor extends ArmyVisitor
{

private $text =
public function visit(Unit $node)
{

$txt
$pad
$txt
$txt
$txt

=
= 4*$node->getDepth();
.= sprintf ( "% { $pad} s" f
. = get_class($node) .":
.= "Огневая мощь: ".$node->bombardStrength () ."\n";

352

ЧАСТЬ III И ШАБЛОНЫ
$this->text .= $txt;

}
public function getText()

{
return $this->text;
}

}

А теперь рассмотрим клиентский код, а далее пройдемся по всему процессу.
// Листинг 11.43

$main_army = new Army();
$main_army->addUnit(new Archer() ) ;
$main_army->addUnit(new LaserCannonUnit());
$main_army->addUnit(new Cavalry());
$textdump = new TextDumpArmyVisitor();
$main_army->accept($textdump);
print $textdump->getText();

Выполнение данного фрагмента кода приведет к следующему результату:
Army: Огневая мощь: 50
Archer: Огневая мощь: 4
LaserCannonUnit: Огневая мощь: 44
Cavalry: Огневая мощь: 2

В данном примере мы создаем объект типа Army. Этот объект является со
ставным, и поэтому в нем имеется метод addUnit (), с помощью которого мож
но добавлять дополнительные объекты типа Unit. Затем мы создаем объект типа
TextDumpArmyVisitor и передаем его методу Army: :accept (). В этом методе
на ходу составляется имя вызываемого метода и далее делается вызов TextDump
ArmyVisitor: :visitArmy (). В данном случае мы не обеспечили специальной
обработки объектов типа Army, и поэтому составленный в итоге вызов переда
ется обобщенному методу visit () наряду со ссылкой на объект типа Army.
Он вызывает свои методы (включая и вновь добавленный метод getDepth (),
который сообщает всем, кому это следует знать, степень глубины вложения эле
мента в иерархии объектов), чтобы сформировать итоговые данные. По завер
шении вызова метода visitArmy () выполняется операция Army: :accept (), в
ходе которой метод accept () по очереди вызывается для дочерних объектов, и
ему передается объект посетителя. Таким образом, в классе ArmyVisitor про
исходит посещение каждого объекта в иерархическом дереве.
Введя всего пару методов, мы создали в итоге механизм, посредством кото
рого можно внедрять новые функциональные возможности в классы составного
типа, не ухудшая их интерфейс и не дублируя в большом количестве код обхода
иерархического дерева.
На некоторых клетках в рассматриваемой здесь игре армии должны пла
тить налоги. Сборщик налогов посещает армию и берет плату за каждую

ГЛАВА 11 ш ВЫПОЛНЕНИЕ ЗАДАЧ И ПРЕДСТАВЛЕНИЕ РЕЗУЛЬТАТОВ

353

обнаруженную в ней боевую единицу (или подразделение). Разные подразделе
ния должны платить разные суммы налогов. И здесь мы можем воспользоваться
преимуществами специализированных методов в классе посетителя.
// Листинг 11.44

class TaxCollectionVisitor extends ArmyVisitor

{
private $due = 0;
private $report =

public function visit(Unit $node)

{
$this->levy($node,

1);

}
public function visitArcher(Archer $node)

{
$this->levy($node, 2);

}
public function visitCavalry(Cavalry $node)

{
$this->levy($node,

3);

}
public function visitTroopCarrierUnit(TroopCarrierUnit $node)

{
$this->levy($node,

5) ;

}
private function levy(Unit $unit, int $amount)

{
$this->report .= "Налог для " . get_class($unit);
$this->report .=
$amount\n";
$this->due += $amount;

}
public function getReport()

{
return $this->report;

}
public function getTax ()

{
return $this->due;

}
}

В этом простом примере мы не пользуемся непосредственно объектами типа
Unit, передаваемыми различным методам типа visit. Но в то же время мы
пользуемся специализированным характером этих методов, взимая различные
суммы налогов, исходя из конкретного типа вызывающего объекта типа Unit.
Ниже приведенконкретный пример клиентского кода.

354

ЧАСТЬ III « ШАБЛОНЫ

// Листинг 11.45

$main_army = new Army();
$main_army->addUnit(new Archer());
$main_army->addUnit(new LaserCannonUnit());
$main_army->addUnit(new Cavalry());

$taxcollector = new TaxCollectionVisitor();
$main_army->accept($taxcollector);
print $taxcollector->getReport();
print ’’ИТОГО: ’’;
print $taxcollector->getTax() . ”\n";

Объект типа TaxCollectionVisitor передается, как и прежде, методу
accept () объекта типа Army. И снова объект типа Army передает ссылку на
себя методу visitArmy (), прежде чем вызывать метод accept () для своих
дочерних объектов. Но этим компонентам ничего неизвестно, какие именно опе
рации выполняет их посетитель. Они просто взаимодействуют с их общедоступ
ным интерфейсом, причем каждый из них добросовестно передаст ссылку на
себя методу соответствующего типа.
В дополнение к методам, определенным в классе ArmyVisitor, класс
TaxCollectionVisitor предоставляет два итоговых метода getReportO и
getTax (). В результате вызова этих методов предоставляются данные, которые
и предполагалось получить.
Налог для
Налог для
Налог для
Налог для
ИТОГО: 7

Army: 1
Archer: 2
LaserCannonUnit: 1
Cavalry: 3

На рис. 11.7 показаны классы из данного примера.

Рис. 11.7. Пример применения шаблона Visitor

ГЛАВА 11 ® ВЫПОЛНЕНИЕ ЗАДАЧ И ПРЕДСТАВЛЕНИЕ РЕЗУЛЬТАТОВ

355

Трудности реализации шаблона visitor
Шаблон Visitor является еще одним проектным шаблоном, сочетающим в
себе простоту и эффективность. Но применяя этот шаблон, не следует забывать
некоторые особенности его реализации.
Несмотря на то что шаблон Visitor идеально приспособлен для примене
ния вместе с шаблоном Composite, на самом деле его можно применять с лю
бой коллекцией объектов. В частности, его можно применять вместе со списком
объектов, где каждый объект сохраняет ссылку на родственные объекты (т.е. на
узлы одного уровня в иерархическом дереве).
Но вынося операции наружу, мы рискуем нарушить инкапсуляцию, т.е. нам,
возможно, придется раскрыть внутреннее содержимое посещаемых объектов,
чтобы посетители могли сделать с ними что-нибудь полезное. Например, в пер
вом примере применения шаблона Visitor мы были вынуждены ввести допол
нительный метод в интерфейсе класса Unit, чтобы предоставить необходимые
сведения для объектов типа TextDumpArmyVisitor. С этой дилеммой мы уже
сталкивались в шаблоне Observer.
Сам процесс итерации отделен от операций, которые выполняют объекты
посетителей, поэтому придется в какой-то степени ослабить контроль. Нельзя,
например, так просто создать метод visit (), который что-то делает как до, так
и после обхода дочерних узлов иерархического дерева. Это затруднение можно,
например, разрешить, передав ответственность за выполнение итерации объек
там посетителей. Но дело в том, что это может привести к дублированию кода
обхода узлов иерархического дерева в каждом посетителе.
По умолчанию код обхода узлов иерархического дерева лучше оставлять в
посещаемых объектах. Но его вынесение наружу даст следующее явное пре
имущество: возможность изменять способ обработки посещаемых объектов в
зависимости от конкретного посетителя.

Шаблон Command
В последние годы я редко завершал веб-проект, не применяя этот шаблон.
Командные объекты, первоначально рассматриваемые в контексте проектирова
ния графического интерфейса, способствуют удачному проектированию корпо
ративного приложения, поддерживают разделение между уровнями контроллера
(обработки запросов и диспетчеризации) и моделью предметной области (ло
гики работы приложения). Проще говоря, шаблон Command помогает создавать
хорошо организованные системы, которые легко поддаются расширению.

Проблема
Во всех проектируемых системах должно приниматься решение, что делать
в ответ на запрос пользователя. В языке РНР процесс принятия решения ча
сто осуществляется с помощью ряда отдельных контактных страниц. Выбирая

356

ЧАСТЬ III

ШАБЛОНЫ

такую страницу (feedback.php), пользователь явно дает понять функциональ
ным средствам и интерфейсу, что именно ему требуется. Все чаще програм
мирующие на РНР делают выбор в пользу единственной контактной страницы
(этот подход будет обсуждаться в следующей главе). Но в любом случае полу
чатель запроса должен передать полномочия уровню, более тесно связанному с
логикой приложения. Такое делегирование полномочий особенно важно, если
пользователь может сделать запросы на разные страницы. В противном случае
дублирование кода в проекте неизбежно.
Допустим, что у нас имеется проект с рядом задач, которые необходимо ре
шить. В частности, проектируемая система должна разрешать одним пользова
телям входить в систему, а другим — оставлять отклики. Мы можем создать
страницы login.php и feedback.php, где решаются поставленные задачи,
получая экземпляры соответствующих специализированных классов, которые
и выполнят всю рутинную работу. К сожалению, пользовательский интерфейс
проектируемой системы редко соответствует в точности задачам, для решения
которых предназначена данная система. Например, функции входа в систему
и оставления откликов могут понадобиться на каждой странице. Если страни
цы должны решать много разных задач, то мы, вероятно, должны представлять
себе задачи как нечто такое, что можно инкапсулировать. Таким способом мы
упростим внедрение новых задач в проектируемую систему и построим гра
ницу между уровнями этой системы. И это, конечно, приведет нас к шаблону
Command.

Реализация
Интерфейс для командного объекта вряд ли может быть проще! Он тре
бует реализовать только один метод execute (). На рис. 11.8 класс Command
представлен как абстрактный. На таком уровне простоты его можно было бы
определить как интерфейс. Но в данном случае мы склонны воспользоваться
абстрактным классом, потому что базовый класс также может предоставить по
лезные общие функциональные возможности для своих производных объектов.

Command
^execute(context:CommondContext)

Рис. 11.8. Класс Command

В шаблоне Command может быть до трех других участников: клиент, который
создает экземпляр командного объекта; вызывающий участник, который исполь
зует этот объект; а также получатель, которым оперирует команда.
Получатель может быть передан командному объекту клиентским кодом
через конструктор или запрошен из какого-нибудь объекта фабрики. Более
предпочтительным выглядит второй подход, который состоит в применении

ГЛАВА 11 ® ВЫПОЛНЕНИЕ ЗАДАЧ И ПРЕДСТАВЛЕНИЕ РЕЗУЛЬТАТОВ

357

конструктора класса Command без аргументов. И тогда экземпляры всех объек
тов класса Command могут быть созданы одним и тем же способом.
Ниже приведено определение абстрактного класса Command.
// Листинг 11.46

abstract class Command
{
abstract public function execute (
Commandcontext $context): bool;

}

А так выглядит определение конкретного класса, расширяющего класс
Command:
// Листинг 11.47
class LoginCommand extends Command

{
public function execute(Commandcontext $context): bool
{

$manager = Registry::getAccessManager ();
$user = $context->get(’username;
$pass = $context->get('pass’);
$user_obj = $manager->login($user, $pass);
if (is_null($user_obj)) {
$context->setError($manager->getError());
return false;
}
$context->addParam("user",
return true;

$user_obj);

)
}

Класс LoginCommand предназначен для работы с объектом воображаемо
го класса AccessManager. Этот класс предназначен для управления меха
низмом входа пользователей в систему. Обратите внимание на то, что методу
Command:: execute () требуется передать объект типа Commandcontext (в упо
минавшейся ранее книге Core J2EE Patterns он называется RequestHelper).
Эго механизм, посредством которого данные запроса могут быть переданы объ
ектам типа Command, а ответы — отправлены назад на уровень представления.
Использовать объект подобным способом полезно, потому что командам можно
передать разные параметры, не нарушая интерфейс. Класс Commandcontext,
по существу, служит оболочкой для ассоциативного массива переменных, хотя
он часто расширяется для выполнения дополнительных полезных задач. Ниже
приведен пример простой реализации класса Commandcontext.
// Листинг 11.48

class Commandcontext

358

ЧАСТЬ III » ШАБЛОНЫ

private $params = [];
private $error =
public function __ construct ()
{
$this->params = $_REQUEST;
}
public function addParam(string $key,
{
$this->params[$key] = $val;

$val)

}
public function get(string $key): string
{
if (isset($this->params [$key] ) ) {
return $this->params[$key];
}
return null;

}

public function setError($error): string
{
$this->error = $error;
}

public function getError(): string
{
return $this->error;
}

}

Итак, снабженный объектом типа CommandContext, класс LoginCommand
может получить доступ к полученным данным запроса: имени пользователя и
паролю. Мы используем простой класс Registry со статическими методами для
формирования общих объектов. Он возвращает объект типа AccessManager,
которым будет оперировать класс LoginCommand. Если при выполнении мето
да login () из объекта типа AccessManager происходит ошибка, то сообще
ние об ошибке сохраняется в объекте типа CommandContext, чтобы его можно
было отобразить на уровне представления, а также возвращается логическое
значение false. Если же все в порядке, то метод execute () из объекта типа
LoginCommand просто возвратит логическое значение true.
Обратите внимание на то, что сами объекты типа Command выполняют мало
логических операций. Они проверяют входные данные, обрабатывают ошибки
и сохраняют данные, а также вызывают методы из других объектов для вы
полнения соответствующих операций. Если окажется, что логика приложения
вкралась в командные классы, это послужит явным признаком, что следует рас
смотреть возможность реорганизации кода. Ведь такой код способствует дубли
рованию, поскольку он неизбежно копируется и вставляется из одной команды
в другую. Следует хотя бы выяснить, к чему относятся такие функциональные

ГЛАВА 11 Ш ВЫПОЛНЕНИЕ ЗАДАЧ И ПРЕДСТАВЛЕНИЕ РЕЗУЛЬТАТОВ

359

средства. Возможно, их лучше всего переместить в объекты, содержащие ло
гику приложения, или на уровень фасада. В рассматриваемом здесь примере
нам еще недостает клиента — класса, формирующего командные объекты, и
вызывающего участника — класса, который оперирует сформированной коман
дой. Самый простой способ выбрать экземпляры командных объектов, которые
требуется получить в веб-проекте, — указать параметр в самом запросе. Ниже
приведен пример упрощенной реализации клиента.
// Листинг 11.49

class CommandNotFoundException extends Exception {}
class CommandFactory {
private static $dir = ’commands’;

public static function getCommand(
string $action = ’Default’): Command {
if ( preg_match ( ’/\W/', $action ) ) {
throw new Exception (’’Недопустимые символы в команде’’);

}
$class = UCFirst (strtolower ($action) ) . "Command";
$file = self::$dir . DIRECTORY-SEPARATOR . "{$class}.php";
if ( ! file_exists( $file ) ) {
throw new CommandNotFoundException( "Файл ’$file' не найден" );
}
require_once( $file );
if ( ! class_exists ( $class ) ) {
throw new CommandNotFoundException( "Класс ’$class’ не обнаружен"

) ;

}
$cmd = new $class () ;
return $cmd;
}
}

Класс CommandFactory просто ищет в каталоге commands определенный
файл класса. Имя этого файла составляется из параметра $action объекта
Commandcontext, который, в свою очередь, был передан системе из запроса.
К нему добавляется строка "Command” и расширение ” .php”. Если такой файл
найден и класс существует, то он возвращается вызывающему коду. Здесь мож
но задействовать механизм автозагрузки классов по шаблону Composer, тогда
нам не нужно будет явным образом включать класс в наш код. Можно также
ввести еще больше операций проверки ошибок, чтобы убедиться, что найден
ный класс принадлежит семейству Command и что конструктор не ожидает аргу
ментов, но приведенный выше вариант полностью подходит для наших учебных
целей. Преимущество такого подхода заключается в том, что новый объект типа
Command можно в любой момент добавить в каталог commands, и система сразу
же станет поддерживать его.
Теперь проще простого определить вызывающий объект, как показано ниже.

360

ЧАСТЬ III И ШАБЛОНЫ

// Листинг 11.50

class Controller

{
private $context;

public function __ construct()

{
$this->context = new CommandContext();
}

public function getContext (): CommandContext
{
return $this->context;

}
public function process ()

{
$action = $this->context->get('action');
$action = ( is_null($action) ) ? "default" : $action;
$cmd = CommandFactory::getCommand($action);
if (! $cmd->execute($this->context)) {
// обработать неудачный исход операции
} else {
// удачный исход операции: отобразить представление

}
}

}
// Листинг 11.51

$controller = new Controller ();
$context = $controller->getContext();

$context->addParam(’action’, ’login'
$context->addParam('username', 'bob'
$context->addParam('pass’, 'tiddies'
$controller->process () ;

);
);
);

print $context->getError();

Прежде чем вызвать метод Controller::process (), мы имитируем веб-за
прос, задавая его параметры в объекте типа CommandContext, экземпляр кото
рого создан в конструкторе контроллера. В методе process () запрашивается
значение параметра ’’action”, и если оно не существует, то в качестве запасно
го варианта выбирается символьная строка ’’default". Затем метод process ()
делегирует объекту типа CommandFactory создание экземпляров командных
объектов, после чего он вызывает метод execute () для возвращенного команд
ного объекта. Обратите внимание на то, что контроллеру вообще неизвестно
внутреннее содержимое командного объекта. Именно эта независимость от под
робностей выполнения команды дает нам возможность вводить новые классы
Command, не оказывая никакого воздействия на систему в целом.

ГЛАВА 11 я ВЫПОЛНЕНИЕ ЗАДАЧ И ПРЕДСТАВЛЕНИЕ РЕЗУЛЬТАТОВ

361

Ниже приведен еще один класс типа Command.
// Листинг 11.52

class Feedbackcommand extends Command

{
public function execute(CommandContext $context): bool

{
$msgSystem = Registry::getMessageSystem();
$email = $context->get(’email’);
$msg = $context->get(’msg');
$topic = $context->get('topic’);
$result = $msgSystem->send($email, $msg, $topic);
if ( ! $result) {
$context->setError($msgSystem->getError());
return false;

}
return true;

}

НА ЗАМЕТКУ. Мы еще вернемся к шаблону Command в главе 12, “Шаблоны корпоратив

ных приложений”, где будет представлена более полная реализация класса фабрики
Command. А описанная здесь структура выполнения команд является упрощенной
версией другого шаблона — Front Controller, рассматриваемого далее в этой
книге.

Этот класс будет вызван в ответ на получение из запроса символьной строки
"feedback”, соответствующей параметру ’action’. И для этого не придется
вносить никаких изменений в контроллер или класс CommandFactory. Нужно
просто поместить файл класса FeedbackConunand.php в каталог commands.
На рис. 11.9 приведены все участники шаблона Command.

Шаблон Null Object
Половина затруднений, с которыми сталкиваются программисты, связана с
типами данных. Именно поэтому в языке РНР постепенно развивалась поддерж
ка контроля типов в объявлениях методов и при возвращении из них значений.
Если трудности вызывает обращение с переменной, содержащей значение не
верного типа, то не меньше хлопот связано с полным отсутствием значения ка
кого-нибудь типа в переменной. И это происходит постоянно, поскольку многие
функции возвращают значение null, когда в них не удается сформировать ка
кое-нибудь полезное значение. Избавить себя и других от этой напасти можно,
воспользовавшись в своих проектах шаблоном Null Object. Как будет пока
зано далее, если другие проектные шаблоны, рассмотренные ранее в этой гла
ве, служат для того, чтобы сделать что-нибудь существенное, то шаблон Null
Object предназначен для того, чтобы вообще ничего не делать, причем как
можно более корректно.

362

ЧАСТЬ III ® ШАБЛОНЫ

Рис. 11.9. Участники шаблона Command

Проблема
Если на метод возложена обязанность найти нужный объект и он не смог
этого сделать, то все что ему остается — просигнализировать о неудачном ис
ходе операции. Причиной тому может служить устаревшая информация, пре
доставленная вызывающим кодом, или недоступность искомого ресурса. Если
неудачный исход операции имеет катастрофические последствия, то, возможно,
следует выбрать вариант генерирования соответствующего исключения. Но за
частую требуется чуть более снисходительное решение. В таком случае возврат
значения null может оказаться удобным средством известить клиента о неудач
ном исходе операции.
Обратимся снова к рассматривавшемуся ранее примеру игры и допустим, что
в классе TileForces отслеживаются сведения о боевых единицах, находящих
ся в отдельной клетке. В данной игре поддерживаются локально сохраняемые
сведения о боевых единицах во всей системе, а компонент UnitAcquisition
отвечает за преобразование этих метаданных в массив объектов.
Ниже приведено объявление класса TileForces и его конструктора.

ГЛАВА 11 В ВЫПОЛНЕНИЕ ЗАДАЧ И ПРЕДСТАВЛЕНИЕ РЕЗУЛЬТАТОВ

363

// Листинг 11.53
class TileForces

{
private $units = [];
private $x;
private $y;
function __ construct(int $x, int $y, UnitAcquisition $acq)

{
$this->x = $x;
$this->y = $x;
$this->units = $acq->getUnits($this->x,

$this->y);

}
// ...

}

Объект типа TileForces лишь поручает объекту типа UnitAcquisition,
передаваемому его конструктору в качестве параметра, получить массив объек
тов типа Unit. Создадим фиктивный объект типа UnitAcquisition следую
щим образом:
// Листинг 11.54
class UnitAcquisition
{

function getUnits(int $x, int $y): array
{

// 1. Найти координаты x и у в локальных данных и
//
получить список идентификаторов боевых единиц
// 2. Обратиться к источнику и получить
//
полноценные сведения о боевых единицах
//А пока что подставим какие-нибудь фиктивные сведения о них
$army = new Army () ;
$army->addUnit(new Archer());
$ found = [
new Cavalry(),

null,
new LaserCannonUnit(),
$army
] ;
return $found;

}

}

В объекте данного класса сознательно не приведен процесс получения дан
ных типа Unit. Но в реальной системе должен, конечно, выполняться поиск
конкретных данных, а здесь мы довольствовались лишь несколькими опера
циями непосредственного получения экземпляров объектов. Обратите, однако,
внимание на коварное пустое значение null, заданное в массиве $ found. Оно
требуется на тот случай, если, например, клиент этой сетевой игры хранит ме
таданные, которые уже не совпадают с текущим состоянием данных на сервере.

364

ЧАСТЬ III В ШАБЛОНЫ

Имея в своем распоряжении массив объектов типа Unit, класс TileForces
может предоставить некоторые функциональные возможности, как показано
ниже.
// Листинг 11.55
// класс TileForces
public function firepower(): int
{
$power = 0;
foreach($this->units as $unit) {
$power += $unit->bombardStrength ();

}
return $power;
}

А теперь проверим написанный нами код в действии:
// Листинг 11.56

Sacquirer = new UnitAcquisition();
$tileforces = new TileForces(4, 2, $acquirer);
$power = $tileforces->firepower ();
print "Огневая мощь: {$power}\n";

Вследствие скрытного характера значения null этот код приводит к следу
ющей ошибке:
Error: Call to a member function bombardstrength () on null1

В методе TileForces: : firepower () перебирается массив $units и для
каждого объекта типа Unit вызывается метод bombardstrength (). Но попыт
ка вызвать этот метод для значения null, безусловно, приведет к ошибке. Наи
более очевидный выход из положения в данном случае состоит в том, чтобы
проверять каждый элемент массива, прежде чем обрабатывать его:
// Листинг 11.57
// Класс TileForces
public function firepower () : int

{

$power = 0;
foreach ($this->units as $unit)

{

if (! is_null($unit)) {
$power += $unit->bombardStrength ();

}
}
return $power;

}

1 Ошибка: вызов функции-члена bombardstrength () для пустого значения.

ГЛАВА 11 Ж ВЫПОЛНЕНИЕ ЗАДАЧ И ПРЕДСТАВЛЕНИЕ РЕЗУЛЬТАТОВ

365

Сама по себе обработка пустого значения не вызывает особых трудностей.
Но представьте версию класса TileForces, где выполняются самые разные
операции над элементами массива $units. Как только мы начнем размножать
проверку с помощью функции is null () в нескольких местах, то снова при
дем к конкретному образцу недоброкачественного кода. И зачастую избавиться
от параллельных фрагментов клиентского кода можно, воспользовавшись по
лиморфизмом вместо нескольких условных операторов. Это можно сделать и в
данном случае.

Реализация
Шаблон Null Object позволяет поручить классу ничего не делать с пред
полагаемым типом данных. В данном случае создадим по этому шаблону класс
NullUnit следующим образом:
// Листинг 11.58
class NullUnit extends Unit
{
public function bombardstrength () : int
{
return 0;
}
public function getHealth () : int
{
return 0;
}

public function getDepth(): int {
return 0;
}
}

В данном случае в классе NullUnit мы реализовали интерфейс Unit с по
мощью пустых методов, в которых ничего конкретного не делается. А теперь
можно внести исправления в класс UnitAcquisition и создать объект типа
NullUnit вместо пустого значения null.
// Листинг 11.59
public function getUnits(int $х,

{
$army = new Army () ;
$army->addUnit(new Archer());

$found = [
new Cavalry(),

new NullUnit () ,
new LaserCannonUnit(),
$army

1 ;
return $found;

int $у): array

366

ЧАСТЬ III Ж ШАБЛОНЫ

Теперь из клиентского кода в классе TileForces можно вызывать любые ме
тоды для элементов массива $units, в том числе и для объекта типа NullUnit,
без всяких осложнений и ошибок:
// Листинг 11.60
// Класс TileForces
public function firepower () : int {
$power = 0;
foreach($this->units as $unit) {
$power += $unit->bombardStrength ();
}

return $power;
}

Проанализируйте любой крупный проект и подсчитайте количество неизящ
ных проверок, которые разработчикам пришлось ввести в методы, возвращаю
щие пустые значения. Сколько таких проверок могло быть распространено по
всему проекту, если бы большинство разработчиков пользовались шаблоном
Null Object?
Безусловно, иногда требуется заранее знать, что придется оперировать пу
стым объектом. Самый очевидный способ сделать это состоит в том, чтобы
проверить объект с помощью операции instanceof. Но это менее изящный
способ, чем приведенная ранее проверка с помощью функции is null ().
Возможно, более изящным решением может стать добавление приведенного
ниже метода isNull () как в базовый класс (с возвратом логического значения
false), так и в класс, созданный по шаблону Null Object (с возвратом логи
ческого значения true).
// листинг 11.61

if (! $unit->isNull()) {
// сделать что-нибудь
} else {
print "Значение null - ничего не делаем!\п";

}

Это дает нам обоюдовыгодное решение. С одной стороны, можно благопо
лучно вызвать любой метод из объекта типа NullUnit, а с другой — запросить
состояние любого объекта типа Unit.

Резюме
Этой главой мы завершили исследование шаблонов ‘"Банды четырех”.
В ней мы разработали мини-язык и построили его интерпретатор по шаблону
Interpreter. Кроме того, мы обнаружили в шаблоне Strategy другой спо
соб применения композиции с целью увеличить степень гибкости и уменьшить

ГЛАВА 11 w ВЫПОЛНЕНИЕ ЗАДАЧ И ПРЕДСТАВЛЕНИЕ РЕЗУЛЬТАТОВ

367

потребность в повторном создании подклассов. А шаблон Observer позволяет
решить задачу извещения совершенно разных и меняющихся компонентов о со
бытиях в системе.
Затем мы снова воспользовались примером применения шаблона Composite
и с помощью шаблона Visitor выяснили, как осуществить вызов каждого
компонента из иерархического дерева и выполнить над ним многие операции.
Мы также показали, каким образом шаблон Command может помочь в создании
расширяемой многоуровневой системы. И, наконец, выяснили, как сэкономить
на целом ряде проверок пустых значений, воспользовавшись шаблоном Null
Object.
В следующей главе мы выйдем за рамки шаблонов “Банды четырех”, чтобы
исследовать некоторые проектные шаблоны, предназначенные для применения
при разработке корпоративных приложений.

ГЛАВА 12

Шаблоны корпоративных
приложений
Язык РНР, прежде всего, предназначен для применения в среде веб. И бла
годаря существенно расширенной поддержке объектов можно выгодно восполь
зоваться преимуществами шаблонов, разработанных в контексте других объек
тно-ориентированных языков программирования и, в частности, Java.
В этой главе мы будем пользоваться единственным примером для демон
страции описываемых в ней шаблонов. Но не забывайте, что, решив применить
один шаблон, вы не обязаны использовать все шаблоны, которые подходят для
работы с ним. Не считайте также, что представленные в этой главе реализа
ции — это единственный способ применения рассматриваемых в ней шабло
нов. Используйте приведенные в этой главе примеры, чтобы лучше понять суть
описываемых здесь шаблонов, и не стесняйтесь извлекать из них все полезное
для своих проектов.
В данной главе необходимо изложить довольно обширный материал, и по
этому это одна из самых длинных и сложных глав в книге, а следовательно,
прочитать ее за один присест будет трудно. Она подразделяется на введение и
две основные части, что поможет вам освоить материал поэтапно.
Отдельные шаблоны описываются сначала в разделе “Краткий обзор архи
тектуры”. И хотя они в какой-то степени взаимозависимы, вы можете свободно
перейти к описанию любого конкретного шаблона и проработать его отдельно
от других шаблонов, а в свободное время изучить связанные с ним проектные
шаблоны.
В этой главе будут рассмотрены следующие вопросы.

в Краткий обзор архитектуры. Знакомство с уровнями, из которых обычно
состоит корпоративное приложение.
« Шаблон Registry. Управление данными приложения.

370

ЧАСТЬ III

ШАБЛОНЫ

в Уровень представления данных. Средства для управления, а также для от
вета на запросы и представления данных для пользователя.
» Уровень логики приложения. Обращение к настоящей цели проектируемой
системы для решения коммерческих задач.

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

Шаблоны
В этой главе мы рассмотрим перечисленные ниже шаблоны. Можете читать
ее материал от начала до конца или же описание только тех шаблонов, которые
вам нужны или интересны в данный момент.

и Шаблон Registry. Служит для того, чтобы сделать данные доступными
для всех классов в текущем процессе. Если аккуратно пользоваться сериа
лизацией, то данный шаблон также можно применять для сохранения све
дений на протяжении всего сеанса работы или даже целого приложения.

« Шаблон Front Controller. Предназначен для крупных систем, где тре
буется максимально возможная степень гибкости при управлении различ
ными представлениями и командами.
w Шаблон Application Controller. Позволяет создавать классы для
управления логикой представления данных и выбором команд.

к Шаблон Template View. Позволяет создавать страницы для управления
только отображением данных и пользовательским интерфейсом, а также
динамически встраивать информацию в статические страницы, используя
как можно меньше кода.
ш Шаблон Page Controller. Это более легковесный, но менее гибкий, чем
Front Controller, шаблон, решающий те же самые задачи. Он приме
няется для управления запросами и логикой представления данных, если
требуется быстро получить результаты, хотя сложность системы от этого
существенно не увеличится.

ж Шаблон Transaction Script. Если требуется быстро решать задачи,
прибегая в минимальной степени к предварительному планированию, для
создания логики приложения следует использовать процедурный библио
течный код. Этот шаблон плохо поддается масштабированию.
« Шаблон Domain Model. Является полной противоположностью шаблона
Transaction Script. Он служит для создания объектных моделей бизнес-процессов и их участников.

ГЛАВА 12 ш ШАБЛОНЫ КОРПОРАТИВНЫХ ПРИЛОЖЕНИЙ

371

НА ЗАМЕТКУ. Шаблон Command не описывается здесь отдельно, поскольку это уже было

сделано в главе 11, “Выполнение задач и представление результатов”. Но он снова
применяется в этой главе вместе с шаблонами Front Controller и Application
Controller.

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

Рис. 12.1. Уровни типичной корпоративной системы

Структура, приведенная на рис. 12.1, не является чем-то неизменным: не
которые уровни в ней можно объединить, а для сообщения между ними могут
применяться другие стратегии, хотя это зависит от сложности проектируемой
системы. Тем не менее на рис. 12.1 наглядно показана модель, в которой делает
ся акцент на гибкость и повторное использование кода, и многие корпоративные
приложения в значительной степени следуют этой модели.

ж Уровень представления данных. Содержит интерфейс, который реально
видят и с которым взаимодействуют пользователи системы. Он отвечает
за представление результатов запроса пользователя и обеспечение меха
низма, посредством которого можно сделать следующий запрос системы.

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

372

ЧАСТЬ III

ШАБЛОНЫ

пользователю. На практике данный уровень часто объединяется вместе с
уровнем представления данных в единый уровень представления. Но даже
в этом случае роль отображения должна быть строго отделена от ролей
обработки запросов и вызова логики приложения.
Уровень логики приложения. Отвечает за обработку запроса. Выполняет
все необходимые вычисления и упорядочивает полученные в итоге данные.

Уровень данных. Отделяет остальную систему от механизма хранения
и получения необходимой информации. Уровень данных используется в
одних системах на уровне управления и команд для получения объектов
приложения, с которыми требуется работать. А в других системах уровень
данных скрывается настолько, насколько это возможно.
Так какой же смысл разделять систему подобным образом? Как и в отноше
нии многого другого в этой книге, ответ кроется в ослаблении связей. Поддер
живая логику приложения независимой от уровня представления данных, вы
делаете возможным ввод новых интерфейсов в систему вообще без изменений
или же с небольшими коррективами ее исходного кода.
Представьте себе систему управления списками событий (до конца этой гла
вы мы разберем данный пример достаточно подробно). Конечному пользова
телю требуется привлекательный HTML-интерфейс, что вполне естественно,
тогда как администраторам, поддерживающим систему, может понадобиться
интерфейс командной строки для встраивания в автоматизированные системы.
В то же время для работы с мобильными телефонами и другими портативны
ми устройствами требуется разработать разные версии системы, а возможно, и
применить для этого интерфейс SOAP или RESTful API.
Если вы первоначально объедините логику, лежащую в основе системы, с
уровнем представления в формате HTML (что до сих пор является распростра
ненной методикой, несмотря на многочисленные критические замечания по это
му поводу), эти требования могут вынудить вас сразу же приступить к перепи
сыванию системы. А если вы спроектируете многоуровневую систему, то новые
методики представления данных можно будет внедрить, не пересматривая уров
ни логики приложения и данных.
Но в то же время методики сохранения данных подвержены изменениям.
И в этом случае должна быть возможность выбирать методики сохранения дан
ных с минимальным воздействием на другие уровни в системе.
Тестирование — это еще одна хорошая причина для проектирования си
стем с отдельными уровнями. Общеизвестно, что веб-приложения с трудом
поддаются тестированию. В системе, которая в недостаточной степени разде
лена на уровни, автоматические тесты должны, с одной стороны, согласовывать
HTML-интерфейс, а с другой — рискованно запускать произвольные запросы
базы данных, даже если они преследуют совсем другую цель. И хотя всякое те
стирование лучше, чем полное их отсутствие, такие тесты неизбежно вызывают

ГЛАВА 12

ШАБЛОНЫ КОРПОРАТИВНЫХ ПРИЛОЖЕНИЙ

373

беспорядок. В многоуровневой системе классы, которые обращаются к дру
гим уровням, часто создаются таким образом, чтобы расширять абстрактный
суперкласс или реализовывать определенный интерфейс. Этот супертип тогда
может поддерживать полиморфизм. В контексте тестирования весь уровень
может быть заменен рядом фиктивных объектов, которые нередко называют
ся “заглушками” или “имитирующими” объектами. Подобным образом можно
протестировать логику работы приложения, например, с помощью фиктивного
уровня данных. Подробнее о тестировании речь пойдет в главе 18, “Тестирова
ние средствами PHPUnit”.
Уровни полезны даже в том случае, если вы считаете, что тестирование ни
кому не нужно и что у вашей системы всегда будет только один интерфейс.
Создавая уровни с различными обязанностями, вы строите систему, составные
части которой легче расширять и отлаживать. Сохраняя код, выполняющий оди
наковые операции, в одном месте, а не пронизывая систему, например, мно
гочисленными обращениями к базе данных или стратегиями отображения ин
формации, вы тем самым уменьшаете вероятность дублирования кода. Ввести
что-нибудь в такую систему относительно просто, потому что изменения будут
происходить упорядоченно по вертикали, а не беспорядочно по горизонтали.
Новому функциональному средству в многоуровневой системе может потре
боваться новый компонент интерфейса, дополнительная обработка запросов,
дополнительная логика приложения и улучшение механизма хранения данных.
Такое изменение называется вертикальным. А в одноуровневой системе мож
но ввести новое функциональное средство, но затем вспоминать, на скольких
(пяти, а может быть, и на шести) страницах применяется измененная таблица
базы данных. В такой системе могут существовать десятки мест, где вполне ве
роятен вызов нового интерфейса. Поэтому придется просмотреть всю систему,
добавляя в нужных местах соответствующий код. Такое изменение называется
горизонтальным.
Разумеется, на практике вряд ли удастся полностью избежать подобного рода
горизонтальных зависимостей, особенно если речь идет об элементах навигации
в интерфейсе. Но многоуровневая система поможет свести к минимуму потреб
ность в горизонтальных изменениях.
НА ЗАМЕТКУ. Несмотря на то что многие из описываемых здесь шаблонов существуют

уже давно (ведь шаблоны являются отражением испытанных методов), их названия
и области применения взяты из упоминавшегося ранее основного труда Мартина
Фаулера по шаблонам корпоративных приложений Patterns of Enterprise Application
Architecture' или из авторитетного труда Дипака Алура Core J2EE Patterns2. При
расхождениях в этих двух источниках ради согласованности здесь употребляются
1 Мартин Фаулер. Шаблоны корпоративных приложений (пер. с англ., ИД “Вильямс”,
2009).

2 Дипак Алур, Джон Крупи, Дэн Малке. Образцы J2EE. Лучшие решения и стратегии
проектирования (пер. с англ., изд. “Лори”, 2013).

374

ЧАСТЬ III

ШАБЛОНЫ

условные обозначения имен шаблонов, принятые у Фаулера. Дело в том, что работа
Фаулера в меньшей степени сфокусирована на одной технологии и поэтому имеет
более широкое применение. Алур и другие в своей книге склонны ориентироваться
на технологию Enterprise Java Beans, а это означает, что многие шаблоны оптимизи
рованы для распределенных архитектур. Очевидно, что это вопрос ниши в мире РНР.

Если вы найдете эту главу полезной для себя, то я бы порекомендовал вам обе упо
мянутые книги в качестве следующего этапа обучения. Даже если вы не знаете Java,
то как специалист, занимающийся объектно-ориентированным программированием
на РНР, вы достаточно легко разберетесь в приведенных в них примерах.

Все примеры из этой главы связаны с вымышленной системой управления
текстовыми списками с причудливым наименованием “Woo”, которое обозна
чает “What’s On Outside” (Что идет во внешнем мире). К участникам системы
относятся различные культурные заведения (театры, клубы, кинотеатры), места
проведения культурных мероприятий (киноэкран или театральные подмостки)
и названия мероприятий (например, фильмы Долгая страстная пятница и Как
важно быть серьезным). К описываемым далее операциям относится создание
культурного заведения, ввод в него места проведения мероприятий и вывод спи
ска всех заведений в системе.
Не следует, однако, забывать, что назначение этой главы — продемонстриро
вать основные проектные шаблоны корпоративных приложений, а не спроекти
ровать рабочую систему. По своему характеру проектные шаблоны взаимозави
симы, и поэтому исходный код в большинстве представленных здесь примеров
частично совпадает. Этот код предназначен в основном для демонстрации кор
поративных шаблонов и по большей части не удовлетворяет всем критериям
рабочей корпоративной системы. В частности, проверка ошибок опущена ради
большей ясности кода примеров. Поэтому рассматривайте эти примеры как
средства для демонстрации реализуемых шаблонов, а не как стандартные блоки
для построения каркаса или приложения.

Нарушение правил с самого начала
Большинство шаблонов, представленных в этой книге, вписываются есте
ственным образом в отдельные уровни архитектуры корпоративного прило
жения. Но некоторые шаблоны являются настолько основополагающими, что
выходят за пределы этой архитектуры. Характерным тому примером служит ша
блон Registry. По существу, шаблон Registry предоставляет эффективный
способ выйти за пределы ограничений, накладываемых разделением на уровни.
Это исключение, которое только подтверждает общее правило.

Шаблон Registry
Этот шаблон предназначен для того, чтобы предоставлять доступ к объ
ектам во всей системе. Это своеобразный символ веры в то, что глобальные
переменные — зло. Но, как и остальные грехи, глобальные данные чертовски

ГЛАВА 12

ШАБЛОНЫ КОРПОРАТИВНЫХ ПРИЛОЖЕНИЙ

375

привлекательны. Поэтому архитекторы объектно-ориентированных систем по
чувствовали потребность изобрести глобальные данные заново, но под дру
гим именем. В главе 9, “Формирование объектов”, уже рассматривался шаблон
Singleton, хотя одноэлементные объекты-одиночки, создаваемые по шаблону
Singleton, действительно не страдают от всех бед, которые несут глобальные
переменные. В частности, одноэлементный объект нельзя случайно затереть.
Следовательно, одноэлементные объекты — это худосочные глобальные пере
менные. Но эти объекты все равно вызывают подозрение, потому что побужда
ют привязывать классы к системе, внося тем самым излишнюю тесную связь.
Тем не менее одноэлементные объекты иногда настолько полезны, что многие
программисты (включая меня) не могут отказаться от них.
Проблема

Как пояснялось ранее, многие корпоративные системы разделены на уровни,
причем каждый уровень сообщается с соседними уровнями только по строго
определенным каналам. Такое разделение на уровни делает приложение гиб
ким. В частности, каждый уровень можно заменить или переделать, оказав ми
нимальное воздействие на остальную систему. Но что произойдет, если полу
ченная на каком-то уровне информация впоследствии понадобится на другом
несмежном уровне?
Допустим, что сведения о конфигурации приложения загружаются в классе
ApplicationHelper, как показано ниже.
// Листинг 12.01

class ApplicationHelper
{
public function getOptions() : array
{
$optionfile = __ DIR__ . ”/data/woo_options .xml”;

if (! file_exists($optionfile)) {
throw new AppException("Файл с параметрами не найден”);
}
$options = simplexml_load_file($optionfile);
$dsn = (string) $options->dsn;
// Что с этим теперь делать?
// ...

}
}

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

376

ЧАСТЬ III

ШАБЛОНЫ

И это вполне осуществимо. По существу, передать можно сам объект типа
ApplicationHelper или же более специализированный объект типа Context.
Но в любом случае контекстно-зависимая информация из объекта типа Context
передается через уровни системы тому объекту или нескольким объектам, кото
рым она требуется.
Но здесь компромисс неизбежен: чтобы сделать это, придется изменить ин
терфейс всех объектов и включить в него объект типа Context независимо от
того, требуется ли им его использовать. Очевидно, что это в какой-то степени
подрывает слабую связанность объектов в приложении. Альтернативный вари
ант предоставляет упоминавшийся ранее шаблон Registry, но его применение
имеет свои последствия.
Реестр — это просто класс, который предоставляет доступ к данным (как
правило, но не исключительно, к объектам) через статические методы (или ме
тоды экземпляра, вызываемые для одноэлементных объектов). Поэтому у каж
дого объекта в системе имеется доступ к этим объектам.
Термин реестр (Registry) взят из упоминавшейся ранее книги Мартина Фа
улера Patterns of Enterprise Application Architecture, но, как это часто бывает
с наименованиями многих проектных шаблонов, они употребляются в разных
контекстах. Так, в своей книге The Pragmatic Programmer: from Journeyman to
Master Дэвид Хант (David Hunt) и Дэвид Томас (David Thomas) сравнили класс
Registry с доской объявлений о происшествиях в полиции. Агенты, работаю
щие в первую смену, оставляют на доске информацию о фактах и заметки, ко
торые затем забирают агенты, работающие во вторую смену. Мне также прихо
дилось видеть использование шаблона Registry под названиями Whiteboard
(Белая доска) и Blackboard (Черная доска).
Реализация

На рис. 12.2 показан объект типа Registry, предназначенный для сохране
ния и возврата объектов типа Request по запросу.
Г“ - - «Создает»
- — - - — - - l
I

____________ у___________

I
I

Registry
+instance(): Registry
+setRequest(request:Request)
+getRequest()

Рис. 12.2. Простой реестр

Ниже приведено определение классов Registry.
// Листинг 12.02

class Registry
{
private static $instance = null;
private $request;

ГЛАВА 12 » ШАБЛОНЫ КОРПОРАТИВНЫХ ПРИЛОЖЕНИЙ

377

private function __ construct ()
{
}

public static function instance (): self
{
if (is_null(self::$instance)) {
self::$instance = new self();
}
return self::$instance;
}

public function getRequest () : Request
{
if (is_null($this->request)) {
$this->request = new Request ();
}
return $this->request;
}
function setRequest ( Request $request )
$this->request = $request;
}

{

}
// Листинг 12.03

// пустой класс для проверки
class Request
{
}

Таким образом, доступ к одному и тому же объекту типа Request можно
получить в любой части системы, как показанониже.
// Листинг 12.04
$reg = Registry::instance ();
print_r($reg->getRequest());

Как видите, Registry — это обычный одноэлементный объект-синглтон
(напомним, что одноэлементные классы создаются по шаблону Singleton, см.
главу 9, “Формирование объектов”). В приведенном выше фрагменте кода с по
мощью метода instance () сначала получается и возвращается единственный
экземпляр класса Registry, а затем он используется для извлечения объекта
типа Request.
Отбросив заведомо всякие сомнения, воспользуемся системой сохранения па
раметров на основе ключей следующим образом:
// Листинг 12.05

class Registry
{
private static $instance=null;
private $values = [ ] ;

378

ЧАСТЬ III Я ШАБЛОНЫ

private function __ construct ()
{
}

public static function instance (): self

{
if (is_null(self::$instance) ) {
self::$instance = new self();

}
return self::$instance;

}

public function get(string $key)
{
if (isset($this->values[$key]))
return $this->values[$key];

{

}
return null;
}

public function set(string $key,

$value)

{

$this->values [$key]

= $value;

}
}

Преимущество такого подхода заключается в том, что отпадает необходи
мость создавать методы для каждого объекта, который требуется сохранять и
обслуживать, а его недостаток — в том, что глобальные переменные снова вво
дятся, так сказать, через “черный ход”. Использование произвольных символь
ных строк в качестве ключей для сохраняемых объектов означает следующее:
ничто не помешает изменить пару “ключ-значение” при добавления объекта в
одной из частей системы. В данном случае обнаружилось, что на стадии разра
ботки удобно воспользоваться структурой вроде отображения ключей на значе
ния, а когда станет ясно, какие именно данные требуется сохранить и извлечь,
можно будет перейти к явно именованным методам.
НА ЗАМЕТКУ. Шаблон Registry является не единственным способом организации

служб, которые требуются в проектируемой системе. Аналогичная стратегия по ша
блону Dependency Injection уже рассматривалась в главе 10, “Шаблоны для про
граммирования гибких объектов”. Она применяется в таких распространенных карка
сах, как Symfony.
Объекты реестра можно использовать также в качестве фабрик для общих
объектов в системе. Вместо сохранения предоставленного объекта, класс-реестр
создает экземпляр, а затем сохраняет в кеш-памяти ссылку на него. Кроме того,
можно незаметно осуществить некоторую настройку, например извлечь данные
из файла конфигурации или объединить ряд объектов.

ГЛАВА 12 № ШАБЛОНЫ КОРПОРАТИВНЫХ ПРИЛОЖЕНИЙ

379

// Листинг 12.06

// Класс Registry
private StreeBuilder = null;
private $conf = null;

// ...
public function treeBuilder(): TreeBuilder

{

if (is_null($this->treeBuilder)) {
$this->treeBuilder = new TreeBuilder (
$this->conf()->get(’treedir’));
}
return $this->treeBuilder;
}

public function conf () : Conf

{
if (is_null($this->conf)) {
$this->conf = new Conf ();

}
return $this->conf;

}

Классы TreeBuilder и Conf — вымышленные и включены в данный при
мер ради демонстрации сути рассматриваемого вопроса. Клиентский класс, ко
торому требуется объект типа TreeBuilder, может просто вызвать статический
метод Registry::treeBuilder (), не особенно беспокоясь о сложностях ини
циализации. К таким сложностям могут относиться данные уровня приложения,
например, из вымышленного объекта типа Conf, и большинство классов в си
стеме должны быть изолированы от них.
Объекты реестра можно использовать также для тестирования. В частно
сти, статический метод instance () можно вызвать для обслуживания объекта
класса, производного от класса Registry и заполненного пустыми объектами.
Ниже показано, как внести коррективы в метод instance (), чтобы достичь
этой цели.
// Листинг 12.07
// Класс Registry

private static $testmode = false;
// ...

public static function testMode(bool $mode = true)
{
self::$instance = null;
self::$testmode = $mode;
}

380

ЧАСТЬ III • ШАБЛОНЫ

public static function instance () : self
{
if (is_null(self::$instance)) {
if (self::$testmode) {
self::$instance = new MockRegistry();
} else {
self::$instance = new self();
}
}
return self::$instance;

}

Если требуется испытать спроектированную систему, то можно воспользо
ваться режимом тестирования, чтобы перейти к сымитированному реестру. Он
может предоставить заглушки (объекты, имитирующие реальную среду для це
лей тестирования) или имитирующие объекты (аналогичные объекты, предна
значенные для анализа сделанных для них вызовов и оценивания их правильно
сти). Подробнее о заглушках и имитирующих объектах речь пойдет в главе 18,
‘"Тестирование средствами PHPUnit”.
// Листинг 12.08
Registry::testMode ();
$mockreg = Registry::instance () ;

Реестр, область видимости и язык РНР

Термин область видимости (scope) часто употребляется для описания види
мости объекта или значения в контексте структур кода. Период существования
переменной можно также измерять во времени. Имеются три уровня области
видимости, которые можно рассматривать в этом смысле. Стандартом служит
период, охватывающий НТТР-запрос.
В языке РНР предусмотрена также встроенная поддержка сеансовых пере
менных. В конце запроса они сериализуются и сохраняются в файле или базе
данных, а затем снова восстанавливаются при поступлении следующего запро
са. Идентификатор сеанса связи, который сохраняется в cookie-файле или пере
дается в строке запроса, используется для отслеживания сведений о владельце
данного сеанса. Поэтому можно считать, что у некоторых переменных имеется
своя сеансовая область видимости. Этим преимуществом можно воспользовать
ся, сохраняя некоторые объекты в промежутках между запросами и тем самым
избавляя себя от необходимости обращаться к базе данных. Безусловно, это сле
дует делать очень аккуратно, чтобы не получить в итоге несколько версий одно
го и того же объекта. Поэтому нужно также подумать о стратегии блокировки,
если в результате проверки объекта в сеансе связи окажется, что аналогичный
объект уже существует в базе данных.
В других языках, особенно Java и Perl (который реализован в виде модуля
ModPerl веб-сервера Apache), существует понятие области видимости приложе
ния. Переменные, занимающие это пространство, доступны всем экземплярам

ГЛАВА 12 w ШАБЛОНЫ КОРПОРАТИВНЫХ ПРИЛОЖЕНИЙ

381

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

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

Уровень представления данных
Когда делается запрос в спроектированную вами систему, она должна ка
ким-то образом интерпретировать указанные в нем данные, а затем выполнить
всю необходимую обработку и возвратить ответ. В простых сценариях весь этот
процесс обычно полностью происходит в самом представлении, и только слож
ные вычислительные процедуры и повторяющиеся фрагменты кода размещают
ся в библиотеках.
НА ЗАМЕТКУ. Представление — отдельный элемент уровня отображения данных. Это

может быть PHP-страница (или совокупность составных элементов представления),
предназначенная, главным образом, для того, чтобы отображать данные и обеспе
чивать механизм, посредством которого пользователь может генерировать новые
запросы. Это может быть также один из шаблонов, применяемых в таких системах,
как Twig.
По мере увеличения масштабов приложения стандартная стратегия стано
вится менее подходящей для обработки запросов, вызова логики приложения,
поскольку логика диспетчеризации представления дублируется с одной страни
цы на другую.
В этом разделе мы рассмотрим стратегии управления этими тремя ключевы
ми обязанностями на уровне представления. А поскольку границы между уров
нем представления и уровнем команд и управления, как правило, весьма размы
ты, то их целесообразно рассматривать вместе под общим названием “уровень
представления”.

382

ЧАСТЬ III

ШАБЛОНЫ

Шаблон Front Controller
Этот шаблон диаметрально противоположен традиционному приложению на
РНР с его несколькими точками входа. Шаблон Front Controller (Фронталь
ный контроллер) предоставляет центральную точку доступа для обработки всех
входящих запросов и в конечном итоге поручает уровню представления вывод
полученных результатов для просмотра пользователем. Это основной шаблон
из семейства шаблонов корпоративных приложений Java. Он очень подробно
описан в упоминавшейся ранее книге Core J2EE Patterns: Best Practices and
Design Strategies, которая остается одним из самых авторитетных источников
по шаблонам корпоративных приложений. Но нельзя сказать, что все члены со
общества программирующих на РНР являются приверженцами этого шаблона,
отчасти из-за издержек на инициализацию, которые иногда неизбежны.
В большинстве разрабатываемых мною систем, как правило, используется
шаблон Front Controller. И хотя я могу поначалу использовать его не пол
ностью, но я знаю, какие шаги необходимо предпринять, чтобы развить проект
в реализацию шаблона Front Controller, если мне понадобится та степень
гибкости, которую он предоставляет.
Проблема

Когда запросы обрабатываются в нескольких точках системы, очень труд
но избежать дублирования кода. Вполне возможно, что потребуется аутентифи
цировать пользователя, перевести элементы интерфейса на другие языки или
просто получить доступ к общим данным. Так, если для запроса требуется вы
полнить общие для разных представлений действия, это неизбежно приведет
к копированию и вставке кода. Это усложнит внесение изменений, поскольку
даже самое простое исправление придется повторить в нескольких местах при
ложения. И по этой причине может быть нарушено соответствие одних частей
кода другим. Безусловно, общие операции можно централизовать, выделив их в
библиотечный код, но все равно останутся вызовы библиотечных функций или
методов, разбросанные по всему приложению.
Трудность в организации перехода от одного представления к другому — это
еще одно осложнение, которое может возникнуть в системе, где управление рас
пределено по представлениям. В сложной системе передача запроса на обработ
ку в одном представлении может привести к произвольному количеству страниц
результатов в соответствии с входными данными и успешностью выполнения
требуемых операций на уровне логики приложения. Логика перехода от одного
представления к другому может стать запутанной, особенно если одно и то же
представление используется в разных потоках.
Реализация

По существу, шаблон Front Controller определяет центральную точку
входа для обработки каждого запроса. Он организует обработку запроса, ис
пользуя его для того, чтобы выбрать операцию для последующего выполнения.

ГЛАВА 12 ж ШАБЛОНЫ КОРПОРАТИВНЫХ ПРИЛОЖЕНИЙ

383

Операции обычно определяются в специальных командных объектах, организо
ванных по шаблону Command.
На рис. 12.3 приведен общий вид реализации шаблона Front Controller.

Рис. 12.3. Класс Controller и иерархия команд

На самом деле, чтобы как-то сгладить процесс разработки, скорее всего, при
дется воспользоваться несколькими вспомогательными классами. Начнем, од
нако, с основных участников данного процесса. Ниже приведено определение
простого класса Controller.
// Листинг 12.09

class Controller

{
private $reg;

private function __ construct()
{
$this->reg = Registry::instance ();

}
public static function run()

{
$instance = new Controller ();
$instance->init () ;
$instance->handleRequest();

}

private function init()
{
$this->reg->getApplicationHelper()->init ();
}

private function handleRequest()
{

$request = $reg->getRequest();
$resolver = new CommandResolver();
$cmd = $resolver->getCommand($request);
$cmd->execute($request);

384

ЧАСТЬ III

ШАБЛОНЫ

Как видите, класс Controller очень прост и лишен всякой обработки оши
бок, но ведь в нем больше ничего пока что и не требуется. Контроллер находится
на вершине системы, делегируя полномочия другим классам. Именно эти дру
гие классы выполняют большую часть работы. Статический метод run () вве
ден ради удобства, чтобы вызывать в нем методы init () и handleRequest ().
А поскольку конструктор данного класса объявлен закрытым, то единственная
возможность начать выполнение проектируемой системы в клиентском коде со
стоит в том, чтобы вызвать метод run (). Обычно это делается в файле index.
php, который содержит лишь несколько строк кода, как показано ниже.
// Листинг 12.10

require_once(

DIR

.

/vendor/autoload.php");

use \popp\chl2\batch05\Controller;
Controller::run();

Обратите внимание на неприглядный вид оператора require. Он нужен для
того, чтобы в остальной части системы можно было не беспокоиться о включе
нии требующихся файлов. Сценарий из исходного файла autoload.php авто
матически формируется средствами Composer. Он управляет логикой загрузки
файлов классов по мере надобности. Если это ни о чем вам не говорит, не от
чаивайтесь — мы еще вернемся к подробному обсуждению механизма авто
загрузки в главе 16, “Создание и использование компонентов РНР средствами
Composer”.
На самом деле отличия методов init() и handleRequest () в языке РНР
едва уловимы. В некоторых языках метод init () выполняется только при запу
ске приложения, а метод handleRequest () или его аналог — при получении
каждого запроса пользователя. В нашем же классе мы придерживаемся такого
же различия между инициализацией и обработкой запросов, хотя метод init ()
вызывается для каждого запроса.
В методе init () происходит обращение к классу ApplicationHelper
через класс Registry, ссылка на который находится в свойстве $reg класса
Controller. В классе ApplicationHelper хранятся данные конфигурации
для всего приложения. Вызов Controller: : init () приводит, в свою очередь,
к вызову аналогичного метода init () из класса ApplicationHelper, где ини
циализируются данные, применяемые в приложении, как будет показано далее.
А в методе handleRequest () используется класс CommandResolver с целью
получить объект типа Command для выполнения соответствующей команды пу
тем вызова метода Command: :execute ().
Класс ApplicationHelper

Этот класс не так важен для реализации шаблона Front Controller. Но в
большинстве его реализаций используются данные конфигурации, поэтому для

ГЛАВА 12 в ШАБЛОНЫ КОРПОРАТИВНЫХ ПРИЛОЖЕНИЙ

385

них необходимо выработать соответствующую стратегию. Ниже приведен при
мер простого определения класса ApplicationHelper.
// Листинг 12.11
class ApplicationHelper
{

private $config = __ DIR__
private $reg;

.

”/data/woo_options.ini";

public function __ construct ()

{
$this->reg = Registry::instance ();

}
public function init ()

{
$this->setupOptions ();
if (isset($_SERVER[’REQUEST_METHOD’]))
$request = new HttpRequest();
} else {
$request = new CliRequestO ;

{

}

$this->reg->setRequest($request);

}

private function setupOptions ()
(
if (! file_exists($this->config)) {
throw new AppException("Файл конфигурации не найден!");
}
$options = parse_ini_file($this->config, true);
$conf = new Conf($options['config’]);
$this->reg->setConf($conf);
$commands = new Conf($options[’commands’]);
$this->reg->setCommands($commands);
}

}

В данном классе просто читается содержимое файла конфигурации и в
реестр вводятся различные объекты, благодаря чему они становятся доступ
ными в остальной системе. В методе init() вызывается закрытый метод
setupOptions (), где читается содержимое файла с расширением .ini и пе
редаются объекту типа Registry два массива, каждый из которых заключен в
оболочку класса Conf. В классе Conf определены лишь методы get () и set (),
хотя в более развитых классах может быть организован поиск и синтаксиче
ский анализ файлов, а также обнаружение данных. Один из массивов типа Conf
предназначен для хранения общих значений конфигурации и передается вызы
ваемому методу Registry: : setConf (). Еще один массив служит для преоб
разования путей URL в классы типа Command и передается при вызове метода
Registry::setcommands().

386

ЧАСТЬ III в ШАБЛОНЫ

В методе init () предпринимается также попытка выяснить, выполняется ли
приложение в контексте веб или запущено из командной строки. Для этого прове
ряется существует ли элемент суперглобального массива $_SERVER[ 'REQUEST_
METHOD ’ ]. В зависимости от результата данной проверки в этом методе созда
ется и передается объекту типа Registry соответствующий объект отдельного
подкласса, производного от класса Request.
Поскольку в классах типа Registry выполняется совсем немного дей
ствий — в них лишь сохраняются и возвращаются объекты, поэтому их исход
ный код вряд ли стоит приводить в листингах. Но ради полноты примера ниже
представлены дополнительные методы из класса Registry, применяемые или
подразумеваемые в классе ApplicationHelper.
// Листинг 12.12
// должен быть инициализирован каким-нибудь
// более развитым компонентом
public function setRequest(Request $request)
{
$this->request = $request;
}

public function getRequestO : Request
{
if (is_null($this->request)) {
throw new \Exception (’’Объект типа Request не задан!”);
}
return $this->request;
}
public function getApplicationHelper(): ApplicationHelper
{
if (is_null($this->applicationHelper)) {
$this->applicationHelper = new ApplicationHelper();
}
return $this->applicationHelper;
}

public function setConf(Conf $conf)
{
$this->conf = $conf;
}
public function getConf () : Conf
{
if (is_null($this->conf)) {
$this->conf = new Conf ();
}
return $this->conf;
}
public function setCommands(Conf $commands)
{
$this->commands = $commands;

ГЛАВА 12 Я ШАБЛОНЫ КОРПОРАТИВНЫХ ПРИЛОЖЕНИЙ

387

public function getCommands(): Conf
{
return $this->commands;
}

Ниже приведен пример простого файла конфигурации.
[config]
dsn=sqlite:/var/popp/src/chl2/batch05/data/woo.db

[commands]
/=\popp\ch12\batchO5\Defaultcommand

Класс CommandResolver

Контроллеру требуется какой-нибудь способ, позволяющий решить, как ин
терпретировать HTTP-запрос, чтобы в результате можно было вызвать нужный
код для обработки этого запроса. Такую логику можно легко включить в сам
класс Controller, но для этой цели лучше воспользоваться специальным клас
сом. При необходимости это позволит без особого труда реорганизовать код для
целей полиморфизма.
Контроллер, создаваемый по шаблону Front Controller, обращается к
логике приложения, выполняя команду из объекта типа Command (подробнее о
шаблоне Command см. в главе 11, “Выполнение задач и представление результа
тов”). Этот объект выбирается в соответствии со структурой запрошенного URL,
или значением параметра, указанного в запросе типа GET (последний вариант
встречается реже). Но в любом случае получается отличительный признак или
шаблон, с помощью которого можно выбрать команду. Для выбора команды с
помощью URL имеются разные способы. С одной стороны, можно сопоставить
отличительный признак с конкретным классом типа Command с помощью файла
конфигурации или структуры данных (такая стратегия называется логической).
А с другой стороны, его можно непосредственно отобразить на файл класса,
расположенный в файловой системе (такая стратегия называется физической).
В предыдущей главе демонстрировался пример фабрики команд, в котором
применялась физическая стратегия. Выберем на этот раз логическую стратегию,
преобразовав фрагменты URL в классы, создаваемые по шаблону Command:
// Листинг 12.13

class CommandResolver

(
private static $refcmd = null;
private static $defaultcmd = Defaultcommand::class;
public function __ construct ()
{

// этот объект можно сделать конфигурируемым
self::$refcmd = new \ReflectionClass(Command::class);
}

388

ЧАСТЬ III » ШАБЛОНЫ

public function getCommand(Request $request): Command
{
$reg = Registry::instance();
$commands = $reg->getCommands ();
$path = $request->getPath ();
$class = $commands->get($path);
if (is_null($class)) {
$request->addFeedback("Соответствие пути ’$path' не обнаружено!");
return new self::$defaultcmd ();
}

if (! class_exists($class)) {
$request->addFeedback("Класс ’$class’ не найден!");
return new self::$defaultcmd();

}

$refclass = new \ReflectionClass ($class);
if (! $refclass->isSubClassOf(self::$refcmd)) {
$request->addFeedback(
"Команда '$refclass’ не относится к классу Command!");
return new self::$defaultcmd();
}
return $refclass->newlnstance();

}
}

В этом простом классе сначала из реестра извлекается объект типа Conf,
а затем используется путь, полученный из URL в результате вызова метода
Request: : getPath (), чтобы попытаться получить имя класса. Если имя клас
са найдено и этот класс существует и является экземпляром базового класса
Command, то сначала создается его экземпляр, а затем он возвращается в вызы
ваемую программу.
Если любое из упомянутых выше условий не удовлетворяется, то метод
getCommand () корректно выходит из сложившейся ситуации, возвращая стан
дартный объект типа Command. А в более сложной реализации (например, при
применении логики маршрутизации в Silex и Symfony) в подобных путях упо
требляются метасимволы.
В связи с изложенным выше у вас может возникнуть вопрос: почему в дан
ном коде принимается на веру, что конструктору класса Command, который в нем
создается, не требуется передавать никаких параметров.
return $refclass->newlnstance();

Ответ следует искать в сигнатуре самого класса Command.
// Листинг 12.14
abstract class Command
{

final public function

construct()

ГЛАВА 12

ШАБЛОНЫ КОРПОРАТИВНЫХ ПРИЛОЖЕНИЙ

389

{
}
public function execute(Request $request)
{

$this->doExecute($request);

}
abstract public function doExecute(Request $request);
}

Объявляя метод конструктора как final, мы делаем невозможным его пе
реопределение в дочернем классе. Поэтому ни один из классов типа Command
никогда не потребует аргументы для своего конструктора.
Создавая командные классы, старайтесь по возможности не допускать вклю
чения в них логики приложения. Как только они начнут выполнять то, что
должно делать само приложение, они превратятся в некое подобие запутанного
сценария транзакций, и тогда дублирование кода не заставит себя долго ждать.
Команды можно сравнить с ретрансляционной станцией: они должны интерпре
тировать запрос, вызывать логику приложения для выполнения операций с ка
кими-нибудь объектами, а затем передавать данные для отображения на уровне
представления. И как только они начнут делать что-нибудь более сложное, веро
ятно, настанет время реорганизовать код. Правда, реорганизовать код совсем не
трудно. Для этого достаточно найти место, где команда пытается сделать много
лишнего, а решение для устранения этого недостатка, как правило, очевидно:
переместить функциональные возможности команды вниз по иерархии во вспо
могательный класс или же в класс предметной области.
Запрос

Запросы как по волшебству обрабатываются средствами РНР, а их параметры
аккуратно укладываются в суперглобальные массивы. Вы, вероятно, заметили,
что для представления запроса мы все еще пользуемся классом. В частности,
объект типа Request передается сначала объекту типа CommandResolver, а за
тем — объекту типа Command.
Почему мы не позволяем этим классам напрямую обращаться к элементам
суперглобальных массивов $_REQUEST, $_POST или $_GET? Мы могли бы, ко
нечно, это сделать, но, централизуя операции обработки запросов в одном месте,
мы открываем для себя новые возможности. Например, к входящим запросам
можно применить фильтры или, как показано в следующем примере, получить
параметры не из HTTP-запроса, а из другого источника, что позволит запускать
приложение из командной строки или из тестового сценария.
Объект типа Request может также служить удобным хранилищем данных,
которые требуется передать на уровень представления. На самом деле во мно
гих системах для этих целей предоставляется отдельный объект типа Response,
но мы не будем усложнять дело до такой степени и приведем ниже пример
простого класса Request.

390

ЧАСТЬ III «8 ШАБЛОНЫ

// Листинг 12.15
abstract class Request
{
protected $properties;
protected $feedback = [];
protected $path =
public function __ construct()
{
$this->init();
}
abstract public function init();

public function setPath(string $path)
{
$this->path = $path;
}
public function getPath(): string
{
return $this->path;
}

public function getProperty(string $key)
{
if (isset($this->properties[$key])) {
return $this->properties[$key];
}
return null;
}

public function setProperty(string $key,
{
$this->properties[$key] = $val;
}

$val)

public function addFeedback(string $msg)
{
array_push($this->feedback, $msg);
}

public function getFeedback(): array
{
return $this->feedback;
}
public function getFeedbackString($separator = "\n"
string
{
return implode($separator, $this->feedback);
}
public function clearFeedback()
{
$this->feedback = [];

ГЛАВА 12 Ш ШАБЛОНЫ КОРПОРАТИВНЫХ ПРИЛОЖЕНИЙ

391

Как видите, большую часть этого класса занимают механизмы установки и
получения значений свойств. В частности, метод init () отвечает за наполне
ние закрытого массива $properties для обработки в дочерних классах. Следу
ет особо подчеркнуть, что в данном примере реализации совершенно игнориру
ются методы запроса, чего не стоит делать в реальном проекте. В полноценной
реализации следует организовать обработку массивов из запросов по методам
GET, POST и PUT, а также предоставить единообразный механизм обработки
запросов. Как только будет получен объект типа Request, вы должны обра
щаться к параметрам HTTP-запроса исключительно с помощью вызова метода
getProperty (). Этому методу передается ключ в виде символьной строки, а
он возвращает соответствующее значение, хранящееся в массиве $properties.
Кроме того, нужные данные можно ввести с помощью метода setProperty ().
В данном классе поддерживается также массив $ feedback. Это простой ка
нал связи, по которому классы контроллеров могут передавать сообщения поль
зователю. А в полноценной реализации, вероятнее всего, придется различать
сообщения об ошибках от информационных сообщений.
Как упоминалось ранее, в классе ApplicationHelper создается экземпляр
класса HttpRequest или CliRequest. Ниже приведено определение первого
из них.
/ / Листинг 12.16
class HttpRequest extends Request

{
public function init()

{
// Ради удобства здесь игнорируются отличия
// в методах запросов POST, GET, т.д., но
// этого нельзя делать в реальном проекте!
$this->properties = $_REQUEST;
$this->path = $_SERVER['PATH_INFO’];
$this->path = (empty ($this->path) ) ?
: $this->path;

}
}

В классе CliRequest аргументы командной строки интерпретируются в
виде пары “ключ-значение” и разделяются на отдельные свойства. Кроме того,
в этом классе выполняется поиск аргумента с префиксом path:, а его значение
присваивается свойству $path текущего объекта, как показано ниже.
// Листинг 12.17

class CliRequest extends Request
{
public function init()
{
$args = $_SERVER [ ’ argv ’ ] ;
foreach ($args as $arg) {
if (preg_match(”/Apath: (\S+)/",

$arg,

$matches))

{

392

ЧАСТЬ III * ШАБЛОНЫ
$this->path = $matches[l];
} else {
if (strpos($arg, ’ = ')) {
list($key, $val) = explode("=", $arg);
$this->setProperty($key, $val);
}
}
}
$this->path =

(empty($this->path))

? "/” : $this->path;

}
}

Команда

Вы уже знакомы с базовым классом Command, а шаблон Command подробно
описывался в главе И, “Выполнение задач и представление результатов”, поэто
му не будем повторяться. Но подытожив все, что об этом известно, рассмотрим
простую реализацию объекта типа Command.
// Листинг 12.18

class Defaultcommand extends Command

{

public function doExecute(Request $request)
{

$request->addFeedback("Добро пожаловать в Woo!");
include (__ DIR__ . ’’/main.php") ;
}
}

Такой объект типа Command автоматически выбирается классом CommandResolver, если не было получено явного запроса на конкретный объект типа
Command. Как вы, вероятно, заметили, в абстрактном базовом классе Command
реализован метод execute (), из которого вызывается метод doExecute (), ре
ализованный в дочернем классе. Это позволяет вводить код для начальной уста
новки и очистки во все команды, просто изменяя базовый класс.
Методу execute () передается объект типа Request, через который обе
спечивается доступ к данным, введенным пользователем, а также к методу
setFeedback(). В классе DefaultCommand данный метод служит для уста
новки приветственного сообщения.
Наконец, команда передает управление представлению, просто вызывая ме
тод include (). Внедрение кода представления в классы типа Command — это
самый простой механизм диспетчеризации, но для небольших систем он подхо
дит идеально. О более гибкой стратегии речь пойдет далее, в разделе “Шаблон
Application Controller”.
В файле main.php содержится HTML-код разметки страницы и вызов мето
да getFeedback () объекта Request для отображения сообщений, предназна
ченных для пользователя (вскоре я расскажу о представлениях более подробно).
Теперь у нас имеются все компоненты, необходимые для запуска системы. Ниже
показано, как это будет выглядеть на экране.

ГЛАВА 12 W ШАБЛОНЫ КОРПОРАТИВНЫХ ПРИЛОЖЕНИЙ

393

Woo! Это программа Woo!

Добро пожаловать в Woo!

Как видите, сообщение, выведенное в теле стандартной команды, оказалось
на экране пользователя. Теперь рассмотрим весь процесс, который привел к та
кому результату.
Общее представление

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

ApplicationHelper

CommandResolver

Command

I

I

--------------- 1---------------

-------- 1-------i
i
i
i
i
i
i
i

I

init0

getCommandO

_____________
I
executeO
I
------------------------- 1------------------------------------- Г

I

I

I
I
I

i

Рис. 12.4. Шаблон Front Controller в действии

Как видите, Front Controller делегирует инициализацию объекту типа
ApplicationHelper, где используется кеширование с целью сократить вре
мя на обработку параметров. Затем класс Controller получает объект типа
Command от объекта типа CommandResolver. И, наконец, вызывается метод
Command: :execute (), чтобы выполнить логику приложения.
В данной реализации шаблона Front Controller сам объект типа Command
отвечает за делегирование полномочий на уровень представления. Усовершен
ствованный вариант реализации данного шаблона будет приведен в следующем
разделе.

394

ЧАСТЬ III

ШАБЛОНЫ

Результаты

Шаблон Front Controller — не для слабонервных. Для работы с ним вам
придется уделить немало внимания предварительной разработке, прежде чем вы
реально почувствуете все его преимущества. И если проект настолько мал, что
в конечном итоге каркас шаблона Front Controller может оказаться сложнее
всей остальной системы, или же проект требуется очень быстро реализовать,
это становится серьезным препятствием для применения данного шаблона.
Но успешно применив шаблон Front Controller в одном проекте, вы об
наружите, что можете повторно использовать его и в других проектах с молни
еносной быстротой. В частности, большинство его функций можно разместить в
библиотечном коде, создав таким образом эффективный повторно используемый
каркас.
Еще одним недостатком данного шаблона является обязательное требование,
чтобы все сведения о конфигурации загружались по каждому запросу. В какой-то
степени от этого страдают все шаблоны, но для шаблона Front Controller
часто требуются дополнительные сведения, например, логические соответствия
команд и представлений.
Указанный недостаток можно значительно уменьшить благодаря кеширова
нию данных конфигурации. Самый эффективный способ сделать это состоит в
том, чтобы организовать ввод данных конфигурации системы в виде встроен
ных в РНР структур данных. Такой подход вполне пригоден для тех разработ
чиков, которые самостоятельно сопровождают систему. Но если вашей системой
пользуются люди, не владеющие языком РНР, то для них придется создать файл
конфигурации. Впрочем, вы можете автоматизировать упомянутый выше подход
с помощью собственных средств РНР, написав программу, которая сначала чи
тает содержимое файла конфигурации, а затем создает на его основе структуры
данных РНР, которые хранятся в оперативной памяти. Как только структуры
данных конфигурации будут созданы, они могут использоваться в вашей систе
ме до тех пор, пока не будут внесены изменения в исходный файл конфигура
ции и не возникнет потребность обновить содержимое кеша.
Преимущество шаблона Front Controller заключается в том, что в нем
централизована логика управления представлениями в системе. Это означает
возможность осуществлять централизованный контроль над обработкой запро
сов и выбирать представления (но в любом случае в одном ряде классов). Это
позволит сократить дублирование кода и уменьшить вероятность ошибок.
Шаблон Front Controller предоставляет также немало возможностей для
расширения. Как только основная часть приложения будет спроектирована и го
това к работе, ввести новые классы типа Command и представления не составит
большого труда.
В описанном здесь примере сами команды управляют диспетчеризацией соб
ственных представлений. Если шаблон Front Controller применяется вместе
с объектом, помогающим выбрать представление, а возможно, и команду, то

ГЛАВА 12 И ШАБЛОНЫ КОРПОРАТИВНЫХ ПРИЛОЖЕНИЙ

395

он предоставляет отличные возможности для управления навигацией, которую
труднее эффективно поддерживать, если управление представлениями распреде
лено по всей системе. Такой объект будет описан в следующем разделе.

Шаблон Application Controller
В небольших системах вполне допускается, чтобы команды вызывали соб
ственные представления, хотя это и не идеальный вариант. Намного предпочти
тельнее отделить команды от уровня представления данных настолько, насколь
ко это возможно.
Шаблон Application Controller (Контроллер приложения) берет на себя
ответственность за соответствие запросов командам и команд их представлени
ям. Такое разделение ответственности означает, что в приложении можно очень
легко сменять совокупности представлений, не затрагивая кодовую базу. Это
также дает владельцу системы возможность изменять ход выполнения прило
жения, не затрагивая, опять-таки, его внутреннее строение. Допуская логиче
скую систему разрешения команд по шаблону Command, шаблон Application
Controller упрощает также применение одной и той же команды в разных
контекстах проектируемой системы.
Проблема

Напомним о характере проблемы в рассматриваемом здесь примере. Адми
нистратору требуется возможность вводить культурное заведение в систему и
связывать с ним место проведения культурного мероприятия. Поэтому систе
ма может поддерживать команды типа AddVenue и AddSpace. Как следует из
рассмотренных до сих пор примеров, эти команды выбираются путем прямого
преобразования пути (/addVenue) в класс (AddVenue).
Вообще говоря, успешный вызов команды типа AddVenue должен привести к
первоначальному вызову команды типа AddSpace. Эта связь может быть жест
ко закодирована в самих классах, чтобы при успешном выполнении команды
типа AddVenue она вызывала команду типа AddSpace. Затем в команду типа
AddSpace может быть включено представление, содержащее форму для ввода
места проведения культурного мероприятия в соответствующее заведение.
Обе команды могут быть связаны, по меньшей мере, с двумя различными
представлениями: основным — для отображения формы ввода входных данных
и вспомогательным — для вывода сообщения об ошибке или выражения бла
годарности на экран. По обсуждавшейся ранее логике эти представления могут
быть включены в сами классы типа Command (а точнее, в проверки условий, где
решается, какое именно представление следует воспроизводить в конкретной
ситуации).
Такой уровень жесткого кодирования приемлем до тех пор, пока команды
применяются одинаково. Но ситуация начнет ухудшаться, когда потребуется
специальное представление для команды типа AddVenue и придется изменить
логику, по которой одна команда приводит к другой (вероятно, в выполняющемся

396

ЧАСТЬ III в ШАБЛОНЫ

потоке понадобится вывести дополнительный экран после успешного ввода
культурного заведения и перед началом ввода места проведения культурного
мероприятия). Если каждая из команд применяется только один раз в одной
взаимосвязи с другими командами и одним представлением, то взаимосвязи ко
манд друг с другом и с их представлениями можно жестко закодировать. В про
тивном случае продолжайте читать дальше, чтобы узнать, каким образом класс
контроллера приложения может взять на себя управление такой логикой, осво
бодив классы типа Command, чтобы они могли сосредоточиться на своих непо
средственных обязанностях, т.е. обрабатывать входные данные, вызывать логику
приложения и обрабатывать полученные результаты.
Реализация

Как всегда, ключом к данному шаблону служит интерфейс. Контроллер при
ложения — это класс (или ряд классов), который фронтальный контроллер мо
жет применять с целью получить команды на основе запроса пользователя и
найти нужное представление, которое будет затем выведено после выполнения
команды. Подобная взаимосвязь контроллеров наглядно показана на рис. 12.5.

Рис. 12.5. Шаблон Application Controller

Назначение данного шаблона, как и всех остальных шаблонов, рассматри
ваемых в этой главе, — упростить как можно больше задачу клиентского кода.
Этим и объясняется спартанский вид класса Controller, представляющего
фронтальный контроллер. Но за интерфейсом необходимо развернуть реали
зацию. Применяемый здесь подход демонстрирует лишь одну из возможно
стей сделать это. Прорабатывая материал этого раздела, не забывайте, что суть
данного шаблона состоит во взаимодействии участников (контроллера прило
жения, команд и представлений), а не в особенностях рассматриваемой здесь
реализации. Итак, начнем с того кода, в котором применяется контроллер при
ложения.

ГЛАВА 12 ® ШАБЛОНЫ КОРПОРАТИВНЫХ ПРИЛОЖЕНИЙ

397

Класс Controller

Ниже показано, каким образом класс Controller может взаимодействовать
с классом AppController. Однако данный пример кода упрощен и не предпо
лагает обработку ошибок.
// Листинг 12.19
// Класс Controller
private function __ construct ()

{
$this->reg = Registry::instance();
}

public function handleRequest ()

{

$request = $this->reg->getRequest () ;
$controller = new AppController ();
$cmd = $controller->getCommand($request);
$cmd->execute($request);
$view = $controller->getView($request);
$view->render($request);
}

Принципиальное отличие от предыдущего примера состоит в том, что те
перь компонент представления извлекается вместе с командой, помимо замены
имени класса CommandResolver на AppController, хотя это и косметическая
операция. Обратите также внимание на то, что для получения объекта типа
Request в данном примере применяется объект типа Registry. Объект типа
AppController можно было бы сохранить в реестре, даже если он и не приме
няется в других компонентах. Классы, в которых исключается непосредственное
получение экземпляров, как правило, оказываются более гибкими и легче под
даются тестированию.
Так по какой же логике в классе AppController становится известно, какое
именно представление следует связать с конкретной командой? Как и всегда в
объектно-ориентированном коде, интерфейс важнее, чем реализация. Выберем,
однако, наиболее приемлемый подход.
Краткий обзор реализации

На различных стадиях выполнения операции в классе Command могут по
требоваться разные представления. Стандартным представлением для команды
типа AddVenue может быть форма ввода данных. Если пользователь вводит не
верный тип данных, форма может быть выведена снова, или будет выведена
страница с сообщением об ошибке. Если все пойдет нормально и культурное
заведение будет создано в системе, можно перейти к другому звену в цепочке
команд, представленных объектами типа Command (возможно, к команде типа
AddSpace).

398

ЧАСТЬ III

ШАБЛОНЫ

Объекты типа Command сообщают системе о своем текущем состоянии, уста
навливая специальный код состояния. Ниже приведены коды, которые распозна
ются в рассматриваемой здесь минимальной реализации (они задаются в виде
статических свойств в суперклассе Command).
// Листинг 12.20

const
const
const
const

CMD_DEFAULT = 0;
CMD_OK = 1;
CMD_ERROR = 2;
CMD_INSUFFICIENT_DATA = 3;

Контроллер приложения находит и получает экземпляр нужного класса типа
Command, используя объект типа Request. Как только контроллер приложения
начнет выполняться, с объектом типа Command будет связан соответствующий
код состояния. Сочетание объекта типа Command и кода состояния можно затем
сравнить с внутренней структурой данных, чтобы выяснить, какая именно ко
манда должна быть выполнена следующей или же какое представление следует
отобразить, если никаких команд выполнять больше не требуется.
Файл конфигурации

Владелец системы может определить, каким образом команды и представле
ния должны работать совместно, указав набор директив в файле конфигурации.
Ниже приведен фрагмент такого файла.

Ccommand path="/" class="\popp\chl2\batch06\DefaultCommand">

cview name=”error" />

c/command>
ccommand path="/listvenues" class="\popp\chl2\batch06\ListVenues">
cview name="listvenues" />

Ccommand path="/quickaddvenue" class="\popp\chl2\batch06\AddVenue">
Cview name="quickadd" />
c/command>
ccommand path="/addvenue" class="\popp\chl2\batch06\AddVenue">
cview name="addvenue" />
Cstatus value="CMD_OK">
cforward path="/addspace" />

Ccommand path="/addspace" class="\popp\chl2\batch06\AddSpace">
cview name="addspace" />
cstatus value="CMD_OK">

ГЛАВА 12 • ШАБЛОНЫ КОРПОРАТИВНЫХ ПРИЛОЖЕНИЙ

399

На примере данного упрощенного фрагмента кода XML демонстрируется
одна из стратегий абстрагирования потока команд и его взаимосвязи с пред
ставлениями в классах типа Command. Все эти директивы содержатся в элементе
разметки control.
В каждом элементе разметки command определяются атрибуты path и class,
где описывается элементарное соответствие команд имен классов. Но логика для
представлений оказывается более сложной. Так, в элементе view на верхнем
уровне разметки команды определяется ее взаимосвязь со стандартным пред
ставлением. Иными словами, если ни одно из конкретных условий не совпадает,
то по умолчанию для данной команды выбирается стандартное представление.
Конкретные условия определяются в элементах разметки status, где значения
атрибутов value должны совпадать с одним из упомянутых выше кодов состоя
ния команд. Так, если выполнение команды приводит к коду состояния CMD_OK,
то используется соответствующий элемент разметки view, если равнозначный
код состояния определен в XML-документе.
В элементе разметки view определяется атрибут name, значение которого
служит для составления пути к файлу шаблона, который затем включается в
проект. А элементы разметки command или status могут содержать элемент
разметки forward, а не view. Рассматриваемая здесь система интерпретирует
элемент разметки forward как особого рода представление, повторно вызываю
щееприложение по новому пути вместо воспроизведения файла шаблона.
Рассмотрим следующий фрагмент XML-разметки в свете приведенного выше
пояснения:

Когда из запроса извлекается заданный путь /addvenue, вызывается коман
да типа AddVenue. Затем формируется код состояния CMD_DEFAULT, CMD_OK,
CMD—ERROR или CMD_INSUFFICIENT_DATA. Далее для любого кода состояния,
кроме CMD OK, вызывается шаблон addvenue. Но если команда возвращает код
состояния CMD OK, то это означает, что условие совпадает. Элемент разметки
status мог бы просто содержать другое представление, которое должно быть
выбрано вместо стандартного. Но в данном случае вступает в действие элемент
разметки forward. Отсылая к другой команде, файл конфигурации возлагает
на новый элемент разметки всю ответственность за обработку представлений.

400

ЧАСТЬ III ж ШАБЛОНЫ

И тогда система будет снова запущена на выполнение по новому запросу с за
данным путем /addspace.
Синтаксический анализ файла конфигурации

Благодаря расширению SimpleXML отпадает необходимость в непосредствен
ном выполнении синтаксического анализа, поскольку это делается автоматически.
Остается лишь обойти структуру данных SimpleXML и сформировать собствен
ные данные. Ниже приведено определение класса ViewComponentCompiler,
где все это реализуется на практике.
// Листинг 12.21

class ViewComponentCompiler
{
private static Sdefaultcmd = Defaultcommand::class;

public function parseFile($file)
{
$options = simplexml_load_file($file) ;
return $this->parse ($options);
}
public function parse(\SimpleXMLElement $options): Conf
{
$conf = new Conf () ;
foreach ($options->control->command as $command) {
$path = (string)$command[’path;
$cmdstr = (string)$command['class’];
$path = (empty ($path) ) ? "/” : $path;
$cmdstr = (empty($cmdstr))
? self::$defaultcmd: $cmdstr;
$pathobj = new ComponentDescriptor($path, $cmdstr);
$this->processView($pathobj, 0, $command);
if (isset($command->status)
&& isset($command->status[’value’])) I
foreach ($command->status as $statusel) {
$status = (string)$statusel[’value’];
$statusval = constant (
Command::class . ” : : " . $status);
if (is_null($statusval)) {
throw new AppException(
’’Неизвестный код состояния: { $status } ’’ ) ;
}
$this->processView($pathobj, $statusval,
$statusel);
}
}
$conf->set($path, $pathobj);
}
return $conf;

}
public function processview(ComponentDescriptor $pathobj,
int $statusval, \ SimpleXMLElement $el)

ГЛАВА 12 й ШАБЛОНЫ КОРПОРАТИВНЫХ ПРИЛОЖЕНИЙ
if (isset($el->view)

401

&& isset($el->view['name']))

{
$pathobj->setView($statusval,
new TemplateViewComponent (
(string)$el->view[’name’]));
}
if (isset($el->forward)

&& isset($el->forward['path']))

{
Spathobj->setView($statusval,
new ForwardViewComponent (
(string)$el->forward['path']));
}

}

}

Реальное действие происходит в методе parse (), которому передается объ
ект типа SimpleXMLElement для обхода. Сначала получается объект типа Conf
(напомним, что этот объект служит всего лишь оболочкой для массива), а затем
осуществляется обход элементов команды в XML-доку менте. Для каждой ко
манды извлекаются значения атрибутов path и class, а полученные данные
передаются конструктору класса ComponentDescriptor. Объект этого класса
обработает пакет информации, связанной с элементом разметки command. Этот
класс будет представлен несколько позже.
Далее вызывается закрытый метод processview (), которому передает
ся объект типа ComponentDescriptor, нулевое целочисленное значение, по
скольку обрабатывается стандартное состояние, а также ссылка на текущий
элемент XML-разметки, фактически содержащий конкретную команду. В за
висимости от того, что будет обнаружено во фрагменте XML-разметки, в ме
тоде processview () будет создан объект типа TemplateViewComponent
или ForwardViewComponent, который далее передается вызываемому методу
ComponentDescriptor: :setView(). Если же никакого совпадения не прои
зойдет, то и ничего не будет вызвано, что, конечно, нежелательно. Поэтому в бо
лее полной реализации такое условие следовало бы трактовать как ошибочное.
Обработка атрибутов элемента разметки status начинается в методе
parse (). С этой целью снова вызывается метод processview (), но на этот
раз с целочисленным значением, соответствующим символьной строке из атри
бута value элемента разметки status. Иными словами, символьная стро
ка "CMD_OK" преобразуется в целочисленное значение 1, символьная строка
"CMD_ERROR" — в целочисленное значение 2 и т.д. Встроенная в РНР функ
ция constant () аккуратно выполняет такое преобразование. В итоге методу
processview () передается ненулевое целочисленное значение, а также элемент
разметки status.
Объект типа ComponentDescriptor снова заполняется в методе
processview () любыми обнаруженными объектами, реализующими компонен
ты представлений. И, наконец, объект типа ComponentDescriptor сохраняется
в объекте типа Conf по индексу значения пути к компоненту команды. По окон
чании цикла возвращается объект типа Conf.

402

ЧАСТЬ III » ШАБЛОНЫ

Возможно, чтобы разобраться в рассмотренном здесь процессе, вам при
дется прочитать его описание еще раз, но на самом деле он довольно
прост. В классе ViewComponentCompiler создается массив объектов типа
ComponentDescriptor, заключаемый, как и прежде, в оболочку объекта типа
Conf. В каждом объекте типа ComponentDescriptor хранятся сведения о пути,
команде, реализуемой в классе Command, а также о массиве объектов, реализую
щих компоненты представлений для отображения или вызова другой команды.
Этот массив проиндексирован по коду состояния, принимающему нулевое зна
чение для стандартного представления.
Несмотря на весь этот антураж, сам описываемый здесь процесс в общем
очень прост и состоит в создании взаимосвязей между потенциальными запро
сами с одной стороны и командами с другой (рис. 12.6).
ApplicationHelper

Controller

ViewComponentCompiler

Registry

T

parseFileO

I
I
I
I
I

setCommandsO

!

init()

<
■
■
i
■
■

■
■
■
■

I

г
i
■
■
i
■
■
■

Рис. 12.6. Компиляция команд и представлений

Управление данными компонентов

Как было показано выше, объекты типа ComponentDescriptor хранятся в
объекте типа Conf, который служит оболочкой для получения и установки эле
ментов ассоциативного массива. В качестве ключей этого массива служат пути,
распознаваемые в системе (например, / или /addvenue).
Рассмотрим класс ComponentDescriptor, предназначенный для управления
командами, представлениями и пересылки информации.
// Листинг 12.22

class ComponentDescriptor
{

private $path;
private static $refcmd;
private $cmdstr;

ГЛАВА 12 Я ШАБЛОНЫ КОРПОРАТИВНЫХ ПРИЛОЖЕНИЙ

403

public function __ construct(string $path, string $cmdstr)
{

self::$refcmd = new \ReflectionClass(Command::class);
$this->path = $path;
$this->cmdstr = $cmdstr;

public function getCommandO: Command

{
return $this->resolveCommand($this->cmdstr);

public function setview(int $status, ViewComponent $view)

{
$this->views[$status] = $view;

public function getView(Request $request): ViewComponent
{
$status = $request->getCmdStatus();
$status = (is_null($status)) ? 0 : $status;
if (isset($this->views[$status])) {
return $this->views[Sstatus];
}
if (isset($this->views[0]))
return $this->views[0];

{

}
throw new AppException(’’Представление не найдено!");

public function resolveCommand(string $class): Command
{
if (is_null($class) ) {
throw new AppException("Неизвестный класс ’$class'!”);
}
if (! class_exists($class)) {
throw new AppException ("Класс '$class' не найден!’’);
}
$refclass = new \ReflectionClass($class);
if (! $refclass->isSubClassOf(self::$refcmd)) {
throw new AppException("Команда '$class' не относится к классу
Command!");
}

return $refclass->newlnstance ();

Как видите, в данном классе не только организуется хранение и извлечение
данных, но и делается кое-что еще. Сведения о команде (полное имя класса,
реализующего команду) вводятся через конструктор и только по требованию
преобразуются в объект типа Command при вызове метода getCommand ().
Процедура получения экземпляра и проверки происходит в закрытом методе

404

ЧАСТЬ III

ШАБЛОНЫ

resolveCommand (). Его исходный код выглядит знакомо, поскольку фактиче
ски он заимствован из класса CommandResolver, упоминавшегося ранее в этой
главе, а вернее, навеян его эквивалентными функциональными возможностями.
Таким образом, этот небольшой класс обеспечивает всю логику, необходи
мую для обработки элементов разметки command из XML-файла. Сам же класс
контроллера приложения оказывается относительно скромным, поскольку все
операции выполняются во вспомогательных классах. Ниже приведено опреде
ление этого класса.
// Листинг 12.23

class AppController

{
private static $defaultcmd = DefaultCommand::class;
private static Sdefaultview = "fallback";

public function getCommand(Request $request): Command

I
try {
$descriptor = $this->getDescriptor($request);
$cmd = $descriptor->getCommand();
} catch (AppException $e) {
$request->addFeedback($e->getMessage ());
return new self::Sdefaultcmd();
}
return $cmd;
}

public function getView(Request $request): ViewComponent
{

try {
$descriptor = $this->getDescriptor($request);
Sview = Sdescriptor->getView(Srequest);
} catch (AppException $e) {
return new TemplateViewComponent(self::Sdefaultview);
}
return $view;

}
private function getDescriptor(Request $request):
ComponentDescriptor
(
$reg = Registry::instance ();
$commands = $reg->getCommands();
$path = $request->getPath() ;
$descriptor = $commands->get(Spath);
if (is_null(Sdescriptor)) {
throw new AppException("He найден дескриптор для {Spath}",
}
return Sdescriptor;

404);

ГЛАВА 12

ШАБЛОНЫ КОРПОРАТИВНЫХ ПРИЛОЖЕНИЙ

405

В этом классе фактически присутствует немного логики, поскольку боль
шая часть сложных операций вынесена в различные вспомогательные классы.
В методах getCommand () и getView () вызывается метод getDescriptor()
с целью получить объект типа ComponentDescriptor для текущего запроса.
Текущий путь получается из объекта типа Request в методе getDescriptor ()
и используется далее для извлечения объекта типа ComponentDescriptor из
объекта типа Conf, который также сохраняется в реестре и возвращается мето
дом getCommands (). Напомним, что этот объект служит оболочкой для массива
объектов типа ComponentDescriptor и ранее был заполнен потенциальными
путями в качестве ключей с помощью объекта типа ViewComponentCompiler.
Как только будет получен объект типа ComponentDescriptor, в каждом из
методов getCommand () и getView () можно вызвать соответствующий метод.
Так, в методе getCommand() вызывается метод ComponentDescriptor: :getCo
mmand (), а в методе getView () — метод ComponentDescriptor: : getView ().
Прежде чем продолжить обсуждение, необходимо уточнить некоторые
подробности. Теперь команды, реализуемые объектами типа Command, сами
больше не вызывают представления, и поэтому для воспроизведения шабло
нов требуется какой-нибудь механизм. Для этой цели служат объекты клас
са TemplateViewComponent, реализующего приведенный ниже интерфейс
ViewComponent.
// Листинг 12.24

interface ViewComponent
{

public function render(Request $request);
}

А почему, собственно, интерфейс? А потому, что пересылка данных и ото
бражение шаблонов трактуются как процессы представления. Ниже приведено
определение класса TemplateViewDisplay для отображения представлений
шаблонов.
// Листинг 12.25

class TemplateViewComponent implements ViewComponent

{
private $name = null;
public function __ construct(string $name)

{
$this->name = $name;
}

public function render(Request $request)
{

$reg = Registry::instance ();
$conf = $reg->getConf ();
$path = $conf->get ("templatepath’’) ;

406

ЧАСТЬ III * ШАБЛОНЫ
if (is_null($path)) {
throw new AppException("He найден каталог шаблонов!”);
}
$fullpath = "{$path}/{$this->name}.php”;
if (! file_exists(Sfullpath)) {
throw new AppException(”He найден шаблон для { $ fullpath}”);
}
include(Sfullpath);

}
}

Экземпляр этого класса получается по имени, которое затем использу
ется в методе render () во время визуализации вместе со значением пути
к шаблону из файла конфигурации. Ниже приведено определение класса
ForwardViewComponent для пересылки компонентов представлений.
// Листинг 12.26

class ForwardViewComponent implements ViewComponent
{

private Spath = null;

public function __ construct($path)
{

$this->path = Spath;

}
public function render(Request $request)
{

$request->forward($this->path);
}
}

В этом классе просто вызывается метод forward () для объекта типа
Request. Конкретная реализация метода forward () зависит от подтипа, произ
водного от Request. Так, для типа HttpRequest в этом методе устанавливается
заголовок "Location” (Местоположение), как показано ниже.
// Листинг 12.27
// Класс HttpRequest

public function forward(string $path)
{
header("Location:
exit;

{Spath}");

}

Что же касается типа CliRequest, то для пересылки нельзя полагаться на
сервер, поэтому придется выбрать другой подход:
// Листинг 12.28
// Класс CliRequest

ГЛАВА 12 « ШАБЛОНЫ КОРПОРАТИВНЫХ ПРИЛОЖЕНИЙ

407

public function forward(string $path)
{
// Добавить новый путь к концу списка аргументов,
// где преимущество получает последний аргумент
$_SERVER[’argv’] [ ] = "path:{$path}";
Registry::reset ();
Controller::run ();

Здесь выгодно используется тот факт, что во время синтаксического анали
за пути в массиве аргументов последнее обнаруженное совпадение в конечном
итоге сохраняется в объекте типа Request. Для этого нужно лишь ввести аргу
мент, задающий путь, очистить реестр и запустить контроллер на выполнение
сверху. А поскольку на этом завершается полный цикл, то здесь уместно сде
лать краткий обзор!
Стратегии, применяемые в контроллере приложения для получения представ
лений и команд, могут сильно разниться, но самое главное, что они скрыты от
остальной системы. На рис. 12.7 показан в общих чертах процесс, в ходе кото
рого контроллер приложения, построенный в классе AppController по шабло
ну Application Controller, применяется в классе Controller, созданном
по шаблону Front Controller, для получения сначала первой команды, реа
лизуемой объектом типа Command, а затем и представления.
Controller

AppController

Command

ViewComponent

I

getCommandO

parseFile($vcfile);
$reg->setCommands($commandandviewdata);

}

Класс Command

Теперь, когда команды больше не отвечают за отображение своих шаблонов,
целесообразно рассмотреть вкратце их базовый класс и его реализацию. Как
было показано ранее, в классе Command устанавливаются коды состояния, но в
нем выполняются и другие служебные операции, заслуживающие упоминания.
// Листинг 12.30

abstract class Command
{

const
const
const
const

CMD_DEFAULT = 0;
CMD—OK = 1;
CMD_ERROR = 2;
CMD_INSUFFICIENT_DATA = 3;

final public function __ construct()
{
}

public function execute(Request $request)
{
$status = $this->doExecute($request);
$request->setCmdStatus($status);
}
abstract public function doExecute(Request $request): int;

}

В удачном примере применения шаблона Template Method в методе
execute () вызывается абстрактный метод doExecute (), а возвращаемое

ГЛАВА 12 W ШАБЛОНЫ КОРПОРАТИВНЫХ ПРИЛОЖЕНИЙ

409

значение сохраняется в объекте типа Request. Это значение будет использова
но некоторое время спустя в объекте типа ComponentDescriptor для выбора
подходящего возвращаемого представления.
Конкретная команда

Ниже показано, насколько просто может быть реализована конкретная коман
да типа AddVenue.
// Листинг 12.31

class AddVenue extends Command

{
public function doExecute(Request $request): int

{
$name = $request->getProperty("venue_name");

if (is_null($name)) {
$request->addFeedback("Имя не указано! ");
return self::CMD_INSUFFICIENT_DATA;
} else {
// сделать что-нибудь
$request->addFeedback(”’{$name}' добавлено");
return self::CMD_OK;
}
return self::CMD_DEFAULT;
}
}

На самом деле здесь отсутствует функциональный код, связанный с построе
нием объекта типа Venue и его сохранением в базе данных, но мы до всего это
го еще дойдем. А до тех пор важно подчеркнуть, что выполняемая команда воз
вращает разные коды состояния в зависимости от сложившихся обстоятельств.
Как было показано ранее, разные коды состояния приведут к выбору и возврату
разных представлений из контроллера приложения. Так, если воспользоваться
приведенным ранее примером XML-файла конфигурации, то в результате воз
врата кода состояния CMD OK механизм пересылки запустит ее только по пути
/addspace. Причем это произойдет только для пути /addvenue. А если в запро
се, по которому вызывается данная команда, указан путь /quickaddvenue, то
никакой пересылки не произойдет и отобразится представление quickaddvenue,
хотя команде типа AddVenue об этом ничего неизвестно. Она просто придержи
вается своих основных обязанностей.
Выводы

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

410

ЧАСТЬ III

ШАБЛОНЫ

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

Шаблон Page Controller
Несмотря на то что мне очень нравится шаблон Front Controller, при
менять его целесообразно далеко не всегда. Применение данного шаблона на
стадии предварительного проектирования может иметь положительные послед
ствия для крупных систем и отрицательные для простых проектов, которые тре
бует быстро реализовать. И здесь может пригодиться шаблон Page Controller
(Контроллер страниц), с которым вы, вероятно, уже знакомы, поскольку он ча
сто выбирается в качестве общей стратегии проектирования. Тем не менее не
которые вопросы его применения все же стоит обсудить.
Проблема

И в данном случае задача состоит в том, чтобы управлять взаимосвязью за
проса, логики приложения и представления данных. В корпоративных проектах
это практически постоянная задача, а изменяются только накладываемые огра
ничения.
Так, если имеется относительно простой проект, где развертывание крупной
многофункциональной структуры приведет только к срыву сроков сдачи про
екта, не дав практически никаких преимуществ, то шаблон Page Controller
станет удобным инструментальным средством управления запросами и пред
ставлениями.
Допустим, требуется вывести страницу, на которой отображается список всех
культурных заведений в рассматриваемой здесь системе. Даже если у нас уже
имеется готовый код для извлечения такого списка из базы данных, без приме
нения шаблона Page Controller перед нами все равно встанет трудная задача
достижения такого простого на первый взгляд результата.
Итак, список культурных заведений должен отображаться на странице пред
ставления, и для его получения необходимо выполнить запрос. При обработке

ГЛАВА 12

ШАБЛОНЫ КОРПОРАТИВНЫХ ПРИЛОЖЕНИЙ

411

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

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

Навигация

Последние комментарии

Новое на форуме

Новое в блогах

Впечатления