объектно-ориентированное программирование

Объектно-ориентированное программиро­вание  PHP

Когда в начале 2004 года был выпущен PHP 5. в числе самых важных его функций была усиленная поддержка объектно-ориентированного програм­мирования. Это вызвало рост интереса к объектам и их разработке в PHP-сооб­ществе. На самом деле это был новый этап развития процесса, начавшегося благо­даря выпуску PHP версии 4, в которой объектно-ориентированное программиро­вание впервые стало реальностью.

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

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

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

Ваш новый программист изо всех сил старается понять код, который вам кажется простым и естественным, хотя, возможно, местами слегка запутанным. И этому новому программисту требуется больше времени, чем вы рассчитывали, чтобы войти в курс дела и стать полноправным членом команды.

На простое изменение, которое вы рассчитывали сделать за один день, уходит три дня, потому что вы обнаруживаете, что в результате нужно обновить порядка 20 веб-страниц.

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

Поскольку приложение популярно, вам нужно перенести код на новый сервер. Инсталляцию проекта нужно проводить вручную, и вы обнаруживаете, что пути к файлам, имена баз данных и пароли жестко закодированы во многих исходных файлах. На время этого перемещения вы останавливаете работу, потому что не хо­тите затереть изменения конфигурации, которых требует этот переход. Предпола­гаемые два часа работы превращаются в восемь, поскольку обнаруживается, что кто-то немного «поумничал», задействовав модуль ModRewrite сервера Apache, и теперь для нормальной работы приложения требуется, чтобы этот модуль функ­ционировал на сервере и был правильно настроен.

Вы, наконец, запускаете этап 2. Полтора дня все идет хорошо. Первое сообще­ние об ошибке приходит в тот момент, когда вы собираетесь уходить с работы домой. Еще через минуту звонит клиент с жалобой. Его сообщение об ошибке на­поминает предыдущее, однако в результате более тщательного анализа обнаружи­вается, что это другая ошибка, которая вызывает похожее поведение. Вы вспоми­наете о простом изменении в начале данного этапа, которое потребовало серьезно модифицировать остальную часть проекта.

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

На следующее утро, приехав в офис, вы выясняете, что модуль «корзины для по­купок» не работал всю ночь. Дело в том, что вчера, при внесении изменений в по­следнюю минуту, вы пропустили открывающиеся кавычки, в результате чего код стал нерабочим. Конечно, пока вы спали, потенциальные клиенты из других часо­вых поясов бодрствовали и были готовы потратить деньги в вашем интернет-магазине. Вы исправляете ошибку, успокаиваете клиента и мобилизуете команду для следующего дня «пожарной» работы.

Эта история о ежедневных буднях программистов может показаться преувели­чением. но все это мне случалось наблюдать неоднократно. Многие РНР-проекты начинались с малого, а затем превращались в гиганты.

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

Отсутствие документации делает код трудным для чтения, а отсутствие тести­рования позволяет незаметным ошибкам оставаться необнаруженными до момен­та развертывания приложения. А изменение основного бизнеса клиента часто оз­начает, что в результате модификации код меняет свое первоначальное назначе­ние, и в конце концов начинает выполнять задачи, для которых он в корне непригоден. И поскольку такой код, как правило, разрабатывался и развивался в качестве единой массы, в которой было много чего намешано, очень трудно, или даже невозможно, перестроиться и переписать его фрагменты, чтобы он соответ­ствовал новой цели.

Но все это совсем не плохо, если вы — независимый консультант по РНР. А если серьезно, то проблемы подобного рода как раз и отличают успешный бизнес от неудачного.

РНР и другие языки

Феноменальная популярность РНР означает, что он был основательно протес­тирован во всех сферах своего применения еще на начальном этапе развития. С появлением РНР 3 и, в значительной степени, РНР 4, этот язык быстро стал популярным и мощным инструментом создания крупных коммерческих веб-сайтов. Однако во многих случаях сферы его примене­ния ограничивались разработкой сценариев и средств управления проектами, как и первоначальные версии. В глазах некоторых специалистов, у РНР осталась не­справедливая репутация языка для любителей, который больше приспособлен для задач представления данных.

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

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

Сам язык Java использует многие основные шаблоны в своем API, но до конца 90-х годов шаблоны проектирования еще не завладели сознанием сообщества про­граммистов в такой степени. Книги о шаблонах быстро заполонили компьютерные разделы книжных магазинов, и на форумах появились первые флеймы со словами похвалы или неодобрения.

Возможно, вы думаете, что шаблоны— это мощный способ передачи информа­ции или, наоборот, что это просто «мыльный пузырь» (какой точки зрения придер­живаюсь я, очевидно из названия книги). Каким бы ни было ваше мнение, трудно отрицать, что подход к разработке программного обеспечения, который при этом пропагандируется, полезен сам по себе.

Родственные темы также стали более популярными. Среди них методология экстремального программирования (extreme Programming — ХР), одним из авторов которой является Кент Бек (Kent Beck). ХР — это подход к проектам, который на­правлен на гибкое, проектно-ориентированное, очень тщательное планирование и выполнение.

Один из важных принципов ХР— утверждение, что тестирование является ключевым фактором для успеха проекта. Тесты должны быть автоматическими, выполняться часто, и, желательно, чтобы они были разработаны до написания са­мого кода.

Еще одно требование методологии ХР — проекты должны быть разбиты на ма­лые (очень малые) итерации. И код, и требования к нему должны постоянно анали­зироваться. Архитектура и проект должны быть предметом постоянного совмест­ного обсуждения, что ведет к частому пересмотру кода.

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

С развитием и ростом популярности методологии ХР и шаблонов тестирование также стало ключевым вопросом. Важность автоматических тестов была еще более акцентирована с Появлением мощной тестовой платформы JUnit, которая стала главным инструментов в арсенале Java-программистов.

Версия PHP 4, более эффективная и с усиленной поддержкой объектов, вышла примерно в то же время. Благодаря этим улучшениям появилась возможность соз­давать полностью объектно-ориентированные приложения. Программисты вос­пользовались этой возможностью, к некоторому удивлению создателей ядра Zend Зива Сураски (Zeev Suraski) и Энди Гу гманса (Andi Gutmans), которые присоеди­нились к Расмусу Лердорфу (Rasmus Lerdorf) для разработки PHP. Как оказывалось, поддержка объектов в PHP была далеко не идеальной, но при вы­полнении тщательного контроля синтаксиса на PHP можно было писать объектно-ориентированные программы.

Тем не менее неприятности, слу­чались часто. Культура проектирования была еще не развита.Выход первой бета-версии PHP 5 в 2003 году обеспечил будущее PHP как языка объектно-ориентированного программирования. Движок Zend 2 Engine обеспечил существенно улучшенную поддержку объектов, как вы вскоре увидите. И, что не менее важно, его появление стало сигналом о том, что объекты и объектно-ориентированное проектирование теперь являются основой РНР-проекта.

Добавить комментарий