LINUX.ORG.RU
ФорумTalks

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

 


4

2

Здравия всем!

Я редко пишу на этом форуме, никого здесь не знаю… Но всё-таки решил попробовать. Удалят - и ладно.

Хочу лишь обратиться к молодому поколению программистов: в университете вам будут впаривать ООП - не ведитесь. Я много лет жизни потерял пытаясь понять что это за зверь. Это настоящая религия. Тебя убеждают что это хорошо, а когда ты понимаешь что это плохо - тебе говорят: ну ты просто ещё не знаешь паттернов, 5 принципов дяди Боба и т.д.

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

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

информация ничего не значит без контекста.

В классическом примере ООП используется для пользовательского интерфейса. ООП объект хочет быть самостоятельным, «знать» как себя отобразить. Но это зависит от размера экрана, а если вывод в документ PDF, то предпочтительнее вектор, а не растр и так далее. Рано или поздно работа с ООП постоянно натыкается на конфликт: как передать контекст объекту.

Об этом много сказано, есть много примеров и разборов. Я уверен что студентам некогда читать длинные статьи где много буков. Они легко гуглятся и вот одна из наиболее кратких со ссылками на более подробные https://habr.com/ru/post/451982/

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

Перемещено xaizek из development

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

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

fernandos ★★★ ()
Последнее исправление: fernandos (всего исправлений: 2)
  • <картинка с Вилли Вонка>
  • <картинка с котом и лампой>
slovazap ★★★★★ ()

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

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

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

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

Bass ★★★★★ ()

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

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

LINUX-ORG-RU ★★★★ ()
Ответ на: комментарий от svyatozar

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

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

Bass ★★★★★ ()
Ответ на: комментарий от LINUX-ORG-RU

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

:this:

Bass ★★★★★ ()
Ответ на: комментарий от LINUX-ORG-RU

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

svyatozar ★★ ()
Последнее исправление: svyatozar (всего исправлений: 1)
Ответ на: комментарий от svyatozar

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

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

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

fernandos ★★★ ()

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

t184256 ★★★★★ ()
Ответ на: комментарий от fernandos

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

svyatozar ★★ ()

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

Shadow ★★★★★ ()
Последнее исправление: Shadow (всего исправлений: 1)
Ответ на: комментарий от svyatozar

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

LINUX-ORG-RU ★★★★ ()
Ответ на: комментарий от SR_team

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

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

И так далее…

svyatozar ★★ ()

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

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

bhfq ★★★★★ ()
Ответ на: комментарий от svyatozar

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

SR_team ★★★★★ ()

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

Pinkbyte ★★★★★ ()
Ответ на: комментарий от fernandos

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

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

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

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

LINUX-ORG-RU ★★★★ ()
Ответ на: комментарий от anonymous

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

Pinkbyte ★★★★★ ()
Ответ на: комментарий от svyatozar

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

Shadow ★★★★★ ()
Последнее исправление: Shadow (всего исправлений: 2)
Ответ на: комментарий от LINUX-ORG-RU

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

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

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

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

fernandos ★★★ ()
Ответ на: комментарий от Pinkbyte

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

anonymous ()
Ответ на: комментарий от svyatozar

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

Pinkbyte ★★★★★ ()
Ответ на: комментарий от anonymous

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

не без этого

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

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

Pinkbyte ★★★★★ ()
Ответ на: комментарий от svyatozar

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

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

fernandos ★★★ ()
Ответ на: комментарий от Pinkbyte

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

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

LINUX-ORG-RU ★★★★ ()

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

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

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

byko3y ★★★ ()
Последнее исправление: byko3y (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

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

byko3y ★★★ ()
Ответ на: комментарий от byko3y

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

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

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

svyatozar ★★ ()
Последнее исправление: svyatozar (всего исправлений: 1)
Ответ на: комментарий от svyatozar

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

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

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

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

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

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

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

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

byko3y ★★★ ()
Последнее исправление: byko3y (всего исправлений: 1)

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

X512 ★★★ ()
Ответ на: комментарий от X512

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

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

svyatozar ★★ ()
Ответ на: комментарий от svyatozar

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

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

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

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

X512 ★★★ ()
Ответ на: комментарий от svyatozar

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

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

Siborgium ★★★ ()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)