Отрицательные составляющие ООП, что скажете?

Автор поста имеет кучи функций виндос/линкус-совместимые (сетевые, гуишные и прочие)

Ты ещё про Донцову расскажи сколько книг из под её руки вышло. Небось на нобелевку как минимум возьмёт, но не даютс… Это я к тому, что копрокод писать легко, а вот что-то качественное можно выстрадать только через десятилетия. А можно и не выстрадать.

Отрицательные составляющие ООП

Сложно найти спеца ООП, одни копрокодеры на го и тайпскрипт. Ещё вот ржавый подтянулся.

Просто примитивный пример. Я и без ООП не должен делать на ифах.

Ты ещё про Донцову расскажи

Ну если бы я про тебя писал, может такой аргумент прошёл бы.

ООП это инкапсуляция, полиморфизм, наследование.

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

Это защита от прямого доступа к полям плюс точки валидации и только.

То что ты описал характерно только для языков без множественного наследования. А композиция по сути множественное наследование

Ну и еще например сеттеры позволяют добавлять обсерверы изменений. Например в случае с домом есть допустим дверь, не можно закрыть или открыть - по сути изменить статус флага «открыта». Это в общем канонический сеттер. А если тебе нужно получать событие открытия или закрытия двери, ты добавляешь нотификацию внутрь сеттера без изменения кода который вызывает открытие или закрытие двери.

А дверь(и) добавляешь, внезапно, композицией

Ну да, но нет. Ключевая разница в том, что родители напрмую влияют на поведение детей, а композия - просто инструмент через интерфейс. Если в случае с мультинаследованием меняется родитель, твой наследник ломается к хренам. В случае с композицией ты просто меняешь интерфейс - просто подключаешь другой модуль к своему объекту и все.

Наследование - это связь намертво еще при компиляции, а композиция строится во врем работы.

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

Ещё «абстракцию» часто добавляют.

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

Полиморфизм … не нужны.

Почему?

Я имею в виду именно в том виде, как оно сделано в обычных языках.

Полиморфизм, когда у нас есть указатель на интерфейс (абстрактный класс), который на самом деле указывает на одну из реализаций этого интерфейса, это нужно и полезно.

А когда у нас есть иерархия классов, это уже плохо.

По сути проблемы начинаются, когда мы начинаем наследовать и переопределять реализации и данные. Когда начинаются всякие вызовы super() и прочая. Вот это вот всё уже начинает быть сложно познаваемым и приносит больше вреда чем пользы.

Ты только что попутал статическую композицию с динамической.

И если ты сломал компонент композиции, то твое приложение точно так же сломается.

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

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

Это не объясняет «деградацию» языков. Например в Java нет множественного наследования классов, которое есть в C++. Например в Rust или в Go нет ООП в том же виде, в котором он есть в Java, есть лишь то, что я описываю: наследование интерфейсов. И это не потому, что им было сложно это сделать. Это потому, что ООП не просто избыточен, а вредоносно избыточен.

Не, валидация - хоть какая-то обработка данных. Я про голые геттеры/сеттеры.

Чел по полочкам разложил недостатки ООП

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

Для написания, грубо говоря, аналога iconv ООП совсем необязательно. С этим никто не спорит.

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

в зависимости что писать

Как-то так, да.

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

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

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

Всё уже давно украли до вас man c++

Какое плохое зло я тебе сделал? За что?

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

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

Другое дело, что зачастую ООП и преимуществ особых никаких не даёт. Если программа не оперирует множеством одинаковых объектов (а она могёт не оперировать, мало ли…). А вот в институте нам заливали, что ООП - это мастхэв, и за использование ООП мне за курсач сразу 5 поставили, хотя можно было и без оного обойтись.

– И давно Вас мучают эти… эротические кошмары?
– Доктор, ну почему же «мучают»?

наследование интерфейсов

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

И это не потому, что им было сложно это сделать

Именно потому что. Мозгов не хватило и сделали обрубок.

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

Простейший пример DOM - делать подобное через композицию противоестественно. Уродливый код Servo на ржавом тому пример.

Уродливость кода в твоем примере - чистая субъективщина. Ты сам пример, что сделать можно. Просто лично тебе такая реализация не нравится по тем или иным причинам.

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

субъективщина

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

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

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

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

некоторые вещи противоестественно делать через композицию

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

DOM - делать подобное через композицию противоестественно

["div", {"style": {"color": "red"}},
  ["span", "И чего же в стандартных иерархических структурах данных такого"],
  [ "b", {"className": "accented"}, "противоестественного"],
  "?"]

Как ты div, span и b в коде будешь представлять без наследования? У них как минимум у всех есть style и class аттрибуты. А ещё поведение у них общее и реакции на события. Будешь всё это через композиции что-ли городить и 100500 дублирующих обёрток на методах потом делать? Ты из какой криокамеры будешь? У нас сегодня не платят за количество строк кода.

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

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

Как ты div, span и b в коде будешь представлять без наследования?

Смари туда ⬆️

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

Есть на свете и другие хорошие вещи, кроме композиции — например, полиморфные функции.

Ты еще немного поживи и доживешь до того, что промт-операторы в принципе не поймут сути вопроса.

полиморфные функции

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

Вот я и говорю ты начинаешь городить эмуляцию наследования

Можно иметь полиморфизм без наследования. Шок, видео %)

Функции это уже не ООП

Функции — это хорошо, ООП — не очень.

Отрицательные составляющие ООП, что скажете?

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

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

А у нас корешу пришлось преподу мозг сношать на тему «что такое ООП», без шуток, она у нас его не знала.

Так проблема 1:1 как использование goto или не читаемые перл однострочники на пару страниц.

Ну, раньше ещё Objective-C был. GNUStep можешь посмотреть - мне в юности нравилось (именно Си с классами-объектами в GUI)

Ну, IMHO Раст в принципе уродливый, зато не нужны сотни человек BO ловить.

не пишут на перл однострочники на пару страниц
посмотри примеры на том же cpan, уж всяко красивее раста или ц-выхлопов
со встроенной документацией прямо в коде

Это мы с вами не пишем.

если мыслить уровнем hello world - да, ООП тут выглядит переусложением. когда разрабатываешь сложные системы, дизайн из примитивов - это переизобретение велосипедов (это даже если опустить ресурсные и временные затраты на это). так что тут надо адресовать не к ООП, а к компетенциям авторов подобных писаний. хотя я бы даже времени на их плоды не тратил. «категоричность в суждениях - признак слабого ума» (с) народная мудрость

Накладные расходы на память: каждому объекту требуются метаданные для администрирования. Миллионы мелких объектов фрагментируют рабочую память (ОЗУ).

Видна полная некомпетентность афтара отзыва..