О вреде ООП надо говорить! Это - слишком важная тема, чтобы отмалчиваться.

О вреде ООП надо говорить

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

• <картинка с Вилли Вонка>
• <картинка с котом и лампой>

Статью по ссылке я читал несколько недель назад – и было бы лучше, если бы ты сослался на первоисточник, а не перевод.

Статья верна отчасти, т. е. в ней таки есть здравое зерно, но воспринимать её при чтении надо критически, и не бросаться в крайности. Вообще всю входящую информацию надо воспринимать критически, иначе тебе насрут прямо в мозг. Начиная от утверждений, что «Бог есть», и заканчивая утверждениями, что «Бога нет». Чем старше становишься, тем яснее понимание, что истина где-то посередине.

Но если мне (пусть даже разумную) критику ООП пытаются впарить под желтушным заголовком (я бы даже озаглавил более радикально, напр., «Немедленно забудьте ООП, иначе у вас отвалится пенис») – то я немедленно прихожу к мысли, что автор мудак нечист на руку.

По теме: дядя, ты сам сколько лет в индустрии?

Ты сам-то по теме так ничего и не сказал!

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

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

Ты сам-то по теме так ничего и не сказал!

Статья верна отчасти, т. е. в ней таки есть здравое зерно, но воспринимать её при чтении надо критически, и не бросаться в крайности.

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

:this:

Не согласен. ООП - это раковая опухоль, которая раздувает такие проекты как Qt, Unreal Engine, Godot и многие другие до безобразный размеров (bloatware), с которыми мне приходилось сталкиваться. По возможности, стараюсь бежать от них как от огня.

ООП - это раковая опухоль

Вы на ЛОР прямо с кружка юных программистов?

И какую же парадигму вы хотите предложить?

Вот мне нужен контекст, где мне его хранить?

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

Уместную по месту применения.

Часто уместной является ООП, ТС против, что он предлагает взамен?

Судя по тому, что у вас дата регистрации на сайте 13.03.20, вам ещё никто не говорил что переход на личности - очень слабый аргумент…

Не пихать его чуть больше, чем часто.

А по теме есть что сказать?

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

Нет, так говорим мы, он же заявляет, что

ООП - это раковая опухоль

.

Ну если основа чего либо в виде ООП то да это накладывает следовать этому дальше, ну банально. Хз короче. Я не использую ООП подход явно. И языки где это нативочка тоже. Не потому что ААААААААААААА!!, прост не нужно мне и всё. А кому то нужно. А кто-то уточка =)

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

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

Данные, содержащиеся в IP пакете не содержат в себе документацию о протоколе TCP IP. Данные в файле .txt не содержат таблицу UTF-8. Данные в формате JSON не содержат в себе правила парсинга формата JSON.

И так далее…

Мой ответ по теме: Data Oriented Design.

“Bad programmers worry about the code. Good programmers worry about data structures and their relationships.”

― Linus Torvalds

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

Я так и не понял чем ООП плохо.

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

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

Ожидаешь ответа от ТСа который просто набросил?

Data Oriented Design

Не парадигма.

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

ТС бомбит вероятно от того что ООП пихают часто от и до везде и вся. Особенно в языках где оно заявлено так сказать своей реализацией, тот же С++ например, где новички расчёт фибоначчи начинают писать с описания класса =)

До сих пор на форумах сообщения типа, вот я создал класс, тебе нужно создать класс вообще без конкретики и прочего чисто вода =) А далее по тексту философия кто кого родитель, кто кого наследует, что скрывать что показывать, короче тупо банальное ниочём. Вместо продумывания алгоритма решения задачи и описания его кодом, часто занимаются дрочевом размышлений как это всё красиво оформить, а уже по тоооом как собственно чего то считать/решать/обрабатывать. Попутно вспомнят десяток паттернов проектирования и кучу терминов.

Вот когда такой ужос происходит становится грустно конечно. Но такое не везде и всегда, эт я так, вероятно от этого всего у ТС и бомбит.

Gui без ООП? X-Window, HTML+CSS+Javascript, Dear ImGui…

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

Даже в Xaw есть ооп, html+css+js остаётся гипертекстом с перделками в виде нечитаемого говнолапшекода.

Ядро Линукс - достаточно для тебя большой прокет?

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

Я с вами согласен.

ТС бомбит вероятно от того что ООП пихают часто от и до везде и вся. Особенно в языках где оно заявлено так сказать своей реализацией, тот же С++ например, где новички расчёт фибоначчи начинают писать с описания класса =)

Да, это губительно. Особенно для С++, где есть возможность писать в процедурном стиле.

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

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

из крайности в крайность мечется

не без этого

либо понять что мир не черно-белый

Это с возрастом придет, как мудрость. Правда иногда возраст приходит один, да...

Достаточно старый и консервативный, чтобы его не учитывать.

Я вам ещё могу подкинуть: бэкенд вконтакта долгое время был в процедурном стиле, где-то до 18 года. И это было не из-за недостатков ООП.

Это с возрастом придет, как мудрость.

Эх, как же круто было в садике =) Босоного бегать по полям :D И не думать где на зубы взять мне лям тчк

Серебряной пули нет, вы это прекрасно понимаете.

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

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

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

Для него, судя по тексту, все ООП это плохо при этом он не учитывает время когда продукты сделаны, веяния моды тех лет и т.д

А в чем, собственно, противоречие? Если в 1948 году было модно ходить по улице с говном на голове — значит ли это, что все-таки нам нужно учесть веяния моды тех лет, и начать уважать носящих говно на голове людей?

Я знаю что не смогу никого переубедить. Просто потому что очень трудно доказать очевидное.

Вот есть информация и есть контекст. И всё. В этом суть. Я вовсе не считаю что способен кому-то объяснить что такое информация и уж тем более контекст.

Моя цель показать начинающим программистам, что в научной среде постоянно рождаются (и умирают) много идей, многие из которых нежизнеспособны в корне. Но в какой-то момент отдел продаж мега-корпорации решает внедрить «новую» старую мёртвую идею, раскрутить её (как ходячего мертвеца, зомби) и заставить студентов жрать это говно. «Не ешьте говно» - вот моя позиция. Кому нравится - пускай едят. Но заставлять никого не надо!

«Критикуя предлагай».

Я знаю что не смогу никого переубедить. Просто потому что очень трудно доказать очевидное

Не, погоди, вопрос был «зачем?». Зачем переубеждать собаку не лаять? Или лаять другим голосом.

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

Если вырвать из твоего повествования это одно предложение, то получится что-то вроде «моя цель — показать, что солнце постоянно восходит и заходит, а порой на небе тучи». Да, это так, и не поспоришь ведь.

Но в какой-то момент отдел продаж мега-корпорации решает внедрить «новую» старую мёртвую идею, раскрутить её (как ходячего мертвеца, зомби) и заставить студентов жрать это говно

Уже лучше. А теперь ты можешь сделать еще один шаг и задаться вопросом: а зачем отделу продаж (продаж ли?) мегакорпорации этим заниматься? Ты, как мой батя: «цель жизни политиков — сделать нам на зло, чтобы нам хуже жить было».

«Не ешьте говно» - вот моя позиция

Не ешь. Для этого тебе нужно написать статью на хабре?

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

Суслика видишь? А он есть.

В любом программировании идёт работа с объектами.

Что тут можно предложить? Не используй ООП. Не верь в то что объект знает как себя отобразить. Не используй объекты - они плохо сериализуются. Объекты очень неэффективно хранятся в памяти.

Если тебе нужно применить физику к объектам, и тебе нужны их координаты, габариты, скорость, угол и скорость вращения, и масса - при итерации тебе придётся пропускать все остальные, не относящиеся к физике свойства объекта: имя, описание, текстура, меш и всё что не относится к физике. Как ни крути, а железо читает информацию блоками, кэширует её и лишние поля объекта проходя через различные шины данных создают заторы. Это же очевидные вещи. Я просто не понимаю, что тут предлагать? Не хранить данные в объектах! Отдельно меши, отдельно текстуры, отдельно физику, отдельно тексты и инвентарь. Это давно уже реализовано в OpenGL и в Vulkan. Надо только следовать примеру и применять уже существующие модели.

Не используй ООП.

А что использовать?

Не верь в то что объект знает как себя отобразить.

Функции отрисовки отменяются? Что предлагаете взамен? Километровые switch case?

а железо читает информацию блоками, кэширует её и лишние поля объекта проходя через различные шины данных создают заторы.

Откуда у вас взялись «лишние» поля объекта? Компоненты объекта логически связаны, и, скорее всего, будут использоваться вместе. SoA может давать как прирост производительности, так и снижение.