Развитие об'єктної орієнтованості PHP

Развитие об'єктної орієнтованості PHP

Перевёл Бресь Сергій, internet.

Одной з головних складових планованої 5-ї версії PHP стане Zend Engine 2.0, підтримуючий цілком нову модель объектно-ориентированного програмування. Це стаття описує розвиток підтримки объектно-ориентированного програмування в PHP, включаючи нові можливості та, заплановані в PHP 5.

Как усе це начиналось?

Об цьому мало хто знає, але сьогодні відомий як PHP, лише формувалося влітку 1997 року, — не планувалося, що матиме будь-які об'єктно-орієнтовані можливості. Andi Gutmans і я працювали створення потужного, надійної й ефективного web-языка, заснованого головним чином PHP/FI 2.0 і синтаксисі мови З. По суті, ми були досить далекі від якихось намірів щодо класів чи об'єктів — це мав бути просто структурований мову. Проте, однієї із тих літніх ночей, 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 і аналогічних сім відповідно. Ці целочисленные дескриптори вказуватимуть на осередки у якійсь глобальної таблиці об'єктів, де є справжні об'єкти. Коли ми передамо в wed (), локальні перемінні $bride і $groom отримають значення 4 і аналогічних сім; setHusband () змінить об'єкт, який посилається 4; setWife () змінить об'єкт, який посилається 7; і коли wed () закінчить виконання, $joanne і $joe вже буде проживати перший із своїх решти днів спільної жизни.

Что це все означає для кінцевих пользователей?

Таким чином, кінець казки тепер більш ідилічний, але це означає для пишучих на PHP? Це означає кілька речей. По-перше, це, що ваші докладання робитиметься швидше, оскільки буде набагато менше операцій копіювання даних. Наприклад, як ви передаёте $joe до функцій, замість необхідності створювати дублікат і копіювати його ім'я, дату народження, по батькові, список колишніх адрес, номер соцзабезпечення і… що там ще? — PHP повинен передати лише одне дескриптор об'єкта, одне число. Звісно, прямим результатом від цього є також економія значного обсягу пам’яті — зберігання цілих чисел потребує значно менше місця, ніж зберігання всього об'єкта повністю.

Но, можливо, важливішим і те, нова объектная модель робить объектно-ориентированное програмування на PHP набагато потужнішим і інтуїтивним. Ви не мають будете плутатися з загадковими символами & у тому, аби виконати завдання. Ви большє нє повинні будете піклуватися про те, переживуть зміни, внесені вами в об'єкт всередині конструктора, яка наводить жах поведінка оператора new. Ніколи большє нє потрібно залишатиметься до двох ночі, відстежуючи невловимі помилки! Добре-добре, можливо про нього що й збрехав, але, якщо серйозно, нова объектная модель дуже багато зменшує кількість помилок виду «лови-до-ночи », що з об'єктами. Натомість, це, що придатність використання PHP для великомасштабних проектів стає набагато легше обосновать.

Что ще новенького?

Как можна було б очікувати, Zend Engine 2 містить значна частина інших властивостей, які узгоджуються з його нової об'єктної моделлю. Деякі їх покращують об'єктно-орієнтовані можливості, наприклад, приватні члени ВРЮ і методи, статичні перемінні і агрегирование лише на рівні мови. А найбільш значне — революційний рівень взаємодії з зовнішніми моделями компонентів, такі як Java, COM/DCOM і .NETy у вигляді перевантаження.

В порівнянні з Zend Engine 1 в PHP 4.0, що і запровадив цей вид інтеграції, нова реалізація набагато швидше, завершённее, більш надёжна і навіть легше підтримка і розширенні. Це означає, що PHP 5.0 буде дуже добре взаємодіяти з вашої системою з урахуванням Java чи .NETy, так як ви вже зможете використовувати наявні компоненти в 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, нова версія забезпечить гігантський стрибок вперед тим, хто зацікавлений у його объектно-ориентированных можливостях — особливо компаній, котрі розробляють великомасштабні приложения.

Список литературы

Для підготовки даної праці були використані матеріали із російського сайту internet.