socimedПрограмёрsocimed,

PHP не ООП?!!!! O_o
А как же я последних 3 года то работаю?! Почти всё в моих приложениях - это объекты (почти, потому что всегда-всегда их использовать - это разумеется лишнее).


Все за тебя очень рады, но вот парни из fb, vk и т.п. - они почему-то используют PHP строго в процедурном стиле, о чем и говорят на всех конференциях.

Наверное ты умнее их, как думаешь?

Лень качать свежие joomla/wordpress и прочие, но раньше там не было ООП тоже, хотя учитывая общие мировые тенденции к тотальном оглупению и наворотам оболочек на оболочки, возможно и какой Drupal уже тоже перевели на ООП, невозбранно увеличив response time до типичных 300-600 миллисекунд (супротив 30ms у лучших представителей жанра, при реально достижимом 3ms при переписывании с PHP на C)

ООП - это не язык, и не программа и не что Вы ещё там думаете...
ООП - это парадигма написания кода!!! Ну и молодцы, что они пишут не в ООП. А я пишу в ООП. И что теперь? В дэлфи тоже можно писать в процедурном стиле. Значит дэлфи не ОО язык? Значит и С++ не ОО язык? python?

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

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


Невозможно чего либо без ООП - это вообще очень интересное утверждение. )
ООП - это не "бустер", включив который можно увеличить скорость и эффективность. Зачастую эффект противоположный, но это не вина ООП. Как и всякая концепция, она имеет область применения, и требует ее глубокого понимания. Тогда ООП дает эффект, сокращающий время разработки, увеличивающий надежность и облегчающий поддержку кода. Для больших проектов - именно это наиболее актуально. Это сложно понять на примерах, которые присутствуют в книжках по ЯВУ с ООП.

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

Так что ООП лишь позволяет структурировать код и сделать его легче для восприятия... А вот уже оптимальная структура приложения ложится на плечи программиста.... И если это человек-дубень, который освоил ООП и считает себя гением, то никакое ООП его не выручит :) Но при одинаковой подготовке и хорошо продуманной заранее структуре, объектно-ориентированный код будет медленнее его процедурного аналога (соответственно менее эффективный), по надёжности оба варианта будут одинаковы.

Alibek B.ПрограмёрНо при одинаковой подготовке и хорошо продуманной заранее структуре, объектно-ориентированный код будет медленнее его процедурного аналога (соответственно менее эффективный), по надёжности оба варианта будут одинаковы.
Ну для каких-то задач именно объекты с методами и свойствами могут быть наиболее удобными.
Почему бы в этом случае не использовать готовые механизмы ООП, присущие используемому ЯП, а не писать свою корбу?

Я о том и говорю :) Это удобно... но НЕ БОЛЕЕ чем просто удобно :) Но многие тут используют термины "эффективнее", "быстрее", "надёжнее"... А другие (многие) руководители проектов на эти термины ведутся