Лично мне нечего добавить.

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

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

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

что все? кто эти все?

_____________
Промокод предоставляет скидку на заказ домена и/или хостинга reg.ru
BFCC-3895-8804-9ED2

Чем другие порошки! Так и говорят, кстати.

Я по крайней мере не знаю более удобных инструментов чем контракты и инверсия зависимостей. Чтобы открыл некоторый файл (контракт) и сразу всё понятно что к чему.

Сначала нужно обучиться процедурке, потом понять какие в ней есть архитектурные изъяны, вернее прочувствовать их. Понимать будем позже. И только потом возможно эффективное осмысленное обучение ООП. Проходит значительное время, вот и говорят о высоком пороге вхождения. Для человека готового войти в парадигму порог не столь и велик. Но одного лишь желания, увы, не достаточно. =(

Все то, о чем написаны знаменитые на весь мир книги. Например, рефакторинг Фаулера или дизайн Эванса. Я не мастер давать настолько точные определения, если одним словом описать что я поразумеваю под ООП, наверное лучше всего подойдет - "интерфейс (контракт)".

В принципе да, если не прямо совсем всё, то подавляющее, даже сказать абсолютное большинство.

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

Армяне лучше чем грузины. Чем? Чем грузины!

На самом деле с тобой трудно не согласиться. Но с одной маленькой ремарочкой. То, что сейчас модно принято называть ООП, чаще всего трактуется как Объектно Обязательное Программирование. Однако если следовать "парадигме" буквально, на объекты нужно ориентироваться, но вовсе не обязательно ими ограничиваться. Однако почему то всё, что не представлено объектами, моментально объявляется говнокодом.

Тут злую шутку играет излишний интузиазм и недостаток квалификации наверное. Как раз то, что борцами за "чистоту рядов" ставится в вину тем, кто использует мультипарадигму.

Что касается этого:

Совершенно не соглашусь. Как раз наоборот, если начнешь с процедурки, ты погиб на долгие годы. Собственно это коснулось и касается почти всех, кто начал обучение программированию с PHP.

А если начнешь с JAVA или еще хлеще с C#, то там вообще трудно что то делать без объектов. И тут важно чтобы кто то сразу объяснил их суть. Тогда никакого порога не будет. Там просто невозможно ничего сделать, не понимая механизмов объектов и классов. А это уже основа другого порядка, с этим багажом гораздо проще разбираться с архитектурами.

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

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

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

Важно тут то, чтобы мы понимали друг друга на уровне кода. Это ответ ТС. Не нужно искать черную кошку в темной комнате, особенно если её там нет. Не нужно уповать на ООП, как на золотую пулю. Нужно просто писать красивый, всем понятный и эффективный код.




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

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

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

Почему погиб? Просто не созрел для архитектурных изысков. Опыт разработки эффективных алгоритмов пригодится так или иначе, а он не зависит ни от парадигмы ни от архитектуры. Я не верю, что можно с нуля научить сразу осознанному ООП. Как учить вождению и сразу развить способность видеть дорожную обстановку (как говорится думать за других).

Да, потому что объект главным образом это тип. Чем сильнее типизация в проекте, тем лучше. Классно, когда соответствие типов проверяется в момент компиляции, но PHP лишен такой фишки.

За все хорошее, против всего плохого? Архитектурные вопросы лежат намного выше по абстракции, чем понятный и эффективный код, кстати. Можно писать понятный и эффективный код на процедурке и не видеть чем он хуже ООП-шного.

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

Именно так.

А можно и наоборот. Писать запутанный монолитный ООП код и не видеть, что он хуже понятной и эффективной процедурки.

Ровно тоже самое я могу сказать, что переход от ООП к мультипарадигме требует осознать то, что на уровне ООП далеко не сразу очевидно.

У ООП полно недостатков, не зря существует куча сформулированных антипаттернов. А еще больше несформулированных. Перефразируя Страуструпа можно вывести немного другой силлогизм:

Но это фикция, потому что ООП не всегда == красивый код.

Вот не всегда так, хотя польза типизации очевидна. Просто иногда за нее приходится слишком дорого платить. Ровно как и другие, на первый взгляд, "преимущества" ООП зачастую слишком дорого стоят. Взять хотя бы тот же порог вхождения, хотя я в него не верю.

Так что если:
1. Код перенасыщен паттернами
2. Абстракция возведена в абсолют
3. Полиморфизм применяется всегда, надо оно или нет, с оправданием "а вдруг!"
4. Архитектура простого проекта разрабатывается по принципам астронавтики
5. И вообще, когда ООП ради ООП

Твой код - дерьмо. Хоть ООП его назови, хоть горшком без ручки.

И наоборот. Если ты пишешь модульную систему на процедурке, либо на ФП, и код:
1. Хорошо структурирован
2. Лаконичен
3. Прозрачен
4. И вообще интуитивно понятен даже новичку

Твой код хорош. Что бы не говорили про него адепты.

Так что я за хороший и красивый код, а не за религиозный фанатизм с ООП вместо иконы. Ровно как и процедурка тоже совсем не религия, а инструмент.

Все доводы про сложность расширяемости и поддерживаемости - фикция и миф. Не стану акцентироваться, лень. Одно только скажу. Мой рабочий проект на 80% написан процедурно. Я недавно (года два назад) попробовал переписать отдельные модули на ООП, и бросил нафиг. Ибо это никому не надо. Он вполне расширяем и подерживаем и так. Ни у кого из новых программистов никогда не возникало серьезных вопросов по коду. Он просто очевиден. Может там местами нарушен DRY, но зато код не связан и никакой SOLID ему не нужен.

А проект это успешно работает и развивается уже около 10 лет. А если взять вообще законченный проект, который и расширять то не нужно, то все ваши доводы "за" полностью теряют смысл. Не нужно ничего расширять, проект закончен.

А если станет нужно, значит не так уж сложно его и отрефакторить. Особенно если проект написан мультипарадигмально. Там, где действительно тонкое место, там ООП. Там где не нужна избыточность - свои инструменты.

Еще раз повторю свое твердое убеждение.

ООП полезен только тогда, когда с проектом работает очень много людей. Это либо популярный опенсорс (чаще с претензией на популярность ), либо жутко кровавый интерпрайз.

В первом случае народ норовит соответствовать, как же, люди смотрят! Кто же "купит" процедурку
Во втором оправдано, однако и мелкие компании норовят туда же. Ибо плох тот сайт, который не хочет стать Гуглом)))

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

И кол в голове: Хорошо == хорошо; ООП == хорошо. Не ООП == плохо.

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

Вот если учить наоборот, сначала объекты показать, пару архитектурных приемов, основные паттерны для затравки, а в процессе показывать нативные возможности языка, такого пафоса вряд ли увидишь. Потому что тогда анализ кода останется на месте, не забьется фанатизмом.

Код или хорош или нет. Все. Точка. Никакие другие характеристики ему вообще не нужны.

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

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

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