LINUX.ORG.RU
ФорумTalks

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

 


3

2

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

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

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

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

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

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

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

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

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

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

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

Или ромб в квадрат?

Я принцип объяснил. В данном конкретном случае проще в квадрат ввести поле «угол», а класс ромб не создавать.

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

Или наследовать и то и другое от «Геометрическая фигура»

Наследовать нужно, чтобы не пастить площадь/периметр. Вопрос что от чего. И мы еще не дошли даже до прямоугольников, я и не говорю о чём-то более сложном.

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

А в чем проблема?

Вы тут в нашем в приличном обществе спрашиваете «в чём проблема в программировании копипастой»? Серьёзно? Я не думал, что срач так быстро закончится.

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

Это повод ломать удобство использования?

Весь код имеет свойство дико расти в дозволенные стороны. Делаешь одно условие, считай, что их там n.

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

Весь код имеет свойство дико расти в дозволенные стороны. Делаешь одно условие, считай, что их там n.

Это повод заставлять всех кто работает с твоим кодом переводить руками Ромб в КвадратныйРомб и наоборот?

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

Не можем == не нужно.

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

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

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

Зачем переводить? Выдача определённого класса (при создании экземпляра объекта) должна быть основана и на угле между сторонами, если мы говорим про ромбы и квадраты.

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

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

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

Вынеси стратегию в отдельный объект.

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

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

И передать в неё весь контекст, нужный для методов, которых n. Стратегий тоже будет где-то по числу методов.

Нет, только частные случаи, которые имеет смысл шарить между разными классами.

Охрененно.

Верно

Да и потом. А как там же инкапсуляция? Мы опять положили хер на принципы ООП?

А с нею у тебя что не так?

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

Нет, только частные случаи, которые имеет смысл шарить между разными классами.

Так можешь считать, что частных случаев у тебя тоже n. Если не можешь, тебе их придумают.

А с нею у тебя что не так?

Вот пример стратегии на жабке. Как видно из кода в стратегию просто передали a и b. То есть переложили внутреннее состояние объекта. То есть положили хер на инкапсуляцию. Может быть на википедии говнокодеры и просвещённые как-то по-другому делают стратегию, я не знаю.

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

При изменении можно просто создавать объект и рисовать его.

Зато в ромб не тащатся формулы для прямоугольника.

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

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

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

При изменении можно просто создавать объект и рисовать его.

Не ты че угараешь?) На каждый тик объект создавать)

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

И вообще, я на своём жсе, в котором, как говорят, херовое ооп, делаю «стратегию», просто подкладывая функцию с this в нужный объект.

Рад за тебя.

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

Народа мало, накал угара не полный. Было бы еще человек 5, они бы тебе показали, как надо делать оопэ. Ну я сделаю тред на след. неделе. ВСЁ. Пошел я кодить.

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

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

Можно.

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

А знаете, когда это всё началось? Где-то со структурного программирования. Все эти подпрограммы и блоки раздувают код.

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

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

Это просто самый простой путь, иначе надо вставлять условные операторы.

Писать какое то говно ради того что бы избежать ифов это адекватно?)

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

А знаете, когда это всё началось? Где-то со структурного программирования. Все эти подпрограммы и блоки раздувают код.

Ничего они не раздували, по сравнению с тем, на сколько сокращали. Попробуй попиши скриптоту без подпрограмм.

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

Раздутие - это не про легче сопровождать, а как раз таки наоборот. Если бы в жаба ооп приделали какую-нибудь вменяемую декларативность вместо спринга сбоку, то можно было бы сказать, что мы там что-то сократили, победили и с этим теперь работать легче. А так - нет. ООПота в типичном жаба проекте - это сраная каша из правильных паттернов, половина из которых непонятно зачем и куча тупых ошибок, которые потом правятся годами. Это НЕ удобно сопровождать, тяжело научить кодеров понимать и пользоваться этим правильно. Просто лучше ничего не придумали и/или не пробовали.

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

Не избежать ифов, и избежать разрастания метода до 100к+ строк.

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

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

Какими например?

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

Попробуй попиши скриптоту без подпрограмм

С гоуту можно попробовать.

Раздутие - это не про легче сопровождать, а как раз таки наоборот

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

ООПота в типичном жаба проекте - это сраная каша из правильных паттернов, половина из которых непонятно зачем и куча тупых ошибок

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

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

Присущими прямоугольнику.

Квадрат ведь настолько же ромб, насколько и прямоугольник.

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

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

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

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

какой жаркий спор, мне скучно, поэтому будут пять копеек.

Как точно описать квадрат?

Как только вы ответите на этот вопрос, сразу станет понятно, что нужно для объекта квадрат (:

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

Как точно описать квадрат

Зависит от того, что вы собираетесь с ним делать.

Может хватить как скаляра одной из сторон, так и вектора.

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

МММ, мышление программиста)))) ну ладно, наброс я сделал, он походу удался (:

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

ООБД, в этом смысле, совсем не являются «произвольными», так как не вылезают за пределы графов, которые хорошо отображаются в реляционную модель.

Реквизит объекта может быть массивом или ассоциативным массивом. Или даже функцией.

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

А теперь, пожалуйста, так, чтобы компилятор смог векторизовать цикл обхода коллекции таких объектов :)

Если из объекта нужна только одна колонка, то обходить именно её. Правда что делать, если один объект в разных коллекциях…

а в С++ даже иметь для такого композитного указатели value-семантику.

Если это считать значением и складывать на стек, всё равно векторизовать не получится.

ООБД выродились в просто ORM.

наследование в ORM делается жуткими извратами.

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

Наследовать нужно, чтобы не пастить площадь/периметр. Вопрос что от чего.

Периметр вообще для всех многоугольников одинаково можно считать, с площадью сложнее. Наверное, надо объединить все фигуры, для которых площадь считается одинаково, в один тип и реализовать для каждого такого типа метод расчета площади. Наследование? Ну ты понел.

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

формула площади Гаусса

Вообще шыкарно. В итоге имеем один тип многоугольника и кучку интерфейсов для интересующих нас задач. Как тебе такое, Ил @crutch_master?

Nervous ★★★★★
()
Последнее исправление: Nervous (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.