так и есть


_____________
Стимулятор ~yoomoney - 41001303250491

Прикол в том, что ровно тоже самое можно сказать и в другую сторону. Многие просто переросли ООП, а многие так в нем и застряли, считая вершиной мироздания.

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

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

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

У него пока еще не потухли надежды писать чистый, прозрачный и хорошо документированный код. Он еще пока думает, что все пишут неправильный ООП-код. Ну уж а вот он то будет делать все по науке! Да здравствует ООП!

Если это получится,т я буду рад за него. Обычно этого ни у кого не получается. Так что все задекларированные преимущества ООП - чистая теория. Да и теория то так себе.

Справедливости ради нужно сказать, что и процедурный код вовсе не золотая пуля. Там тоже полно недостатков. Именно по этому я всегда агитирую за мультипарадигму.

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

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

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

какое красивое название для говнокода

_____________
Стимулятор ~yoomoney - 41001303250491

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

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

И нет ни одного ЯП, который в полной мере назвать ООП-языком. Ну может разве что Smalltalk)))
В каждом есть какие то свои отступления. Так что по сути чистого ООП не бывает, другой вопрос на сколько у программиста хватает смелости признаться себе в этом, а главное, на сколько хватает смелости использовать фишки, которые другими ортодоксами типа Valick'а упрямо называются говнокодом.

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

Или хэлперы к примеру. Почему не использовать обычные функции, не заморачиваясь с неймспейсами. Наш любимый PHP на 90% состоит из функций и ничего. )))

Я про мидлвары вообще молчу.

Или если еще глубже копнуть, модель. Да, отличная идея юзать объекты. DDD, TDD и прочая, я скоро представлю программу в рамках курса, там это все показано практически.

НО это в части модификации. К тому же доменные объекты великолепно мапятся на реляционные базы. Так почему бы не использовать в рамках CQRS в части чтения те же сервисы и ту же процедурку?

Что мешает?

Вот ООП и мешает. И сильно. Как только в рамках ООП делается попытка использовать реляционные возможности, рождаются уродливые Active Records. Потому что иначе либо возникнет опасность импеданса, либо нужно забыть про SQL-возможности. И если в части модификации это вполне терпимо и даже удобно, то в плане чтения полный капец.

Хотя давно уже есть альтернатива, DOD (Data Oriented Design), который сам по себе не является золотой пулей, но в части чтения валит ООП на обе лопатки,

Дальше поехали, один их трех знаменитых столбов (наследование) уже оказался и не столбом вовсе, и от него ООПэшники уже открещиваются, как от бесовской затеи. Ровно так же, как и полиморфизм больше не считается прерогативой ООП. Так что ему остается? Инкапсуляция? Она хороша только для опенсорса или большого интерпрайза, где работают сотни взаимозаменяемых человек, что само по себе уже нонсенс. А так это попытка защитить левый карман от того, что из него что то украдет правая рука.

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

Да, да, сейчас кто то скажет про тестирование. Но и тут не все гладко))) Ни что не стоит на месте, и тестировать сейчас можно не только код, насквозь состоящий из объектов.

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

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

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

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

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