[Nielson]

Что в них более удобное, чем в функциях и произвольных конструкциях? Зачем городить свалку говна, что бы сделать выборку одного поля и вернуть его? Когда можно прописать один запрос и while-ом получить.

[Scroll]

Опять же, приведу пример на играх (просто в играх объекты более наглядны, т.к. визуальны). В игре у нас есть: мир, зона, монстры, главный герой. Монстры бывают еще и разные. У монстров и главного героя есть какие-то характеристики и умения. Получается такая цепочка: существо->ГГ, существо->монстр, морстр->вид1, монстр->вид2. Теперь предположим, что у существа есть характеристики сила и здоровье. У ГГ и разных видов монстров эти характеристики отличаются.

Проблема заключается в том, что у нас получается очень много РАЗНЫХ сущностей, обладающих РАЗНЫМИ свойствами. Из-за этого структурный код очень сильно раздувается, и, в конце концов, стоновится неудобоваримым. ООП код, наоборот, позволяет в достаточной мере сократить код, задать ему строгую логичную структуру.

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

Попытался объяснить как мог -_-

[Nielson]

Ну это естественная модель данных. И применима к логике в том числе - у любой позиции каталога, например, может быть несколько атрибутов, и все они будут разные. Но позиции - суть одно и тоже, только с разными картинками и названием.
Вообщем, тут ясно ) Просто я не пойму — чем на практике в вебе это выгоднее? У тебя нет конкретного примера в запасниках? С удовольствием бы посмотрел ))

[Scroll]

Ну, совсем конкретных примеров нет.
Представь, что ты пишешь интернет-магазин:
Какие тут могут быть классы? Первое, что приходит на ум - это user и article.

Юзера можно добавлять, удалять, редактировать, авторизовать, активировать, добавить в карзину, удалить из корзины. У него могут быть свойства: ФИО, баланс, почта, корзина.

Товар так же можно добавлять, удалять, выставлять, редактировать, вычислять рейтинг, выводить в браузер. Его свойства: изображение, цена, характеристики, рейтинг, описание, HTML-код.

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

[deMone]

Если брать в качестве примера MVC, то каждый контроллер и модель представляют собой отдельные классы. Просто потому что в разных контроллерах и моделях разные методы.

Если бы был просто набор функций, связать все функции, касающиеся работы с пользователями сложнее, чем когда у тебя есть один класс, в котором есть всё, для работы с пользователями.

[Nielson]

Ну да, верно. И в структуру базы закладывается так же объектная модель. А потом просто это описывается процедурными методами.

Я просто не могу уловить сути. У меня есть очень сильное ощущение, что программисты используют ООП ради ООП. Это как креатив ради креатива. Типа — я охуени! Я юзаю ООП! Прибавку к зарплате мне в 30К, будьте добры!

Задача в виде облегчения восприятия программы, легкой донастройки и т.д. - на малых проектах ее можно не учитывать в принципе. Тем более, что дописать какой-то процедурный обработчик и вставить в нужное место — проблем не составляет.

[Scroll]

У меня иногда тоже такое впечатление создается) Но раз продвинутые программисты говорят, что ООП - это круто, значит надо учить ООП)
А для маленьких проектов да, иногда ООП может быть даже вреден.

[Nielson]

deMone, что мне мешает создать «виртуальный класс» функций, которые будут храниться каждый отдельно для удобства работы с ними? И эти функции, объединенные моим сознанием (то бишь у меня в голове) будут, по-сути, выполнять ту же роль, что и класс в ООП, только всё значительно проще.

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

Это как копать бульдозером маленькую канавку. Заебешься в срань. Но ведь лопатой не престижно — платят меньше!

Добавлено через 1 минуту

Scroll, для меня «гуру» давно закончились, когда я понял — КАК работают люди.

[deMone]

Nielson, ничего не мешает. Только если твой проект возьмётся дорабатывать другой программист — нихуя он не увидит твоего виртуального класса. И будет трахаться с твоим кодом дольше, чем нужно.

А как ты их увидишь, если ты не пробуешь? Попробуй что-нибудь сделать в том же CakePHP.

И никакого престижа тут нет — это реально удобно.

[Nielson]

Попробую обязательно )) Сейчас и правда говорю несколько необоснованно