ООП - Оборачиваем Ошибки Полиэтиленом

[rigidus]

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

Читать дальше

Comments

[kkirsanov]

--Обычно сравнивнение идет с процедурным программированием.

Поправка, - "процедурное программирование" это синоним "императивного". Сравнивать ООП с ним по меньшей мере странно.

[rigidus]

Согласен, но "они делают это"

[darika_d_va]

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

[rigidus]

Я думаю лучше раскрыть поподробнее про "не вижу смысла"

[darika_d_va]

Есть случаи, когда ООП если и не необходимо, то по крайней мере уместно. А, например, громоздить объекты в сравнительно небольшом модуле для Asterisk на PHP, не вижу смысла. Я достаточно раскрыла тему?

[rigidus]

Хрен знает, я вообще не в курсе, что такое "громоздить объекты в сравнительно небольшом модуле для Asterisk на PHP"

И конечно мне интересны примеры где ООП уместно. Тут выше сказал про GUI - ну я и не спорю. А еще?

[cgvictor]

Налицо непонимание задач.
Скажи мне, Михаил, что самое дорогое (не сердцу, а $$$) в жизненном цикле продукта на рынке?

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

"Диаграмма классов на стене" решение не идеальное, но без нее в проекте через год (два, пять) начинает твориться полный бардак - проверено миллионами мух. Поэтому да, полиэтилен или что там еще, но: это дешево, это скейлится, и это работает.

Бизнес платит и заказывает музыку, втч. невзирая на курс "компиляторы".

[rigidus]

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

[cgvictor]

>> выбросить, весь цикл и начать заново

Мыслишь не теми категориями. Самое дорогое - профейлить соответствие продукта нуждам рынка, потому что тогда у бизнеса тупо нет продукта. И просраны не деньги разработки, а value всей бизнес-задачи. Стоимость переписывания здесь исчезающе мала. А продукт в большинстве случаев не развивается и не успевает за рынком (из практики) именно тогда, когда является черным ящиком на уйпойми каких технологиях.

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

И будет прав, нахуя ему эта рулетка?

Рынок выбрал ООП - дешево и с гарантиями. Качество (довольно, впрочем, абстрактное) никому там нахрен не интересно. А вот supportability - очень даже.

++ свежая дописка про UML вообще не из этой оперы.

[rigidus]

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

Я то тут про архитектуру. И UML - это как раз тот костыль, без которого в ООП никак, по изложенным в посте причинам. Так что дописка - просто пример развития идеи о некотором мета-уровне из которого растет код

[gineer]

\\О том что вместо - несколько позже, ок?

Уже случилось это позже? Или еще ждать. :)

[rigidus]

Еще ждать :) Я пока не готов разразиться циклом постов о написании и отладке DSL

[binf]

Доброго времени суток. Я здесь впервые, но, поскольку тема для меня животрепещущая, позволю себе высказаться.

В процесе перехода на гибридные ЯП (с С# на F#, а с Java на соответственно Scala), я тоже пришёл к выводу, что, как правило, любой ОО-код можно успешно ресоурсить на функциональный, используя замыкания, размеченные объединения и технику сопоставления с образцом. При этом читаемость кода всегда улучшается. Тут единственная проблема видится мне в привычке программистов думать в терминах ложных представлений об ООП, навязанных C++ и Java в первую очередь.

Объектно-ориентированное программирование объединяет данные вместе с кодом, который их обрабатывает и это продается как преимущество.Нет. Цимес ООП в динамическом (мульти)полиморфизме, а не в статическом связыании (структурировании) кода и данных. Последнее выдаётся как премущество Java и С++ ("паблик статик файнл Борщ Борщ борщ нью Борщ", ага ), хотя изначально в Simula и Smalltalk заложена принципиально иная парадигма. Которая, как известно, успешно реализована в CLOS.

[rigidus]

Я бы сказал, что в ООП сложно выделить один "цимес", т.к. всегда проще продать пакет преимуществ под одним лейблом, чем одно конретное преимущество. Динамический мультиполиморфизм по сравнению с мультиметодами и обобщенными функциями CLOS выглядит как наколеночное решение. Что же касается прототипного ООП в javascript - я не могу сказать по его поводу что-то определенное, поскольку знаком с ним лишь теоретически.

[binf]

Хм, а я, напротив, с CL лишь теоретически, но о преимущества мультиметодов представляю, поскольку имел пичальный опыт "применения шаблона visitor".

Прототипное ООП лучше даже одним лишь отсутствием классов, плюс возможность динамической структуризации. javascript, видимо, не самый удачный пример такого ЯП ввиду наличия множества граблей. Но он всё же достаточно удобен, поскольку граблей таки меньше, чем к примеру в С++, их можно обойти малой кровью. Автор формата json назвал его "Lisp в шкуре C"

[rigidus]

>> с CL лишь теоретически
Есть отличный краткий курс (просмотреть и даже попробовать можно за день, а то и меньше)

https://github.com/filonenko-mikhail/ub-lisp

После него можно сразу легко и свободно рассуждать об устрицах :)