Форум: Форум PHPФорум ApacheФорум Регулярные ВыраженияФорум MySQLHTML+CSS+JavaScriptФорум FlashРазное
Новые темы: 0000000
PHP 5. На примерах. Авторы: Кузнецов М.В., Симдянов И.В., Голышев С.В. Самоучитель MySQL 5. Авторы: Кузнецов М.В., Симдянов И.В. PHP. Практика создания Web-сайтов (второе издание). Авторы: Кузнецов М.В., Симдянов И.В. MySQL на примерах. Авторы: Кузнецов М.В., Симдянов И.В. Программирование. Ступени успешной карьеры. Авторы: Кузнецов М.В., Симдянов И.В.
ВСЕ НАШИ КНИГИ
Консультационный центр SoftTime

Форум PHP

Выбрать другой форум

 

Здравствуйте, Посетитель!

вид форума:
Линейный форум Структурный форум

тема: Для чего нужно ООП на php ?
 
 автор: Sl   (20.02.2007 в 08:02)   письмо автору
 
 

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

   
 
 автор: ZuArt   (20.02.2007 в 09:40)   письмо автору
 
   для: Sl   (20.02.2007 в 08:02)
 

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

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

   
 
 автор: t4f   (20.02.2007 в 10:07)   письмо автору
 
   для: ZuArt   (20.02.2007 в 09:40)
 

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

   
 
 автор: ZuArt   (20.02.2007 в 10:24)   письмо автору
 
   для: t4f   (20.02.2007 в 10:07)
 

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

   
 
 автор: cheops   (20.02.2007 в 12:57)   письмо автору
 
   для: Sl   (20.02.2007 в 08:02)
 

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

   
 
 автор: t4f   (20.02.2007 в 16:59)   письмо автору
 
   для: cheops   (20.02.2007 в 12:57)
 

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

   
 
 автор: cheops   (20.02.2007 в 17:30)   письмо автору
 
   для: t4f   (20.02.2007 в 16:59)
 

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

   
 
 автор: t4f   (20.02.2007 в 17:32)   письмо автору
 
   для: cheops   (20.02.2007 в 17:30)
 

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

   
 
 автор: cheops   (20.02.2007 в 17:35)   письмо автору
 
   для: t4f   (20.02.2007 в 17:32)
 

Кому как...

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

   
 
 автор: t4f   (20.02.2007 в 17:38)   письмо автору
 
   для: cheops   (20.02.2007 в 17:35)
 

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

   
 
 автор: cheops   (20.02.2007 в 17:53)   письмо автору
 
   для: t4f   (20.02.2007 в 17:38)
 

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

   
 
 автор: t4f   (20.02.2007 в 18:05)   письмо автору
 
   для: cheops   (20.02.2007 в 17:53)
 

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

   
 
 автор: cheops   (20.02.2007 в 19:00)   письмо автору
 
   для: t4f   (20.02.2007 в 18:05)
 

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

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

   
 
 автор: t4f   (20.02.2007 в 20:01)   письмо автору
 
   для: cheops   (20.02.2007 в 19:00)
 

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

   
 
 автор: cheops   (20.02.2007 в 20:19)   письмо автору
 
   для: t4f   (20.02.2007 в 20:01)
 

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

   
 
 автор: t4f   (21.02.2007 в 10:16)   письмо автору
 
   для: cheops   (20.02.2007 в 20:19)
 

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

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

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

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

   
 
 автор: tAleks   (26.02.2007 в 16:38)   письмо автору
 
   для: cheops   (20.02.2007 в 20:19)
 

А что такое FrameWork?

   
 
 автор: cheops   (27.02.2007 в 00:51)   письмо автору
 
   для: tAleks   (26.02.2007 в 16:38)
 

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

   
 
 автор: t4f   (27.02.2007 в 09:54)   письмо автору
 
   для: cheops   (27.02.2007 в 00:51)
 

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

   
 
 автор: t4f   (20.02.2007 в 17:04)   письмо автору
 
   для: cheops   (20.02.2007 в 12:57)
 

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

   
 
 автор: cheops   (20.02.2007 в 17:32)   письмо автору
 
   для: t4f   (20.02.2007 в 17:04)
 

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

   
 
 автор: Sl   (20.02.2007 в 13:31)   письмо автору
 
   для: Sl   (20.02.2007 в 08:02)
 

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

   
Rambler's Top100
вверх

Rambler's Top100 Яндекс.Метрика Яндекс цитирования