Почему боятся ООП?

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

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

Ну, тебе не нужны, а другим может быть нужны. Будешь икать потом.

И вообще откуда взялась идея шарить синглтоны между процессами

Не между процессами, а в одном процессе может быть несколько обособленных рантаймов. Банальный пример это веб-сервер с несколькими сервисами и/или сайтами. Или при использовании IoC движка может потребоваться запустить в одном процессе несколько отдельных подприложений с разной конфигурацией, которые могут использовать одни и те же синглтоны.

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

В голову приходит положительный пример, в приложении может быть общий глобальный инстанс клиента скажем HTTP сервиса или БД, который используется разными рантаймами в одном процессе.

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

То есть пулл коннектов должен шариться на все приложение и это ок.

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

Допустим, у тебя есть класс для записи в файл, (OutputFile) который пользователь может использовать в своей программе. Тебе нужно прозрачно для пользователя сидеть внутри этого класса и отправлять записываемую инфу по интернету на определённый сервис (класс DataSender). Ты будешь на каждый объект OutputFile создавать свой объект DataSender и открывать 100500 коннектов к сервису?

Я ничего не понял, но могу тебе сказать, что я не буду открывать 100500 коннектов к сервису. Я создам столько объектов сколько нужно или буду их переиспользовать через object pool.

Clojure - это деградация по сравнению с Common Lisp

Worse is better во все поля.

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

не прибивая при этом гвоздями создание других инстансов этого же класса при необходимости для других рантаймов в этом же процессе.

а зачем мне другие инстансы в том же процессе?

а в одном процессе может быть несколько обособленных рантаймов. Банальный пример это веб-сервер с несколькими сервисами и/или сайтами.

Хоть с миллионом сайтов, есть глобальный конфиг веб-сервера, есть пулл воркеров, есть балансировщик нагрузки, есть кеш и еще миллион штук, которые веб-сервер должен инстанциировать единожды и шарить между «рантаймами»

Если честно, то классическое MVC я никогда не мог понять.

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

В моей системе класс UI не занимается вычислением или обменом данными. Только интерфейсом пользователя. Всё остальное делегируется другим классам. Соответственно, каждый класс занимается своей узкой задачей. Если это противоречит классическому MVC, то не значит, что моя система хуже.

С чего бы ему противоречить? Ваш класс UI это V в CMV. C-controller роутит запрос, подготавливает данные, дергает M-models которые обрабатывают эти данные (запросы к БД здесь же) и выдает результат во V-view, который выводит результат. CMV.

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

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

99% веб фреймворков смотрят на вас с осуждением. Когда ж вы (все) научитесь при общении указывать обсуждаемую область? У одного пена горлом идет от синглтонов в С++, второй без них в вебе жить не может и тд.

рряя иммутабельность не нужна жаба тормозит

И тебя вылечат. Точнее, попишешь многопоток с ручными блокировками — сам вылечишься %)

Clojure - это деградация

Млекопитающие, может, тоже кажутся кому-то деградацией по сравнению с динозаврами. Где эти жалкие мыши, а где величественные бестии. А поди ж ты, как всё повернулось-то %)

Мир не стоит на месте.

CL вообще гибкий и разносторонний

Но единственное, на что он эту гибкость на практике применяет — это аутофелляция.

У Clojure, кстати, стандарта вообще нет

Clojure — это основа будущего нового стандарта лиспа, нравится тебе это или нет %) Кложаподобных недоязычков уже мульон наклепали, на куче платформ — от гошечки до петона и жопаскрипта, народу нравится. Вероятно, в какой-то момент это породит запрос на стандартизацию, будем посмотреть.

Когда ж вы (все) научитесь при общении указывать обсуждаемую область?

Вот и я про твоё бревно в глазу:

99% веб фреймворков

Каких ещё веб-фреймворков? Фронт или бэк? В первом нахрена синглтоны? Во втором только дегенерат будет использовать синглтоны. Впрочем я не удивлюсь.

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

У синглтона всего две особенности которые могут привести к проблемам у неумелого программиста:

1. Глобальное состояние, суть синглтона в том что это единая глобальная точка доступа.

2. Потокобезопасность. По-умолчанию синглтон не потокобезопасен, паттерн просто ничего не знает о потоках и программист должен сам предусмотреть механизм синхронизации чтобы не наплодить синглтонов.

Ещё один путает тёплое с мягким…

Впрочем, тут не стоит переживать. Я сам начал понимать разницу только при разработке своего IoC движка. И то, не сразу это вдуплил, только с версии 2.0

Апелляция к авторитету, причем к своему. Отклонено. Жалкое зрелище.

Не понимать область применения синглтона и безапелляционно заявлять что «синглтоны это дегенератсво» это клиника.

Вопрос прежний, почему по-вашему вариант 2 это плохо?

Я не считаю синглтон антипатерном. Просто область применения у него определённая. Если мы используем его для ведения логов, например, то это нормально. Если какой-то объект общается только с двумя-тремя другими объектами, то лучше его не делать синглтоном.

Имхо, синглтон это антипаттерн конкретно в Джаве

Предполагаю, что дело не в языке. У меня сложилось впечатление, что синглтон стали называть антипатерном после моды на юнит-тестирование, где нам нужны одинаковые стартовые условия для каждого теста. Для обычных объектов нам достаточно вызвать конструктор. А синглтон или не проверять или делать ему метод сброса состояния. Для классов, которые используют синглоны надо вызывать не только конструктор, но и сбросы всех используемых синглтонов. Можно запутаться и что-то упустить.

И тебя вылечат. Точнее, попишешь многопоток с ручными блокировками — сам вылечишься %)

Это гораздо проще отлаживать чем ссанину с STM, где непонятно что и непонятно когда высралось жабовский стектрейс, по которому нихера не понятно. Более всратая отладка только в хаскеле.

Млекопитающие, может, тоже кажутся кому-то деградацией по сравнению с динозаврами.

Млекопитающие это развитие. Но если хочешь такую аналогию - то если CL это велоцираптор, то Clojure это курица(или даже скорее птица Додо).

Мир не стоит на месте.

Деградирует стремительно.

Но единственное, на что он эту гибкость на практике применяет — это аутофелляция.

Самоотсосом и дрочкой на ФП и прочее занимаются как раз только поклонники Clojure. CL сделан не чтобы дрочить, а чтобы делать продукты.

Clojure — это основа будущего нового стандарта лиспа, нравится тебе это или нет

Clojure это вообще не лисп. Это лиспо-подобный язык. Он не продолжает основную линейку лиспа(LISP 1.5 -> … -> MacLisp -> … -> ZetaLisp/LML -> CL), и он не использует даже такие базовые концепции лиспа как cons-ячейки и соответствующие операции над ними. Это такой же побочный продукт, как Dylan (и Dylan то был куда более лиспом), и так же скоро будет забыт. Уже забывается, как хайп проходит.

А синглтон или не проверять или делать ему метод сброса состояния

Вообще проблема тестирования синглотонов, это не проблема юнит тестов, потому что в атомарный юнит мы всё равно будем передавать объект синглтона руководствуясь Д в СОЛИД. Но если все-таки очень хочется, ну навесьте на него аспект.

Ну, здрасьте-приехали. Нам рассказывали, что всё круто будет, ООП упрощает программирование, просто наследуем собачку от животного и кошечку от животного и собачка.Голос() печатает Гав!, а кошечка.Голос(), соответственно, Мяу!. А тут выясняется, что ходишь как по минному полю и нужно двадцать лет учить: где тут грабли запрятаны и хитрые приёмчики, как от них уворачиваться, если уж наступил. Не в этом ли заключается ответ на изначальный вопрос автора: „Почему боятся ООП“?

А тут выясняется

В каком конкретно месте выясняется то? Как вы смогли соединить вместе проектирование дерева наследования, полиморфизм и глобальное состояние и назвать это одной большой проблемой ООП? Вы точно понимаете о чем идет речь?

Как вы смогли соединить вместе …

Достигается опытом. Опят же, давно тут сижу, помню ООП продавали как «весь мир состоит из объектов с состоянием, например у вас есть банковский счёт с состоянием «количество денег» и операциями «снять» и «положить» и, смотрите, в нашем ООП вы можете просто создать объект «account» с переменной «amount» и методами «put(money)» и «get(money)». Просто опишите объекты реального мира на нашем ООП языке и всё чудесно заработает. Звучало довольно убедительно. Многие до сих пор верят.

А потом те же самые люди, тем же самым языком произносят галиматью вида «проблема тестирования синглотонов, это не проблема юнит тестов, потому что в атомарный юнит мы всё равно будем передавать объект синглтона руководствуясь Д в СОЛИД» и ничего из этого не соотвествует сущностям реального мира. Некоторых это отрезвляет.

ничего из этого не соотвествует сущностям реального мира

Это у вас голова не соответсвует реальному миру. Вы еще в школьной программе найдите несоответсвия и начните возмущатся. Ай-ай, как же так, мне в школе объясняли, все так красиво было, вот тут ДНК а вот тут РНК. А пошел в институт и ОКАЗАЛОСЬ!!! что этих РНК как говна за баней, зачем меня обманывали, почему так сложно! Вы дурачок местный что ли? Да, представьте себе, есть задача проектирования, есть объекты домена, а есть объекты-модели, а есть объекты слоя передачи данных, а есть сервисы, а есть слой представления, и так далее. А вы как хотели? Это только у лисперов все просто, а в реальном мире инженерные задачи имеют несколько уровней сложности, и как-то надо этой сложностью управлять. И человечество пока не придумало ничего лучше, чем скрывать детали реализации за абстракциями. Этим ООП и занимается, а не тем что вы себе нафантазировали прочитав приключения профессора Фортрана.

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

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

Никуда оно не выходит. ООП эволюционирует вслед за всей индустрией. Есть дебилы застрявшие в 60-х, но таких к счастью не много. Люди в основном понимают, что одни идеи закрепляются, как успешные, другие отмирают, как менее успешные. Железо диктует свои требования, бизнес диктует другие. Люди накапливают опыт, у языков изменяется область применения, появляются средства автоматизации - все меняется вокруг. И то, как видели ООП в 80х, и как его видят сейчас - отличается. Это удивительно для вас?

Мне нравится ваш оптимизм и позитивный настрой.

Откуда 5 звезд у этого дебила?

Удалите дауна с платформы

Иди лучше уроки сделай, а то опять двойку поставят, мамкин ты наш «удаляльщик с платформы»

человечество пока не придумало ничего лучше, чем скрывать детали реализации за абстракциями

От некоторого говна лучше по возможности избавиться насовсем (я смотрю на тебя, mutable state), чем прятать его за баней абстракциями. Иначе в конце концов или говно прорвёт барьеры, или непрерывно растущая куча абстракций превратится в кучу говна. А исход один — ты утонешь.

Это такой способ сказать что он дурачок?

Современное мейнстримное ООП это то же самое ООП, что было в Simula-67, в 60х. До 80х еще не добрались. Еще долго до них.

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

поцелуйтесь, мальчишки

в чём отличие промеж хайпа ооп и хайпа структурное_программирования?

s/эволюционировал/деградировал/

Так это ж одно и то же, чисто от точки зрения зависит. Глисты (я не сравниваю дваваскрипт с глистами!) с одной стороны деградировали, от развитого организма осталась одна кишка с зубами и система размножения, а с другой — эволюционировали в новой пищевой нише и процветают.

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

дык и в ооПе тож есть полезная эвристика

хайп ужо почти схлынул

осталось схлынуть отдаче(которая медленно спадает)(kickback'у) ооп и останется полезная эвристика(набор их на некотором домене(области) своей применимости)

вон оказыца многосортные алгербы это там же где сигнатуры почти категории - недавно наскочил - ща не помню дорогу - а чёт достаточно простое типо проектирование по взрослому с алгеброй и прочей базой

Структурное программирование — вещь довольно простая и польза от неё очевидно. Как до него додумались, так сразу и перешли на него и обратно не собираются.

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

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

Фу, осуждаем.

Не в этом ли заключается ответ на изначальный вопрос автора

Возможно, в этом. Но есть два практических признака пользы ООП:

1. Подавляющее большинство крупных программ используют ООП, в том числе и программы на си, типа Gimp. Слышал, что и в коде Linux оно есть.
2. ООП реже сносит крышу программистам, в отличие от ФП или тем более метапрограммирования, несмотря на все «минные поля». Возможно, я путаю причину и следствие: программу, которая пишет программу, которая пишет программу рискуют только программисты у которых уже не всё в порядке с головой.

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

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

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

ООП реже сносит крышу программистам,

Ой, вот я б не сказал, не сказал. Тем более, если человек в принципе знаете функциональщину и декларативное программирование, скорее всего он и ООП как-то знает. Не обязательно хорошо, но кругозор определённый имеет. А вот людей, которые кроме ООП ничего не знают и не хотят — пруд пруди. И объяснить им ничего нельзя, потому как лисп для них с прологом — какая-то херота беспонтовая, которой их зачем-то мучили на парах один семестр в институте.

программу, которая пишет программу, которая пишет программу

Там в большинстве случаев довольно банальный код, который просто сокращает количество писанины. Магический флёр нагнали, когда финансирование на создание ИИ выбивали. Но потом наступила AI winter и вообще с тех пор сорок лет уж минуло. Пора бы и забить.

ООП реже сносит крышу программистам, в отличие от ФП

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

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

ну тоже самое в далёком будущем и про оопее будут сказывать

в пик хайпа «всё» было структурным даже небо даже акбар

«оопие » не причина оопее следствие

когда производительность Y резко подскакивает обратная гироскопит деградацией тех кто Y оперует на общее благо

природная дисапация как она есть

всё как всегда редко когда редко

каша из топора без топора не каша ага