Розвиток об'єктної орієнтованості 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 ():
function
myFunction ($ arg) (
$ arg = 5;
)
?>
і ви викликаєте цю функцію:
$ myArgument = 7;
myFunction ($ myArgument);
print $ myArgument;
?>
Як ви, напевно, знаєте, виклик myFunction () не
змінить $ myArgument; передане в myFunction () - це копія значення
$ myArgument, а не сама змінна $ myArgument. Цей спосіб передачі аргументу
називається передачею аргументів за значенням. Передача аргументів за посиланням (По-моєму,
- Це помилка, думаю, малося на увазі - "за значенням". ) Реалізована
майже в усіх структурованих мовах і надзвичайно корисна, оскільки дозволяє
вам писати свої або викликати чужі функції, не турбуючись про побічні ефекти,
які вони можуть зробити на "зовнішні" для них змінні.
Однак розглянемо наступний приклад:
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 () так:
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, нова версія забезпечить гігантський стрибок вперед для тих, хто
зацікавлений в його об'єктно-орієнтованих можливості - особливо для
компаній, що розробляють великомасштабні програми.
Список літератури
Для підготовки даної роботи були використані
матеріали з сайту http://www.realcoding.net/
