ООП: да или нет? [PHP + MySQL]

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

p.s. А если этот же код переписать на асме? Безо всяких там ООП - их там просто нет. Понятно, что имеется в виду обьемы кода, при которых такой фактор как продуманность системы не будет значимым, Вы же заявили, что удобство для программистов это только побочный эффект ООП. Вы станете утверждать, что такой код станет работать медленнее?

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

Книга М. В. Кузнецов и И. В. Симдянов "Объектно-ориентированное программирование на PHP" 2007 + CD - price 290 rub. -
1.6 В РНР элементы ООП подхода не отлажены до конца.

Цитата ("dervinar"):

dervinar

в общем случае код с ооп и без него не будет не лучше не хуже, ни быстрее не медленнее.

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

если говорить о прикладном программировании там надо немного с другой стороны подходить. нельзя объять необъятное и будем говорить о windows.
в ос уже есть объекты, средства доступа к ним и их использования. на чем бы вы не писали принципиальной разницы не будет. и не забывайте что объект - это всего лишь кусок кода в памяти, который не подвешивает систему и до него можно добраться срествами системы.
Цитата ("dervinar"):

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

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

ну а что лучше, что хуже (ооп или без него) без конкретного задания иногда довольно трудно сказать. например создать окно в windows можно непосредственно через winapi, а можно через стандарный класс. в любом случае все закончится вызовом winapi, но если этих окон надо создать 1000? что лучше обращать напрямую к winapi задавая и вычисляя кучу параметров или использовать объект, которому нужно установить пяток-другой число-буквенных свойств?
едиственным реальным критерием как правило является сама ос. если она уже заточена под использование ооп, то лучше его и использовать.

Не могу не отметить:

Цитата ("dervinar"):

... Код без использования ООП, начиная с определенной сложности проекта становится написать практически невозможно - начинают плодиться баги и "костыли". ...

Такие, без сомненья, сложные проекты как ядро Linux (сотни разработчиков), ядро FreeBSD (также, сотни разработчиков), все системные программы UNIX, в частности Linux (сотни программ, тысячи разработчиков) и многие, многие другие, в частности, вся системы OS/MVS IBM (тысячи разработчиков, миллионы строк исходного текста) или, например, программное обеспечение для решения "задачи сближения двух тел" написаны без всякого ООП и при этом прекрасно работают. Все это, на самом деле, вопрос организации процесса разработки, а не отдельно взятой технологии программирования.

Цитата ("Illarion_SA"):

Такие, без сомненья, сложные проекты как ядро Linux (сотни разработчиков), ядро FreeBSD (также, сотни разработчиков), все системные программы UNIX, в частности Linux (сотни программ, тысячи разработчиков) и многие, многие другие, в частности, вся системы OS/MVS IBM (тысячи разработчиков, миллионы строк исходного текста) или, например, программное обеспечение для решения "задачи сближения двух тел" написаны без всякого ООП и при этом прекрасно работают. Все это, на самом деле, вопрос организации процесса разработки, а не отдельно взятой технологии программирования.

Хотел отдельно упомянуть об этом, но забылось как-то... Спасибо, что напомнили. Слово "практически" подчеркнуто не зря. Можно сделать все, вопрос, будет ли это обоснованно. В приведенных Вами примерах это обоснованно.
Просто операционная система, такая как Linux и FreeBSD станет нахрен никому не нужна если её переписать через классы, т.к. она станет работать не просто на десятки процентов - в разы медленней и больше кушать памяти. Поэтому программистам приходится мучаться. Вы абсолютно правильно сказали, вопрос организации процесса. Но в общем и целом, на это было потрачено куда больше человеко-часов(а в случае с коммерческими разработками еще и денег), чем могло бы быть. Опять таки, повторюсь, в случае ОС, да и вообще, в любых задачах, требующих большого колличества вычислений отказ от ООП обоснован и усложнение процесса разработки окупится более качественным продуктом.

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

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

Подскажите пожалуйста какую нибудь среду разработки для PHP что бы можно было использовать ООП. Есть что нибудь на подобии студии?

ZendStudio

Лично мне кажется что большенство web-developer-ов тратят меньще всего времени и сил своей мозги на раздумия типа:
"как бы написать то-то, то-то чтоб не дай бог не добавить пару другую процентов нагрузки на хард сервера", (в смысле хард-устройств)
гораздо больще времени уделяется минимизации времени создания страницы, хотя сейчас и это становится все менее и менее важным
(по прогнозам Microsoft через пару лет, в нете, на человека, будет около 130 Гбайт данных, сейчас около 8 Гбайт, на душу)

моя мысля...


так давайте же обсудим не качество того или инного способа программирования в смысле времени
а в смысле облегчения разработки, поддержки, обновления/изменения и тд и тп


лично мне интересней как лутче написать хороший и понятный всем скрипт, узнать приемы программирования для улутчения конечного продукта,
чем какой способ программирования вернет обработанный результат клиенту быстрей (0,130 сек VS 0,140 сек)

Цитата ("develop-master"):

Подскажите пожалуйста какую нибудь среду разработки для PHP что бы можно было использовать ООП. Есть что нибудь на подобии студии?

ZendStudio на любителя. уж очень много внимания они уделяют своим собственным изделиям. к тому же последнее время много "сырых" кусков.
Если нужен только код на мой взгляд лучше PHP Expert Editor трудно найти. и для снг бесплатный.
если нужен еще и визуальный редактор страниц - Dreamweaver или Delphi for PHP. помимо хорошей автоматизации допускают полное ручное редактирования всего.
если нужно так чтобы не лазить в потроха - NetObjects Fusion или что-то подобное.

Цитата ("elosoft"):

ZendStudio на любителя. уж очень много внимания они уделяют своим собственным изделиям

Ну правильно, проект должен развиваться или сделать v1.0 и бросить?
Самые признаные сообществом IDE это Eclipse(PDT или Aptana) и NetBeans и они кроссплатформенные.
PHP Expert Editor по моему УГ он ничего кроме элементарных айдишных функций не умеет.

Цитата ("golinsky"):

Ну правильно, проект должен развиваться или сделать v1.0 и бросить?

должен, но не за счет пользователей.
Eclipse, NetBeans - а вы ими пользовались? я - да.
а PHP Expert Editor - классический техтовый редактор для PHP, основанный на типовом использовании родной php-справки и php-документатора. он не для чего кроме текста не предназначен. зато по скорости и "типизованности" под php другой такой найти трудно.

p.s. кстати зашел сейчас на aptana.com. у меня всегда включена отладка и сообщения об ошибках. замучался гасить окно ошибок. что раньше так было, что сейчас. это оставляет неприятный осадок, тем более для конторы, предлагающей "признанную" ide.

p.s.s. забавно, на netbeans.org та же хрень, правда только на главной странице...

Цитата ("egoistu"):

...
лично мне интересней как лутче написать хороший и понятный всем скрипт,

Пишите свои скрипты так, как Вы хотели бы чтобы из писали для Вас.

Цитата ("egoistu"):

. узнать приемы программирования для улутчения конечного продукта,

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

Цитата ("elosoft"):

Eclipse, NetBeans - а вы ими пользовались? я - да.

ну естественно )) и пользуюсь, причем не только для php, например netbeans для ruby а php, python eclipse
Цитата:

а PHP Expert Editor - классический техтовый редактор для PHP, основанный на типовом использовании родной php-справки и php-документатора. он не для чего кроме текста не предназначен. зато по скорости и "типизованности" под php другой такой найти трудно.

вот я и о чем и говорю что например написание проекта где больше 20 классов, это убийство, а для 10-20 строчек php -a, ipython, irb и по скорости php expert editor не сравниться ))
я к тому что человек спросил ide, а вы советуете какой то полудоделанный виндовский блокнот который даже близко на ide не походит, при этом облаживая zend, eclipse, netbeans

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

хотя Ваш совет наверное всеравно, везде и всегда будет на 1-ом месте

ИМХО: это первое с чего надо начинать учение, дабы не переписивать через месяц, другой, тот-же отрывок кода который
не понятно где и каким образом завалялся в поза-поза-прошлом проекте, и в котором нифига не понятно, кто чей папа.

Таким темам место на holywars.ru
По теме: Да.

egoistu, такого не бывает чтобы всем было хорошо и понятно сходу т.е. код написанный кем то другим воспринимался как свой
к примеру взять роутинг, одним например нравится организация в стиле ruby on rails, zend framework, symfony другие любят просто htaccess, третьи любят явное задание с помощью regexp, соответсвенно программисты пишут классы под себя, причем от движка к движку по разному
например использовали вы раньше php 5 и тут решили перейти на php 5.2 а там уже много полезных функций reflections, контроль типа и т.д. и вы хотите их использовать во-первых это опыт использования вещей которые есть в других языках но в php только начинают появляться во-вторых это реальное развитие, потому что время от времени вам придеться подсматривать эту же реализацию в других языках, если конечно программирование интересно, если написать один один абстрактный класс и только его постоянно использовать, это уже не программирование а какой то копипаст который в итоге ничего кроме деградации не даст, можете всю жизнь использовать фреймворк это вам облегчит работу но так и не научитесь писать нечто похожее, и это будет создавать трудности если захочеться сделать шаг влево от этого фреймворка
глупо предполагать что процедурно или ооп или аоп может вам облегчить все ньюансы, эти подходы и были созданы для того чтобы применять где удобно а не чтобы стать фанатиком какого то одного из них

Можно спорить сколько угодно но по сабжу ответа нет и явное тому доказательно языки которые не имеют ооп реализации(например С), но их применяют везде даже в перевес таким монстрам как java и красивостям как ruby

golinsky, я отлично понимаю что написать абсолютно универсальную CMS или подстраиваемые модули, чтоб на любой вкус, и чтоб всем угодить... не получится
разве что разработать ИИ, настоящий ИИ, а не пародии (на сколько мне извесно такой еще не родился), получить за него Нобелевскую премию,
и давать ему только указания - сделай то, сделай это...

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

очень хочется увидеть что-то на подобе:
я написал

function procedure() {

    // aaa

} 

но время спустя выяснилось что лутче

function procedure() {

   // bbb

}

или

class oop {

    function __construct() {

        /// bbb

    }

}