Допустим я создал объект (объявление) у него есть свойства (описание, цена, имя продавца, контакты).

Я не понимаю и как мне использовать этот объект? Я имею ввиду не процедурным методом.

Чтобы обращаться к каждому свойству через $this-> нужно больше кода чем процедурным методом.


В чем преимущества ООП? Напишите примеры в практике.

Сначала стоит глубоко изучить ООП, а потом задавать такие вопросы. Как минимум, если не понравится, сможешь аргументированно объяснить, почему НЕ нужно использовать этот подход.

А сейчас, судя об упоминании «нужно больше кода» — будет трудно объяснить, в чём прелести красивой ООП архитектуры, масштабируемости, понятности и стандартизированности кода. В процедурном мире это тоже возможно, но в другом виде. Просто однажды надо выбрать свой путь, но выбирать надо уже хорошо зная оба подхода к разработке.

_____________
Блог | VK | GitHub | Twitch

Сейчас опять холивар...

Спасибо конечно. Я на практике быстрее понимать начну. Чем изучать по книгам.
Я устал изменения в свой сайт (процедурно написанный)вносить, количество которых растет в геометрической прогрессии. А ООП как пишут может от этого избавить.

Напишите простой пример просто.

paul85

twin, здравствуй, мой кровный враг :)
(это так, шутка на тему ООП vs Процедурный стиль)

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

А вот в случае, когда ты работаешь в некоем проекте на >1 млн строк кода и >50000 php-файлов, который постоянно развивается, где в течение полугода может вообще поменяться стэк технологий (за исключением самого ЯП), то тут ООП сильно выручает. Например: использовал ты сервер очередей Gearman. А тут бац! — надо перейти на Rabbit MQ. Если перед этим ты сделал адекватный интерфейс для компонента очередей, то тебе надо будешь лишь реализовать специфичную прослойку для работы с новой технологией, а не перепиливать код в проекте. Полезность фабрики в данной ситуации очевидна.

Но, никто не спорит, если переусердствовать с паттернами — в итоге сам себе выстрелишь в ногу :)

_____________
Блог | VK | GitHub | Twitch

twin, а почему же тогда большинство (если не все) фреймворков на ООП? Все такие дурачки и не познали дзен? =)

alex162341

Самое веселое когда фирмочка делающая лэндинги просит php программиста со знанием ООП.
Вроде везде написано что php это не совсем ООП, или я заблуждаюсь ?

paul85
Нет, не познали. Я могу объяснить это двумя причинами. Первая банальна - это "круто". Но она не выдерживает критики.

Вторая еще банальнее. То, о чем писал AlmazDelDiablo - универсальность.

Любой фреймворк претендует на всеобъемлющие и универсальные решения тревиальных задач. Соответственно тут ООП - самый подходящий инструмент.

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

Я сомневаюсь, что сайты крутых банков или тех же больших игрушек написаны на всяких Yii.

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

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.