LINUX.ORG.RU
ФорумTalks

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

 


3

2

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

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

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

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

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

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

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

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

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

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

Ответ на: комментарий от fpastush

я имел ввиду про отображение объекта будь-то на экран,в pdf

И я про это.

Операции obj.draw() делегируются некоторому абстрактому классу device, указатель на который установлен в зависимости от контекста. При чем тут паттерн «бридж», я не поняла.

Djanik
()

Чего сразу gui, а как с rest api удобно работать? Таскать токены за собой или плодить коннекты, рано или поздно уперевшись в лимит? Чушь, в общем.

pekmop1024 ★★★★★
()

Демократия — отвратительная форма правления, но ничего лучшего человечество пока не придумало. Уинстон Черчилль (с)

https://habr.com/ru/post/451982/

Какой-то шизик, сначала рассказывает про ООП - зло, затем «у меня будет некий объект, например DataStore».

хочу создать новую статью, ещё короче но с конкретными примерами

Ты такой же шизик?

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

да, по факту мы говорим об одном и том же, только Мост более развернутый. Например, по левую сторону моста у нас в базовом классе документ, который в дочерних классах может быть представлен как doc, xsl, txt и т.д. По правую сторону интерфейс как раз с этим методом draw, а в реализациях спсобы: принтер, сеть, диск и т.д.

Тут нужно понимать, что паттерны gof они не про конкретику, а про абстрактную идею.

fpastush
()

ООП объект хочет быть самостоятельным, «знать» как себя отобразить

ООП - это про инкапсуляцию. Сам объект не хочет сам ничего. Как напишут, так и работает.

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

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

fpastush
()

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

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

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

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

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

kabanov
()
Ответ на: Все гораздо проще от absurdde

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

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

Другой вопрос, что не хватает реализации ООП и ЯП в частности, для небольших команд/фрилансеров.

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

Полностью соглашусь, но есть небольшое уточнение. ООП, как показывает практика, эволюционно прижился в средних и больших проектах, без него увы никак иначе проект развалится. А для программулек в 500-1000 строчек кода вполне хватит и процедурки. Даже взять те же микросервисы, на личном опыте,отдельно взятый сервис на той же гошечке пилить может и джун в процедурном стиле(эдакий unix-way), а вот чтоб потом это все эти микросервисы склеить между собой без ООП никак.

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

ну так и я о том же, а ТС явно путает теплое с мягким

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

микросервисы склеить между собой без ООП никак

Поправка: без модели акторов никак. Автор статьи об этом и говорит, если ты заметил:

I typically glue different logical components via message passing, actor-style

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

не неси бред

где я сказал слово «алкоголь»?

голова не только, чтобы в нее есть

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

Ну да, Модель акторов есть более точная реализация Объектно-ориентированного принципа Алана Кея, а вот микросервисы я бы называл реализацией паттерна Active object, который является наследником Модели Акторов

fpastush
()

Java без ООП не работает

/thread

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

Работа с объектами не означает, что код написан в парадигме ООП.

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

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

Ну да, ну да.. А процедурный код, который, например, юзает строковый объект, имеет такие же глобальные переменные и функции, которые меняют состояние в целом.

Ничего не напоминает ?

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

С алкоголем всё намного понятнее. Его вред для организма человека многократно подтверждается в статистике и разных исследованиях. Пользы никакой.

«Всё есть яд и всё есть лекарство…»

А у тебя опять мир чёрно-бел.. Жалок Скушен ты..

yyk ★★★★★
()

Шо, опять? Я разоблачения ООП регулярно читаю, кхе-кхе, каждые 10 лет.

Вообще, ООП — это методика, помогающая бороться со сложностью программного кода. Но да, из него могут делать религию. Так не делай!

Регулярно упоминаемый на ЛОРе unix way — это тоже методика. Со своими плюсами и своими ограничениями. Тем не менее, да, местные сотворили из него религию. И как только кто-то приносит удобную для пользователей программу, сделанную по шаблону «комбайн», набегают и начинают кричать «а как же юникс вей»? Мысли, применим ли юникс вей вообще в данном случае, у них не возникает. Потому, что это веруны, а не инженеры. У меня даже есть подозрение, что это ровно те самые люди, которые кричат о ненужности высшего образования. Потому, что именно высшее техническое образование даёт в первую очередь инженерную культуру. В том числе понимание, что любая методика, любая технология имеет свою область применения и свои границы.

И эти люди добились того, что от слов unix way другие начинают блевать. Хотя сам unix way в этом ну никак не виноват.

Точно так же и ООП не виновато в том, что догматики не умеют его применять.

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

P.S. Автор хабрастатьи по твоей ссылке хоть и наезжает на ООП, но по мере чтения примеров выясняется, что не нравятся ему именно плохие практики применения ООП, и даже он сам пользуется классами. Как всегда, конец немного предсказуем. :)

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

Какая разница, что там написал ТС. Когда это кого волновало.

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

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

https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition
Задачу решили? Решили. Надо для этого было использовать ООП? Нет.

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

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

«БРЫНЗОВЕЛОСТЬ НЕ ПРИБЛИЖАЕТ ПАБЛОСУРЖИК!» - гласила местная газета.

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

ООП - это раковая опухоль, которая раздувает такие проекты как Qt, Unreal Engine, Godot и многие другие до безобразный размеров

Gtk ты в этот список включаешь?

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

Да, что-то вроде static main() и своего рода еще Singletone Object. Да, его по факту визуально нет, но остается такой же единоличной точкой входа, где все и выполняется.

Пример, python. Вот где где, а там все объекты, даже то место где будет выполняться, например, функция main() с «вертикальными вызовами» других процедур-объектов, тоже(!) является объектом, инстанс класса module, точно не помню.

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

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

И это, строго говоря, ни разу не антоним ООП.

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

Вообще, ООП — это методика, помогающая бороться со сложностью программного кода.

Которая изжила себя в популярных реализациях (java) и создаёт еще больше сложности, чем забирает. Кстати, главный оплот ынтерпрайз ООПоты жабка, расписался в её несостоятельности, когда туда приделали рефлексию с аннотациями и спрингом. Теперь это не «б-жественное оопэ» мешок с костылями и грязными хаками, чтобы добавить декларативности и всё это хоть как-то работало. Иначе было сложна, да. Вот так оопэ побеждает: подпорками и плясками.

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

Ядро Линукс

В котором ООП внезапно есть. Ну я, в общем, так и думал…

hobbit ★★★★★
()
  • без ООП эти вопросы остаются открытыми
    • объекты и объектный подход
    • абстрактные методы
    • Java-интерфейсы
    • наследование, в том числе множественное
    • полиморфизм
    • инкапсуляция
    • паттерны проектирования
      • абстрактная фабрика
      • шаблонный метод
      • композитор
      • посетитель
      • декоратор
      • мост
    • и т.д. и т.п.
anonymous
()
Ответ на: комментарий от crutch_master

Да, но не стоит забывать, что все-таки сам язык Java есть обертка над JVM-байт кодом, там еще есть 100500 подобных языков для jvm, большая часть из которых делалась для упрощения жизни недопрограммистов. И что в итоге, пилят еще один jvm-язык Kotlin, который в итоге сойдется в одну точку с джавой. А вот сама jvm классически ООП-шная и достойна внимания.

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

Да, что-то вроде static main() и своего рода еще Singletone Object. Да, его по факту визуально нет, но остается такой же единоличной точкой входа, где все и выполняется.

Отчасти из-за того, что развитие ООП было связано с процедурной парадигмой.

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

По факту да и получается, что всегда было так, что нужно всему давать свое определение. И в итоге ОО принцип был всегда! только потом пришло время и нашелся человек который дал ему точное определение ну и доп. плюшки. По итогу мысль ТС-а в том, что «а давайте все выкинем» и сделаем что-то, что сам не знаю что….

fpastush
()
Ответ на: комментарий от Twissel

А ты унылый тролль со скучным вбросом… и Владимир, и

Do you really want to hurt me? Do you really want to make me cry? :`(

Владимир

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

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

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

И в такой ситуации надо всех этих людей как-то ввести в ООП. И тут проблема - если, как ты пишешь, ООП это методика, помогающая бороться со сложностью программного кода - то чтобы продемонстрировать эту методику, нужен сложный код. Сложный код осилит человека три из группы. А лабы должны сдать все. И тут начинается вот эта фигня - расчет объема ящика с использованием класса Box. Туда же прикручивается наследование, полиморфизм, а в итоге программа считает V = abc.

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

Серьезно, вот тут шутят про FizzBuzzEnterpriseEdition, а на лабах это и происходит.

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

объекты

Я тут спросил, а что такое объект, дали настолько расплывчатое определение, что можно засунуть сей вопрос куда-нибудь далеко.

наследование, в том числе множественное

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

абстрактные методы, Java-интерфейсы, полиморфизм

Вопросы типизации, а не оопэ.

инкапсуляция

И адок с воспроизведением стейта.

паттерны проектирования

Что паттерны? Зачем ты их сюда приплёл?

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

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

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

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

И в итоге ОО принцип был всегда

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

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

А вот сама jvm классически ООП-шная и достойна внимания.

Она не классически ООП-шная и вообще ооп в жабке - тот еще кусок дерьма by-design.

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

Не соглашусь, данные с функциями и их видимость это больше к модульному принципу. А я говорю про то, что ООП есть их обобщение, а не как отдельная современная ветка развития. Есть один программист-«философ», Егор Бугаенко со своим Elegant Object, вот там он хорошо эту тему раскрывает.

fpastush
()
Ответ на: комментарий от Vit

перестань уже увеличивать количество бреда в теме.

svyatozar ★ (23.07.21 02:02:15) генератор бреда

лол

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

Есть один программист-«философ», Егор Бугаенко со своим Elegant Object, вот там он хорошо эту тему раскрывает.

Ты код его видел? Ну нахер, уж лучше функцианальщики. Хотя, шо то говон, шо это.

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

Я про JVM-байткод и его вертикальную интеграцию. Это далеко не хардварный ассемблер. Посмотри и почитай его как-нить для расширения кругозора и своих знаний

fpastush
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.