ООП в php

Создание web-страницы теперь выглядит совсем не так, как в былые времена. Для организации сайта в наши дни обычно применяется множество различных технологий, в том числе: (X)HTML, CSS, JavaScript, SQL и серверные языки сценариев. Но это еще не все. Web-страница обычно отображается браузером. На рынке представлено несколько браузеров, и ведут они себя по-разному. Мало того, различия есть и в поведении разных версий одного и того же браузера. Даже одна и та же версия конкретного браузера может вести себя неодинакового в разных операционных системах, на разном оборудовании, при различной разрешающей способности экрана и т.д.

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

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

Так ли нам нужны объекты?

Имеющаяся в любом серверном языке сценариев возможность "включать" файлы в состав Web-страницы сокращает объём начальной работы и последующего сопровождения. Предположим, например что в верхней части любой страницы должно быть размещено меню - одинаковое для всех страниц сайта. Можно, конечно, копировать и вставлять один и тот же код в каждую страницу, но это утомительно и непродуктивно. Гораздо лучше написать такой код один раз и воспользоваться средствами языка сценариев для включения его в каждую страницу, где он необходим. Тогда, если потребуется изменить код, достаточно будет модифицировать всего один файл. Это очень упрощает сопровождение сайта, состоящего из множества страниц.

Такой подход можно описать фразой: «Включай и используй повторно; не пиши многократно». В некотором смысле объектно-ориентированное программирование (ООП) - обобщение этой идеи. Объекты упрощают разработку Web-приложений, устраняя необходимость копировать и адаптировать существующий код. Если бы полезность ООП была настолько очевидна, то внедрение этой технологии не встретило бы сопротивления. Однако это не так. Так познакомимся же с наиболее интересными аргументами против объектной ориентированности в области Web, чтобы покончить с мучительными сомнениями.

Всего лишь язык сценариев

РНР - язык сценариев. Ряд возражений против ООП опирается на этот факт.

Некоторые языки сценариев позволяют лишь выстраивать последовательности команд и потому часто именуются «клеем». Например, сценарий на языке оболочки (shell) может вызывать ряд команд операционной системы, чтобы не набирать их каждый раз заново. Из-за разнообразия требований к Web-странице может сложиться впечатление, что РНР - как раз такой язык: клей для удержания разнородных составных элементов страницы. Если использовать РНР только для этого, то, наверное, нет нужды в объектной ориентированности, она даже может стать помехой. С этой точки зрения, высказываемой часто , с пренебрежительным видом, объектно-ориентированные средства лучше оставить «настоящим» языкам программирования, а в языках сценариев - это лишняя обуза. Объектно-ориентированный язык сценариев - не более чем противоречивый термин; это язык, пытающийся «прыгнуть выше головы».

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

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

Объектная ориентированность - это для крупных фирм

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

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

Лучшее - враг хорошего

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

Компьютерные языки, равно как и их естественные собратья, должны меняться вместе с изменением окружающей обстановки, иначе рискуют стать непригодными. ООП не заменяет процедурного программирования и не делает его устаревшим. И вовсе не всегда ООП оказывается наиболее подходящим выбором, как бы ни стремились его адепты убедить вас в обратном. Но для некоторых задач, возникающих в ходе разработки программ для Web, просто необходимо решение, основанное на ООП. Кроме того, не обладая хотя бы минимальными знаниями об основах ООП, вы не сможете в полной мере воспользоваться достоинствами РНР 5. Например, единственный способ создать SOAP-клиента - прибегнуть к классу SOAPClient.

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

Это сложнее

Опасение чрезмерно увеличить сложность PHP-страниц часто выдвигается в качестве более тонкого возражения против перехода на ООП. Без сомнения, ООП иногда вносит нежелательное усложнение - достаточно взглянуть на множественное наследование в С++ или на технологию Enterprise Java. Но с РНР такого не произошло, и есть основания надеяться, что и не произойдет. РНР, в первую очередь, - язык для разработки Web-приложений (наверное, именно поэтому в него так долго не внедрялись объектно-ориентированные расширения). А программирование для Web имеет свои особенности, именно ради них механизмы ООП все-таки были добавлены. Тот факт, что реализация ООП в РНР не всегда удовлетворяет ревнителей чистоты идеи, как раз и свидетельствует об этом. Даже в своей процедурной ипостаси РНР никогда не был особо элегантным и не претендовал на роль эталонного языка; он всегда был нацелен на решение конкретных задач для Web.

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

Культура РНР

Понятие культуры не часто ассоциируется с языками программирования, но взгляд на культуру РНР поможет понять специфику реализации ООП в этом языке. РНР - это язык с открытыми исходными текстами, который Расмус Лердорф (Rasmus Lerdorf) создал свыше 10 лет назад. Он обладает всеми признаками успешности: существует несколько лет, постоянно развивается, имеет устойчивое сообщество разработчиков и постоянного лидера — Расмус Лердорф по-прежнему играет очень активную роль в разработке.

РНР, безусловно, самый популярный язык для разработки Web-приложений, и главная причина его успеха - простота использования. Это не случайность, РНР специально был задуман как простой для использования язык. И об этой цели не забывали при его модернизации до уровня полнофункционального объектно-ориентированного языка. Например, один из новых классов в РНР 5 удачно назван SimpleXMLElement (simple - простой). С его помощью можно включить на страницу RSS-канал, написав всего четыре строчки кода.

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

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