Форум PHP

эту читал в электронном. неплохая, согласен..

сейчас ищу всё что в большей степени связано с ооп

В электронном, к сожалению, нет.

Но есть электрокнига Джорджа Шлосснейгла. РНР - Профессиональное программированиие. Она немного о другом, но, на мой взгляд, достойна внимания, поскольку сильно отличается от семейства книг, ака переписанныйМануал

может у вас есть эта книга в эл. виде?

"...стоит иметь ввиду знаменитый девиз Perl: "Любую задачу можно решить несколькими способами". Это особенно верно для небольших сценариев, когда быстро получить рабочий код и запустить его важнее, чем создать структуру, которая сможет эффективно и безболезненно вырасти в большую систему (в мире экстремального программирования наспех разрабатываемые проекты такого рода называют пробнымии решениями)" (С) Мэтт Зандстра.

Тут было упоминание о его книге "РНР. Объекты, шаблоны и методики программирования" - щас чего то его не заметил, но +100500 к тому посту, ибо книга действительно на редкость прекрасна.

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

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

> Но я реально видел программы размером в 100 строк, использующих классы
Не в последнюю очередь благодаря авторам таких программ РНР называют языком быдлокодеров.

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

Наверное поэтому я пока и не въехал, зачем оно тут. Но я реально видел программы размером в 100 строк, использующих классы (размером в 98 строк, 2 другие строки программы были применением класса). И мне не давало покоя то, что я не мог понять гениальность данного кода. Переписывая его набором операторов, я сокращал код вдвое-втрое и пытался понять, в чем мой косяк, что я теряю, отказавшись от класса. Теперь мне становится интересным, какую цель приследовали люди, одевая в классы даже ОДНОРАЗОВЫЙ код. Похоже, это уже просто сила привычки...

Раньше программы писали без функций. Но со временем программы стали усложняться и повторяющегося кода стало очень много. Решили выделять код в функции. Функция — это blackbox, превращающий входные данные в выходные по определённым правилам.
С течением времени программы ещё более усложнились и процедурный подход стал неудобен. Появилась новая парадигма — ООП, где класс — форма для штамповки объектов со своими определёнными свойствами и поведением. Если рассматривать объект как хранилище функций, то да, ООП не имеет смысла. Не всякая задача решается средствами ООП (особенно задачи уровня "Hello world!", как в вашем примере). В РНР таких задач очень мало.