Прощу людей знающих подсказать мне и другим новичкам в PHP, какими соображениями пользоваться при выборе модели(подхода) для написания скрипта - ООП или структурное программирование? Для реализации ООП приходится идти на определенные жертвы, нагрузка на ресурсы машины увеличивается. Но вместе с этим ООП дает то, ради чего был задуман - более удобный вид исходных кодов, более удобный подход в постоении логики программы. Для современных ПК проблема ресурсов не так важна и поэтому приимущества ООП имеют более высокий приоритет, чем его недостатки. Но даже в десктоп-приложениях встречается практика - критические участки кода писать более эффективными, с точки зрения производительности, методами. Поэтому учитывая специфику веб-программирования, специфику выполнения скриптов, хочу понять основные моменты, которыми стоит руководствоваться при выборе модели программирования. Как я понимаю все же не стоит полностью все делать с помощью ООП, только из за того что это "красива" или "модно"? Вот например писать ли класс, даже если в этом скрипте будет всего лишь один его экземпляр? Создание и удаление, один раз, набора переменных более эффективно, чем создание и удаление одиночного экземпляра класса?
Почему нет? http://ru.wikipedia.org/wiki/Singleton Надо не придерживаться одного стиля, надо их совмещать. А вобще на эту тему множество споров, в том числе и на это форуме.
Вы уже убили тысячу процентов производительности выбрав PHP вместо C, стоит ли экономить еще 7? Выбросьте их головы эту ерунду… если вам нужно написать критичный к ресурсам участок кода, то вы пишите extension для PHP на С (м.б. даже с ассемблерными вставками, если все настолько плохо ;-)). На данный момент написание класса избавляет от проблем с namespace, т.е. если все переменные и функции находятся внутри класса вы не засоряете глобальное пространство имен. Но это все было про структурные свойства языка PHP. На самом деле самое главное — это подход. Можно и объектный подход реализовать на функциях-переменных (GTK — отличный тому пример), можно и наоборот.
Я сам "люблю" ООП! Но иногда думаю что не разумно использую ООП из-за этой "влюбленности"! Sergey89 По ссылке мне очнь понравился пример для PHP5 - красиво! ) С этим я согласен! Но вопрос не в этом. AlexGousev ну это не серьезно вы! ) php проще для хостеров, да и для разработчиков, (хотя думаю и С++ с нужним набором библиотек подошел бы) А вообще я золотую середину исщу Ну вообщем и я про это. У меня вопрос в том, какими соображениями руководствоватся в коких-то конкретных ситуациях. Мож подскажите из своего опыта? Все таки ООП "жрет" ресурсы не плохо, особенно такие механизмы как наследственность и виртуальные методы,из-за которых происходит создание разных таблиц указателей, конроль над всем этим очень ресурсоемкий. Вот инкапсуляция - это действительно очень удобно и наверное это единственное где не стоит "парится" о проблеме соотношения пользы/затраты.
cgi практически на любом хосте выполняются ещё со времён, когда php был не везде не факт. если php - как модуль апача и компилиться всё один раз - то быстрее, чем рожать отдельный процесс для выполнения Cшной cgi. или ты про то, что стоило сразу свой модуль к апачу писать вместо некого php скрипта? а можно ещё http сервер сразу заточеный под решение определённой проблемы писать... http-cms-server например )
а почему бы и нет а откуда увереность что интерпретирование PHP кода будет быстрей даже если php-как модуль, чем запуск аналогичного по функциональности но написаного на си cgi? может все таки запуск отдельного процесса быстрее будет чем обработка строкового PHP-файла? Наверное смотря какой скрипт. И еще я не знаю можна ли php-код как то в исполняемый компилить, что-то вроде слышал, надо поискать
QQQ по-моему CGI был уже тогда когда PHP ещ вообще не было, и был он задуман для упрощения написания CGI-скриптов Поэтому этого не пойму: Ну и в чем же тогда "сила" PHP, если не в упрощении программировании под веб, и не в упрощении контроля (отладки, хостером и т.д.)
Честно говоря сейчас программирую процедурно (не использую ООП и классы). С глобальностью (namespace) пока проблем не было. Да и задачи, для которой ООП бы понадобилась пока тоже нету. Даже крупный проект у меня пишется на функциях. Имхо - дело вкуса и удобства для самого программиста, не более того
Так или иначе почти все программисты приходят к ООП, даже во времена PHP4. Раньше это было просто удобнее читать. С появлением PHP5, ООП в пхп становится всё больше похожим на настоящее ООП, поэтому всё больше преимуществ, поэтому всё быстрее люди будут переходить на ООП. имхо.
Все, что я хотел сказать, это то, что стоит исключить «производительность» при выборе между функциями и классами. Инкапсуляция — это все же несколько другое. Никогда код в виртуальной машине не будет быстрее код для хост-системы, даже если сама vm уже висит в памяти. Но дело не в этом. Дело в том, что при выборе между классами и функциями пытаться делать выбор на основе производительности бессмысленно. Можно. И в определенных случаях так оно и делается. Только еще чаще пишется extension для скриптовых языков и сервер. На компилируемых языках на самом деле много не писали, сразу поняли, что надо юзать PERL. Собственно первые две (две, да? или 3-я тоже?) версии были написаны на PERL'е. Именно в том и сила, что четко заточен под программирование под web. Это скриптовый язык. Он будет выдавать ошибки, писать, что что-то не так вместо того, чтобы ронять весь web-сервер (как это могло происходить с CGI-программами на С). PHP существенно снижает требования к квалификации программиста — в этом его второй плюс. Сколько человек участвует в проекте?Насколько много из того, что будет написано будет унифицированно и использоваться в других проектах? Забыли о других программистах которые вынуждены будут использовать то, что вы сделали
AlexGousev Скрытие приват переменных внутри класса, разве это не часть инкапсуляции зы я знаю что такое инкапсуляции
Я только несколько месяцев назад начал писать первые классы. Пока открыл для себя только 2 преимущества перед процедурным программированием: 1) Можно создавать некую систему адресов. Каждое действие находится в некой песочнице и имеет доступ только в некоторым обьектам игровой площадки, которая в свою очередь, может контактировать со всем миром. Получается очень удобно. 2) Написал 1 раз и пользуйся вечно. Можно быть увереным, что в новом скрипте ты не назовеш переменную или функцию уже существующим именем в давно созданной тобой библиотеке. Некое пространство имён. в РНР6 уже неактуально.
Ruzzz потому что разница, например, между вызовом пустой функции и вызовом пустого метода класса составлят 30%. При этом вызвать функцию миллион раз «стоит» 0,2с, а вызвать метод миллион раз стоит 0,27с… сколько вы сэкономите на этом в среднем скрипте: четыре с половиной килобайта памяти и 0,00004 секунды? Оно существенно? Основная фишка инкапсуляции — это все-таки скрытие реализации того или иного функционала, а не конкретных имен методов/переменных. Собственно обычная функция уже инкапсулирует некий функционал в себе, т.е. это определение применимо не только к классам. А скрытие имен переменных — лишь следствие.
не инкапсуляцию к ООП, а ООП к инкапсуляции, ибо это один из китов ООП. Хотя по мне основной столп ООП, конечно, наследование.
ооп - это частный случай структурного программирования. cgi - это интерфейс взаимодействия вэб-сервера с приложэнием. писать поддерживающие этот интерфейс программы можно на любом языке.
Это точно. И в любом случае, большая сишная cgi (например для обработки видео) выполнится существенно быстрее большой php-скрипта (который должен еще сначала скомпилироваться). Да и PHP ввиде CGI работает во многих случаях медленне Perl например. PHP для SAPI =) Возвращаясь к теме: Смысл создавать метод внутри класса с целью незасорения GLOBALS, если с этой целью отлично справляется простая функция? //Off Народ, подскажите пожалуйста хорошие статьи или ресурсы по ООП в PHP...
Касательно ООП, или касательно ООП в PHP ? Дело в том, что ПХП классы итак обладают полиморфизмом, но позднее связывание (перегрузка методов) не реализуемо, поэтому смысл интерфейсов в нем практически отсутствует, как таковой. Это скорее, задел на будущее, для PHP 6.