благодарю
| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > PHP: Общие вопросы > ООП и php - практическая необходимость |
| Автор: realPROme 21.12.2008, 20:29 |
| народ, прогаю лет около 10, начинал с бэйсков и паскалей... в общем, я очень консервативен и до сих пор принимаю только структурное программирование, хоть потихоньку начинаю применять и классы... собственно, как-то слепо... мне не совсем понятен их смысл... просьба привести конкретные примеры ситуаций, когда ООП имеет явные преимущества перед структурным программированием благодарю |
| Автор: skyboy 21.12.2008, 20:59 |
| навряд ли такое возможно. в смысле - примеры привести. по скорости разработки ООП вполе может превзойти процедурное, но только если: - все участники процесса не понаслышке знакомы с ООП: если ты только вчера использовал функции и переменные переменных типов, то у других будут проблемы с твоим кодом(не соответствует идеологии: не переносимый и расширяемый), а у тебя - с пониманием чужого кода; - задача действительно оправдывает применение ООП: к примеру, программы для контроллеров можно и на С++ писать, но если контроллер работает только с машинными кодами(пока что контроллеры, принимающие python-код редкость), то такой подход себя н оправдает. по скорости работы и занимаемой памяти машинный код, полученный компиляцией ООП вполне может проиграть коду, полученному из процедурно-стилевого кода(таблицы виртуальных функций и т.п.), но несильно. так что не совсем понятно, какого рода "преимущества" ожидаются. да, если все участники знакомы с ООП, то преимущества вполне могут быть в: а) скорости разработки б) простоте отладки(пр правильном подходе имеем слабую межмодульную взаимосвязь и сильную внутримодульную - компоненты можно отлживать независимо) в) простоте поддержки(модификация и коррекция) г) расширяемость д) повышенная повторная применимость |
| Автор: NLspieler 21.12.2008, 21:25 |
Почти все (а может даже и все) эти преимущества можно получить, используя пользовательские функции. А тем более, если быстродействие при этом повышенное. Или в чем я не прав? Пытаясь читать про ООП, ничего не понимаю,  может быть кто-либо из форумчан сможет лучше объяснить на примитивных примерах?  |
| Автор: igm 21.12.2008, 21:34 |
| а Вы попробуйте поработать с классами, это как пересесть на Мерседес с Жигулей, трудно потом отказаться. |
| Автор: source777 21.12.2008, 21:55 | ||||
А когда встретишься с проектами, в которых и 10 kLOC не предел, тут уж и всю мощь АОП осознаешь... |
| Автор: realPROme 22.12.2008, 00:00 | ||||||
да я вот пробую... загвоздка в том, что разницы не чувствую... а все вокруг за ООП только и говорят... вот и непонятно мне
дайте не примитивный пример
ну скажем так, самый крупный мой php-проект весит более 3мб в исходниках, и я в нем вполне легко ориентируюсь, сколько там строк не знаю, т.к. более 600 файлов, не считал просто ООП в основном вижу в коде от сторонних разработчиков, и везде, где только я его видел, смысл именно ООП мне не был ясен, т.к. все то точно с таким же успехом реализуется структурным программированием, смысл я видел разве что в том, что программисту ООП-подход просто привычней и все, не более того skyboy, очень благодарен за Ваш пост, чувствуется, что писали по опыту, я в команде не работал и работать не собираюсь, это не по мне, привык все сам, так что данный пункт соответственно и упустил... |
| Автор: bars80080 22.12.2008, 00:09 | ||||
впрочем, до 1000 строк на модуль не добирался
воооот, такая же фигня. впрочем, слышал я такую весчь, что это своего рода склад мышления. т.е. есть люди которым ООП бесмысленен, а есть которым он незаменим. и перестроится с одного на другое можно только с сильным перестроением хода мыслей в голове |
| Автор: skyboy 22.12.2008, 01:16 | ||||||||||
возможно, речь об ОО-проектировании, а не программировании. потому как мне сложно представить, чтоб человек "с процедурным складом мышления", прочитав докментацию, не смог написать нечто вроде
тут не обязательно дело в объеме кода. представим, что надо отрисовать на экране средставми openGL прямоугольник. стадия 1. создаем функцию. в неё пихаем 20 параметров: параметры отрисовыаемого прямоугольника(цвет, толщина линий, размеры), парамерты отрисовки(расположение прямоугольника на отрисовываемом пространства), параметры "полотна"(например, идентификатор окна в windows) и параметры инициализации openGL(около десятка). Вся работа - внутри единственной функции. Естетвенно, работать сложно. Изменять код - ещё сложнее. итак, стадия 2. инициализацию openGL, подготовку контекста отрисовки и саму отрисовку выносим в разные фунцкии. в нашу "первоначальную функцию" все ещё передаются двадцать параметров, но внутри - только вызов трех других функций с передачей им соответствующих данных. стадия 3. отделяем параметры друг от друга: группируем парамерты по смыслу, выделяя однотипные параметры(параметры иницциалзации openGL, параметры отрисовки, параметры отрисовываемого) в отдельные записи(в PHP для этой цели использовались бы ассоциативные массивы). теперь вместо кучи параметров в фунцкию передаются всего три. пусть, сложных, но управляться с ними будет проще. стадия 4. надо передать в функцию какую-то функцию. к примеру, чтоб при отрисовке каждой новой стороны использовать не один и тот же статически заданный цвет, а взывать определенную функцию, чтоб она уже генерировала цвет очередной стороны. и - стоп! у нас же ожидается в параметрах функции именно цвет, а не имя другой функции! Как же делать? Писать ещё одну функцию, которая ожидает в качестве параметра "цвет обводки" имя фунцкии, а не число? Или расширять имеющуюся функцию при помощи if'ов, чтоб шла проверка: если существует функция с таким именем, то вызывать фунцкию, нет - пытаться использовать как строку с заданием цвета? А если кадый параметр может стать динамически генерируемым? тогда как - писать под все возможные комбинации статически заданных и динамически генерируемых данных разные функции? или наплодить дерево if'ов, а затем повеситься с горя? итак, ООП:
естественно, может показаться, что всего-то надо было изначально договориться, что в фунцкию в любом случае будут уходить не значения, а имена фунцкий-оберток, которые в случае фиксированных значений выглядели бы просто вот так:
но это ж сколько функций надо было бы создать! |
| Автор: gibbzy 22.12.2008, 05:44 |
| Плюс ко всему многие фреймворки используют ООП например Zend Framework. И достаточно удобно структурировать код и разделять логики модель - вид - контроллер. А просто так этому не научишься. Мне понадобилось полтора года чтобы понять что к чему и то сейчас я допускаю ошибки в проектировке проектка. Для страждущих к знаниям советую читать Гради Буча обьектно ориентированный анализ и проектирование потихоньку и помаленьку за 2 дня этому не научишься, а так же применительно к пхп есть книги PHP для профессионалов и ещё нашол такую книгу http://www.softtime.ru/php5/?id_article=112 ничего сказать не могу потому что заказал ещё не пришла и такая http://www.ozon.ru/context/detail/id/3452954/ книга тоже есть . http://taop.rpod.ru/rss.xml вот ещё подкасты есть. |
| Автор: solenko 22.12.2008, 07:23 | ||
skyboy, вы наговорили кучу страшного и в итоге привели код, котрый и десятой части это всего не делает. В итоге вывод -- ООП позволяет делать меньше! Передергиваете, однако.
|
