Статья: Развитие объектной ориентированности PHP
}
}
wed($joanne, $joe);
print areMarried($joanne, $joe);
?>
(Реализации Woman::setHusband(), Man::setWife() и areMarried() опущеныкакупражнениечитателю).
{ wed — "жениться", bride — "невеста", groom — "жених", husband — "муж", wife — "жена", areMarried — "ониженаты?" }
Что возвратит areMarried()? Можно надеяться, что двое новобрачных сумеют остаться женатыми, по крайней мере, до следующей строчки кода, но, как вы могли догадаться, — не останутся. areMarried() подтвердит, что они развелись, как только женились. Почему?
Причина проста. Из-за того, что объекты в PHP 3.0 и 4.0 не являются чем-то особенным и ведут себя как любые другие переменные, — когда вы передаёте $joanne и $joe в wed(), на самом деле вы передаёте не их. Вместо этого, вы передаёте их точные копии, дубликаты. Таким образом, хотя их копии и женятся в wed(), действительные $joe и $joanne остаются на безопасном расстоянии от таинства священного брака, в своей защищённой внешней области видимости.
Конечно, PHP 3 и 4 дают вам возможность принудительно передать переменные по ссылке, позволяя, таким образом, функциям изменять аргументы, переданные им из внешней области видимости. Если бы мы определили прототип wed() так:
<?php
function wed(&$bride, &$groom)
?>
то для Joanne и Joe всё сложилось бы более удачно (или менее, в зависимости от вашего на то взгляда).
Однако, всё намного сложнее. К примеру, что если вы хотите вернуть объект из функции по ссылке? Что если вы хотите вносить изменения в $this внутри конструктора, не беспокоясь о том, что может произойти, когда они в результате выполнения оператора new скопируются в переменную-контейнер? Не знаете, о чём я?.. Скажите "аллилуйя" { а лучше прочитайте раздел References inside the constructor из PHP Manual }.
Несмотря на то, что PHP 3 и 4 в определённой степени справлялись с этими трудностями, предоставляя синтаксические ухищрения для передачи объектов по ссылке, они никогда не брались за суть проблемы:
Объекты отличаются от остальных видов значений, следовательно,
объекты должны передаваться по ссылке, если не указано иного.
Решение — Zend Engine 2
Когда мы, наконец, убедились, что объекты — действительно создания особые и заслуживают особого поведения, это стало лишь первым шагом. Мы должны были предложить такой способ реализации этого, который не повлияет на остальную семантику PHP и, желательно, не заставит переписывать весь PHP. К счастью, решение пришло в виде луча света, вспыхнувшего над головой Andi Gutmans'а чуть более года назад. Его идея состояла в замене объектов дескрипторами объектов { в оригинале — object handles }. Дескрипторы объектов, по существу, будут числами, индексами в глобальной таблице объектов. Аналогично любым другим видам переменных они будут передаваться и возвращаться по значению. Благодаря этому новому промежуточному уровню, теперь мы будем работать с дескрипторами объектов, а не с самими объектами. В сущности, это означает, что PHP будет вести себя так, будто сами объекты передаются по ссылке.
Давайте вернёмся к Joe и Joanne. Как изменится поведение wed() теперь? Во-первых, $joanne и $joe больше не будут являться объектами, а станут дескрипторами объектов, скажем, 4 и 7 соответственно. Эти целочисленные дескрипторы будут указывать на ячейки в некой глобальной таблице объектов, где находятся настоящие объекты. Когда мы передадим их в wed(), локальные переменные $bride и $groom получат значения 4 и 7; setHusband() изменит объект, на который ссылается 4; setWife() изменит объект, на который ссылается 7; и когда wed() закончит выполнение, $joanne и $joe уже будут проживать первый из своих оставшихся дней совместной жизни.
Что это всё означает для конечных пользователей?
Таким образом, конец сказки теперь более идиллический, но что это означает для пишущих на PHP? Это означает несколько вещей. Во-первых, это означает, что ваши приложения будут выполняться быстрее, так как будет гораздо меньше операций копирования данных. Например, когда вы передаёте $joe в функцию, вместо необходимости создавать дубликат и копировать его имя, дату рождения, отчество, список прежних адресов, номер соцобеспечения и... что там ещё? – PHP должен передать лишь один дескриптор объекта, одно целое число. Конечно, прямым результатом всего этого также является экономия значительного объёма памяти — хранение целых чисел требует гораздо меньше места, чем хранение всего объекта целиком.
Но, быть может, более важным является то, что новая объектная модель делает объектно-ориентированное программирование на PHP значительно более мощным и интуитивным. Вы больше не должны будете путаться с загадочными символами & для того, чтобы выполнить задачу. Вы больше не должны будете заботиться о том, переживут ли изменения, внесённые вами в объект внутри конструктора, наводящее ужас поведение оператора new. Никогда больше не нужно будет оставаться до двух ночи, отслеживая неуловимые ошибки! Хорошо-хорошо, возможно о последнем я и солгал, но, если серьёзно, новая объектная модель очень значительно уменьшает количество ошибок вида "лови-до-ночи", связанных с объектами. В свою очередь, это означает, что пригодность использования PHP для крупномасштабных проектов становится гораздо легче обосновать.
Что ещё новенького?
Как можно было ожидать, Zend Engine 2 содержит довольно много других свойств, согласующихся с его новой объектной моделью. Некоторые из них улучшают объектно-ориентированные возможности, например, приватные члены и методы, статические переменные и агрегирование на уровне языка. Наиболее же значительное — революционный уровень взаимодействия с внешними моделями компонентов, такими как Java, COM/DCOM и .NET посредством перегрузки.
В сравнении с Zend Engine 1 в PHP 4.0, который впервые ввёл этот вид интеграции, новая реализация гораздо быстрее, завершённее, более надёжна и даже легче в поддержке и расширении. Это означает, что PHP 5.0 будет очень хорошо взаимодействовать с вашей системой на основе Java или .NET, так как вы сможете использовать существующие компоненты в PHP явно, как если бы они были обычными PHP-объектами. В отличие от PHP 4.0, который имел специальную реализацию для таких перегруженных объектов, PHP 5.0 использует один и тот же интерфейс для всех объектов, включая родные PHP-объекты. Эта возможность гарантирует, что PHP-объекты и перегруженные объекты ведут себя абсолютно одинаково.
Наконец, Zend Engine 2 также приносит в PHP обработку исключений. До настоящего времени печальной действительностью является то, что большинство разработчиков пишут код, не достаточно изящно обрабатывающий ошибочные ситуации. Не редко встречаются сайты, вываливающие в ваш браузер загадочные ошибки базы данных вместо показа правильно сформулированного сообщения "Произошла такая-то ошибка". В случае с PHP основная причина этого в том, что обработка ошибочных ситуаций — задача, приводящая в уныние; вы, фактически, должны проверять возвращаемое значение для всех и для каждой функции. С добавлением set_error_handler() справляться с этой проблемой стало полегче, так как появилась возможность централизовать обработку ошибок, но до желаемого решения оставалось всё ещё далеко. Добавление же обработки исключений в PHP даст возможность разработчикам отлавливать ошибки более мелким неводом, и, что более важно, поспособствует элегантному восстановлению после ошибок, в каком бы месте программы они ни произошли.
Заключение
Версия PHP 5.0, основанная на Zend Engine 2.0, ознаменует значительный шаг вперёд в развитии PHP как одной из основных на сегодня web-платформ в мире. Сохраняя свои твёрдые обязательства перед пользователями, предпочитающими использовать функционально структурированный синтаксис PHP, новая версия обеспечит гигантский скачок вперёд для тех, кто заинтересован в его объектно-ориентированных возможностях — особенно для компаний, разрабатывающих крупномасштабные приложения.