 |
Ограничения прежней объектной модели
|
|
|
|
Развитие объектной ориентированности PHP
Перевёл Бресь Сергей, http://phpclub.ru/
Одной из главных составляющих планируемой 5-й версии PHP станет Zend Engine 2.0, поддерживающий совершенно новую модель объектно-ориентированного программирования. Эта статья описывает развитие поддержки объектно-ориентированного программирования в PHP, включая новые возможности и изменения, запланированные в PHP 5.
Как всё это начиналось?
Об этом знают немногие, но когда то, что сегодня известно как PHP, только формировалось летом 1997 года, — не планировалось, что оно будет иметь какие-либо объектно-ориентированные возможности. Andi Gutmans и я работали над созданием мощного, надёжного и эффективного web-языка, основанного главным образом на PHP/FI 2.0 и синтаксисе языка C. В сущности, мы были достаточно далеки от каких-либо намерений относительно классов или объектов — это должен был быть просто структурированный язык. Однако, в одну из тех летних ночей, 27 августа всё изменилось.
Классы были добавлены в код, ставший основой версии PHP 3.0. Добавлены они были как синтаксическое украшение для организации доступа к наборам данных. PHP уже поддерживал понятие ассоциативных массивов, и добавленное новшество было ничем иным, как новым необычным способом доступа к подобным наборам. Тем не менее, как показало время, этот новый синтаксис оказал гораздо более серьёзное влияние на PHP, чем планировалось изначально.
Ещё одним неизвестным для большинства фактом является то, что в пору официального появления PHP 3.0 в середине 1998-го, когда он ошеломляющими темпами набирал силу, Andi Gutmans'ом и мной уже было решено переписать реализацию языка. PHP мог нравиться пользователям в существующем виде (на самом деле, мы знали, что он им нравится), но как создатели двигателя мы знали, что творится под капотом, и мы не могли с этим мириться. Переписанный код, позже получивший прозвище 'Zend Engine' (Zend является комбинацией Zeev и Andi), положил начало и стал одной из основных составляющих второй перестройки, которую пережил PHP за период чуть более года.
|
|
|
Тем не менее, эта перестройка оставила объектную модель PHP, по большей части, не изменившейся с версии 3 — она всё ещё была упрощённой. Объекты до сих пор в значительной мере были синтаксическим украшением для ассоциативных массивов и не предоставляли пользователям достаточного количества дополнительных возможностей.
Объекты в прежние времена
Итак, что мы могли делать с объектами во времена PHP 3.0 и даже в текущей версии PHP 4.0? На самом деле, — немногое. Объекты были по сути дела хранилищами свойств, наподобие ассоциативных массивов. Наибольшим отличием являлось то, что объекты должны были принадлежать к какому-либо классу. Классы, как и в других языках, содержали набор свойств и методов (функций), и экземпляры объектов могли создаваться из них с помощью оператора new. Поддерживалось единичное наследование, позволяющее пользователям расширять (или сужать) рамки существующего класса без необходимости писать класс наново или создавать его копию. Наконец, PHP 4.0 также добавил возможность вызывать методы заданного класса как в контексте использования объекта, так и вне его.
Одним из важнейших поворотных моментов в истории PHP было то, что, несмотря на очень ограниченную функциональность и массу проблем и ограничений, объектно-ориентированное программирование в PHP процветало и становилось самой популярной парадигмой увеличивающегося числа законченных PHP-приложений. Эта тенденция, бывшая по большей части неожиданной, поставила PHP в невыгодное положение. Начинал проявляться тот факт, что объекты вели себя не как в других ОО языках, а как ассоциативные массивы.
|
|
|
Ограничения прежней объектной модели
Самой проблематичной стороной объектно-ориентированной модели PHP 3 / PHP 4 было то, что объекты передавались по значению, а не по ссылке. Что это означает?
Скажем, у вас есть простая, несколько бесполезная функция, называемая myFunction():
<?php
function myFunction($arg) {
$arg = 5;
}
?>
и вы вызываете эту функцию:
<?php
$myArgument = 7;
myFunction($myArgument);
print $myArgument;
?>
Как вы, наверное, знаете, вызов myFunction() не изменит $myArgument; переданное в myFunction() — это копия значения $myArgument, а не сама переменная $myArgument. Этот способ передачи аргумента называется передачей аргументов по значению. Передача аргументов по ссылке { По-моему, — это опечатка; думаю, имелось в виду — "по значению". } реализована почти во всех структурированных языках и чрезвычайно полезна, так как позволяет вам писать свои или вызывать чужие функции, не беспокоясь о побочных эффектах, которые они могут оказать на "внешние" для них переменные.
Однако рассмотрим следующий пример:
<?php
function wed($bride, $groom) {
if ($bride->setHusband($groom);
$groom->setWife($bride)) {
return true;
} else {
return false;
}
}
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 уже будут проживать первый из своих оставшихся дней совместной жизни.
|
|
|
