|
|
|
| Стоит ли изучать вообще ООП ?. Просто многие программы можно писать ведь и без использования ООП. Для каких целей может использоваться ООП на PHP ?
Заранее спасибо. | |
|
|
|
|
|
|
|
для: Sl
(20.02.2007 в 08:02)
| | ООП - это метод программирования, который позволяет большую расширяемость и наращивание кода, с возможностью СПОКОЙНО использовать уже написанный код, без таких заморочек типа, а не совпадают-ли две разные глобальные функции по имени из разных модулей, или не пересекуться ли переменные и т.д. и многое другое... я вычленил только самые понятные моменты.
в общем стоит обратиться к теории ООП изначально, без привязки вообще к какму-бы то ни было языку. | |
|
|
|
|
|
|
|
для: ZuArt
(20.02.2007 в 09:40)
| | Согласен. Но еще одна главная особенность - скрытие реализации. | |
|
|
|
|
|
|
|
для: t4f
(20.02.2007 в 10:07)
| | Эт точно!!! Полностью согласен ;) | |
|
|
|
|
|
|
|
для: Sl
(20.02.2007 в 08:02)
| | В PHP редко встречаются задачи, требующие применение ООП, это удел больших иерархических библиотек. Глупо разрабатывать один класс от которого никогда никто не будет ничего наследовать - так как подготовка класса требует больше усилий, чем функционального кода и окупиться эти усилия могут только при активном использовании наследования, а наследование в свою очередь нужно при иерархии... а вот тут затык, так как все сетевые интерфейсы и большинство баз данных разрабатывались без учёта объектно-ориентированного интерфейса и применять на полную катушку в PHP ООП очень сложно. | |
|
|
|
|
|
|
|
для: cheops
(20.02.2007 в 12:57)
| | Иерархия? А как насчет класса для работы с базами данных? Сначала абстрактный класс, затем для mysql, потом для mssql и т.д. Или класс, отвечающий за вывод html, например, класс вывода новостей, класс вывода чего-то там наследует класс вывода новостей и.т.д.
А какже отделение логики от кода? | |
|
|
|
|
|
|
|
для: t4f
(20.02.2007 в 16:59)
| | Для создания такого интерфейса не требуются классы - это можно сделать при помощи набора функций-обёрток. Инкапсуляция - это не частная собственность ООП - ей пользуются уже 40 лет и вполне успешно. Более того, без инкапсуляции нельзя построить ни один большой проект, будь то с применением ООП или без оного. | |
|
|
|
|
|
|
|
для: cheops
(20.02.2007 в 17:30)
| | Но с помощью классов это будет наиболее удобно. Полиморфизм тот же... | |
|
|
|
|
|
|
|
для: t4f
(20.02.2007 в 17:32)
| | Кому как...
PS класс - это не контейнер для хранения функций - основная его задача увеличить повторное использование кода и снизить дублирование блоков. | |
|
|
|
|
|
|
|
для: cheops
(20.02.2007 в 17:35)
| | Я знаю, что класс в первую очередь это атд. Вот потому (что атд) я и пишу, что удобнее. Полиморфизм же позволит не заморачиваться с наименованием методов. Разве можно такое сделать с помощью обычных функций?
Вот небольшой пример на моем блоге - http://www.phpforum.ru/index.php?automodule=blog&blogid=13&showentry=38 | |
|
|
|
|
|
|
|
для: t4f
(20.02.2007 в 17:38)
| | Так полимофрмизм применяется при иерархиях, когда разные сходные объекты необходимо снабдить одинаковыми в использовании методами, с совпадающими или отличающимися друг от друга реализациями. Никто не спорит о том, что ООП черезвычайно эффективен при решении задач связанных с иерархиями... вопрос в том, что такие задачи очень редко встречаются в PHP, а отсутствие сессионной связи с сервером (т.е. короткое время жизни объектов) суждает этот круг ещё больше. ООП в PHP не бесполезен - он менее эффективен, чем в других языках, например Java или C++, которые под ООП затачивались. Кроме того при практически полном отсутствии типизации и перегрузки операторов - ООП очень здорово теряет свою силу. ООП - это инструмент, который помимо сильных сторон имеет также и слабые стороны и создать неуклюжее приложение на нём также просто как и в процедурном стиле. Выбор инструмента определяется не модой, а его эффективностью - в окнонных приложениях вы шагу без ООП не ступите - там даже без объектно-ориентированного языка работают в объектно-ориентированном стиле, в PHP эффективность использования ООП очень часто под вопросом. | |
|
|
|
|
|
|
|
для: cheops
(20.02.2007 в 17:53)
| | Во-первых, то, что ООП в РНР менее эффективен я не спорю, особенно в неумелых руках.
Во-вторых, не вижу проблем с жизненным циклом объектов. Если таковые есть, то я про них не знаю.
В-третьих, действительно, типизация в РНР не помешала бы.
В-четвертых, причем тут мода? Мода скорее на смешание логики и представления. :) | |
|
|
|
|
|
|
|
для: t4f
(20.02.2007 в 18:05)
| | >Во-вторых, не вижу проблем с жизненным циклом объектов. Если таковые есть, то я про них не знаю.
Создание объектов требует дополнительной памяти и затрат процессора, если в C++ или Java объект один раз за всё время работы программы создался и один раз разрушился - это на общем фоне не заметно, а вот когда к вам приходит пару тыщ человек и для каждого создай и разрушь объект, да ещё средствами интерпретатора - производительность падает и сильно (этот факт отмечаемый многими - только Страуструпу (создателю C++) удалось свести накладные расходы по созданию объектов к нулю).
>В-четвертых, причем тут мода? Мода скорее на смешание логики и представления. :)
ООП здесь не причём, этого вполне можно добиться и без объектно-ориентированных средств. У ООП имеется своя ниша, при помощи этой методологии можно решать все задачи, но лишь часть из них, эффективнее, чем другими средствами - все остальные задачи решаются менее эффективно. За всё необходимо платить, например, операционная система точного времени менее эффективна чем любая другая, так как лишнее время она просто простаивает до очередного репера - это расплата за точность. За любую функциональность следует расплачиваться, временем, эффективностью, памятью, читабельностью или всем вместе взятым. В ООП расплачивамся читабельностью, а в случае PHP ещё и эффективностью. Поэтому там где у ООП традиционно сильные позиции - мы в выигрыше, там где слабые - в проигрыше. Да иерархия классов клиентов будет более эффективна на ООП - проще сопровождать код и пользоваться им в приложении, однако гостевая книга на ООП - это бред, так как класс больше нигде не будет использоваться никогда, а гостевая книга без ООП в три раза меньше, а следовательно содержит в три раза меньше ошибок и требует в три раза меньше усилий разработчика (Про исследования доказывающие пропорциональность количества ошибок от объёма кода можно почитать у Макконела). | |
|
|
|
|
|
|
|
для: cheops
(20.02.2007 в 19:00)
| | Спасибо, понял.
Кстати, про гостевую книгу, если вы про мой тот пример, то это только пример. | |
|
|
|
|
|
|
|
для: t4f
(20.02.2007 в 20:01)
| | Нет, это я просто для примера, просто когда начинают изучать ООП, почему то пытаются разработать гостевую книгу, хотя гораздо логичнее и полезнее было бы разработать FrameWork или действительно систему разделения логики и представления для пользователей сайта. | |
|
|
|
|
|
|
|
для: cheops
(20.02.2007 в 20:19)
| | FrameWork я уже разрабатываю. Там есть классы для работы с файлами, csv, базой данных, даже шаблонизатор сделал. Пусть будет на уровне фреймворка, т.к. это просто классы. Осталось только универсальный парсер xml файлов сделать - классы для чтения/записи xml файлов.
Правда, это только классы, которые принимают/возвращают массивы. объеденены они только классами исключений. К.л. еще более организованной структуры нет.
Для системы разделения логики и представления для пользователей сайта очень хорошо подойдет шаблонизатор (пассивный, т.е. который только что-либо выводит), например, мой.
Когда доделаю, может быть выложу это все в паблик, если доделаю.
P.S. Кстати, чтобы что-то разработать более полезное, надо бы узнать как разрабатывать это полезное. | |
|
|
|
|
|
|
|
для: cheops
(20.02.2007 в 20:19)
| | А что такое FrameWork? | |
|
|
|
|
|
|
|
для: tAleks
(26.02.2007 в 16:38)
| | Набор классов. | |
|
|
|
|
|
|
|
для: cheops
(27.02.2007 в 00:51)
| | Который объединен в одну логическую структуру. Например, классами исключений, обработкой ошибок, и т.д. | |
|
|
|
|
|
|
|
для: cheops
(20.02.2007 в 12:57)
| | а какже класс для разделения пользовательских полномочий, например, класс admin(с большими полномочиями) наследует класс manager ( c ограниченными), который, в свою очередь, наследует класс user (полномочия которого предназначины на просмотр, а не на редактирование)? | |
|
|
|
|
|
|
|
для: t4f
(20.02.2007 в 17:04)
| | Типичная иерархия - применение ООП оправдано - здесь действительно можно съэкономить время разработки и увеличить гибкость. | |
|
|
|
|
|
|
|
для: Sl
(20.02.2007 в 08:02)
| | Спасибо всем за ответы =) | |
|
|
|