Форум PHP

Стоит ли изучать вообще ООП ?. Просто многие программы можно писать ведь и без использования ООП. Для каких целей может использоваться ООП на PHP ?
Заранее спасибо.

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

в общем стоит обратиться к теории ООП изначально, без привязки вообще к какму-бы то ни было языку.

Согласен. Но еще одна главная особенность - скрытие реализации.

Эт точно!!! Полностью согласен ;)

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

Иерархия? А как насчет класса для работы с базами данных? Сначала абстрактный класс, затем для mysql, потом для mssql и т.д. Или класс, отвечающий за вывод html, например, класс вывода новостей, класс вывода чего-то там наследует класс вывода новостей и.т.д.
А какже отделение логики от кода?

Для создания такого интерфейса не требуются классы - это можно сделать при помощи набора функций-обёрток. Инкапсуляция - это не частная собственность ООП - ей пользуются уже 40 лет и вполне успешно. Более того, без инкапсуляции нельзя построить ни один большой проект, будь то с применением ООП или без оного.

Но с помощью классов это будет наиболее удобно. Полиморфизм тот же...

Кому как...

PS класс - это не контейнер для хранения функций - основная его задача увеличить повторное использование кода и снизить дублирование блоков.

Я знаю, что класс в первую очередь это атд. Вот потому (что атд) я и пишу, что удобнее. Полиморфизм же позволит не заморачиваться с наименованием методов. Разве можно такое сделать с помощью обычных функций?
Вот небольшой пример на моем блоге - http://www.phpforum.ru/index.php?automodule=blog&blogid=13&showentry=38

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

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

>Во-вторых, не вижу проблем с жизненным циклом объектов. Если таковые есть, то я про них не знаю.
Создание объектов требует дополнительной памяти и затрат процессора, если в C++ или Java объект один раз за всё время работы программы создался и один раз разрушился - это на общем фоне не заметно, а вот когда к вам приходит пару тыщ человек и для каждого создай и разрушь объект, да ещё средствами интерпретатора - производительность падает и сильно (этот факт отмечаемый многими - только Страуструпу (создателю C++) удалось свести накладные расходы по созданию объектов к нулю).

>В-четвертых, причем тут мода? Мода скорее на смешание логики и представления. :)
ООП здесь не причём, этого вполне можно добиться и без объектно-ориентированных средств. У ООП имеется своя ниша, при помощи этой методологии можно решать все задачи, но лишь часть из них, эффективнее, чем другими средствами - все остальные задачи решаются менее эффективно. За всё необходимо платить, например, операционная система точного времени менее эффективна чем любая другая, так как лишнее время она просто простаивает до очередного репера - это расплата за точность. За любую функциональность следует расплачиваться, временем, эффективностью, памятью, читабельностью или всем вместе взятым. В ООП расплачивамся читабельностью, а в случае PHP ещё и эффективностью. Поэтому там где у ООП традиционно сильные позиции - мы в выигрыше, там где слабые - в проигрыше. Да иерархия классов клиентов будет более эффективна на ООП - проще сопровождать код и пользоваться им в приложении, однако гостевая книга на ООП - это бред, так как класс больше нигде не будет использоваться никогда, а гостевая книга без ООП в три раза меньше, а следовательно содержит в три раза меньше ошибок и требует в три раза меньше усилий разработчика (Про исследования доказывающие пропорциональность количества ошибок от объёма кода можно почитать у Макконела).

Спасибо, понял.
Кстати, про гостевую книгу, если вы про мой тот пример, то это только пример.

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

FrameWork я уже разрабатываю. Там есть классы для работы с файлами, csv, базой данных, даже шаблонизатор сделал. Пусть будет на уровне фреймворка, т.к. это просто классы. Осталось только универсальный парсер xml файлов сделать - классы для чтения/записи xml файлов.
Правда, это только классы, которые принимают/возвращают массивы. объеденены они только классами исключений. К.л. еще более организованной структуры нет.

Для системы разделения логики и представления для пользователей сайта очень хорошо подойдет шаблонизатор (пассивный, т.е. который только что-либо выводит), например, мой.

Когда доделаю, может быть выложу это все в паблик, если доделаю.

P.S. Кстати, чтобы что-то разработать более полезное, надо бы узнать как разрабатывать это полезное.

А что такое FrameWork?

Набор классов.

Который объединен в одну логическую структуру. Например, классами исключений, обработкой ошибок, и т.д.

а какже класс для разделения пользовательских полномочий, например, класс admin(с большими полномочиями) наследует класс manager ( c ограниченными), который, в свою очередь, наследует класс user (полномочия которого предназначины на просмотр, а не на редактирование)?

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

Спасибо всем за ответы =)