Почему боятся ООП?

Не боятся, а чураются.

чуркаются

Почему?

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

Юмор на уровне оппшника.

А если по делу, то концепт изжил себя. Опп был моден 40 лет назад, соответственно и языки созданные в то время торчали с этого.

А теперь глянь на языки созданные недавно. Мода прошла.

1. Нормальный и/или современный не заставляет создавать классы;
2. Как только появляется реализация абстрактного интерфейса, появляется и ООП.

В этом был мой поинт. Он не запрещает писать скрипты без классов на ООП-языках.

Он не запрещает писать скрипты

Я не про скрипт говорю. Это реальная программа с гуем в 78 строк. Вот реально зачем здесь ООП?

А теперь глянь на языки созданные недавно. Мода прошла.

ну так выкинь реализацию интерфейсов из своего новомодного ЯП, и с гордо поднятой головой говори «у нас не ООП»

Интерфейсы != ООП

Ещё раз попытайся понять тему. Она не про «почему в твоей программе нет ООП», а про "почему ты говоришь, что твой ЯП не поддерживает (отрешился/чурается/стесняется) термина ООП, если всё равно в нём реализована возможность отношения is-a (на уровне фичи (интерфейсов), а не на уровне ручного траходрома с указателями а ля «интерфейсы» в С)?

Интерфейсы реализуют отношение is-a. Это ООП.

почему ты говоришь, что твой ЯП не поддерживает (отрешился/чурается/стесняется) термина ООП

Потому что если заявить об ориентировании на ООП, набегут ООП-шники и начнут говорить «у вас нет полноценного ООП, а только [перечисление фич], надо ещё [перечисление других представлений о парадигме]» и объяснять, как правильно. Поэтому проще избегать таких заявлений.

Нет, это не ООП, а небольшая его часть.

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

Заметил, что некоторые разрабы стесняются (триггерятся/истерят/брезгуют/отстраняются/впадают_в_кому от) ООП. Почему?

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

Потому что если заявить об ориентировании на ООП, набегут ООП-шники и начнут говорить «у вас нет полноценного ООП

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

какая проблема сказать «мы поддерживаем ООП частично, наследование только через интерфейсы»?

Зачем? Вот ради чего?

Уверен, если задать вопрос прямо, тебе ответят, что «поддерживаются такие-то такие-то фичи, характерные для ООП, но в целом язык не объектно-ориентированный». Только зачем это заявлять, когда тебя никто не спрашивал? Можно ещё сказать «мы частично поддерживаем юникод в именах переменных и функций, но только частично — ту его часть, что ASCII». Можно, конечно. Но зачем?

В чём проблема использовать устоявшуюся терминологию? «Берём фичу из ООП» - что некорректно в этой фразе, если без маркетоидной шелухи.

Нет никакой устоявшейся терминологии, только твоя одержимость ООП.

«Берём фичу из ООП» - что некорректно в этой фразе, если без маркетоидной шелухи.

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

Можно ещё сказать «мы частично поддерживаем юникод в именах переменных и функций, но только частично — ту его часть, что ASCII». Можно, конечно. Но зачем?

вот и абсурдная аналогия подоспела

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

Вот тебе другая аналогия: представь, что у тебя в программе есть поле ввода email’а. И в этом поле этот e-mail, естественно, можно редактировать. Будешь ли ты заявлять «программа также является частично текстовым редактором»? Если нет, то почему? Маркетинговый отдел запретил?

Нет никакой устоявшейся терминологии

удобная отмазка для маркетологов

только твоя одержимость ООП.

с каких пор желание называть вещи своими именами стало одержимостью?

Наследование в айти - больная тема.

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

с каких пор желание называть вещи своими именами стало одержимостью?

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

не для того чтобы усложнить

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

Притягивание парадигмы только из-за того, что для её реализации нужна какая-то фича.

Сам-то понял, что написал?

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

И так и так используют. Это не серебряная пуля. Есть случаи, когда оно действительно сильно упрощает программирование. А есть те, где только усложняет. Отсутствие фанатизма (в любую сторону, хоть обажание, хоть хейтерство — одинаково) позволяет использовать подходящие инструменты для подходящих задач.

Для меня ООП (многие языки говорят у нас ООП нет напимер го или луа, а для меня оно там есть)

ООП не может быть или не быть в языке. Это способ организации программ. И его можно использовать хоть в Си или Ассемблере при большом желании. Другое дело, что есть языки, которые способствуют именно такому способу и имеют много различных фич или сахара для его реализации намеренно (например C# или Java как самые яркие примеры, ну или C++ как хрестоматийный), а есть такие, которые этого не делают. Можно ли его в них использовать? Да конечно можно.

Для меня ООП […] это сказать к этим обектам можно применять только эти функции.

Поздравляю, ты не понимаешь, что такое ООП.

Сам-то понял, что написал?

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

Поздравляю, ты не понимаешь, что такое ООП.

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

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

ООП делает код хуже.

Объясни что такое ооп

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

или хоть вехи обозначь

Знаменитая тетрада: абстракция, инкапсуляция, наследование, полиморфизм. Не что-то одно из этого, а всё вместе, применённое для создания подхода к программированию как к моделированию информационных объектов.

у нас тут не наследование, а …

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

Ещё была рекомендация не наследовать конкретные классы, а только интерфейсы. Была рекомендация не наследовать классы из библиотек. Но всегда соображения были теоретические. Ну вот отнаследовал бы кто-то 20 лет назад плюсовый класс std::vector и использовал бы MyVector. Чем это было бы хуже, чем обёртка? В данном конкретном случае, ничем. Но рекомендации даются на большинство случаев.

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

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

Вот тут все объяснено.

https://www.poodr.com/

Почему люди боятся стрелять себе в ногу?

ООП не может быть или не быть в языке. Это способ организации программ. И его можно использовать хоть в Си или Ассемблере при большом желании.

Если ЯП сразу не спроектирован как ОО, то там такие дикие костыли всегда нарастают, что лучше бы и не было ничего (яркие примеры безобразия: gobject, perl). Но приходится на этих костылях крутиться, потому что без ООП очень кисло. Так что даже PHP пришлось переделать под него, и все ваши современные недоязычки от неосиляторов ООП проследуют той же дорогой, либо помрут (чего им и желаю).

Почему люди боятся стрелять себе в ногу?

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

Читайте и слушайте Sandi Metz она как раз заниматеся вопросами дизайна, рефакторинга монолитных запутанных проектов. Все решения есть, они логичные и простые. Чем больше людей будет писать хороший код, тем легче будет программистам работать.

Больно, сэр.

Почему боятся ООП?

Потому что это абстракция, которая затрудняет восприятие и поддержку программ.

Вместо того чтобы написать в коде сделай_a(); сделай_б() с прямолинейной логикой на те самые 30-60 строк, фанаты ООП (это чаще всего новички) придумывают слой абстракции который понятен только автору и превращает flow программы в хождение по лабиринту.

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

Заметил, что некоторые разрабы стесняются (триггерятся/истерят/брезгуют/отстраняются/впадают_в_кому от) ООП. Почему?

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

Как только появляется реализация абстрактного интерфейса, появляется и ООП

Полиморфизм прекрасно работает и без ООП. То, что в некоторых недоязычках он намертво приколочен к иерархии наследования, а некоторые упоротые адепты этих недоязычков отождествляют ООП и иерархию наследования — проблемы недоязычков и их упоротых адептов.

ООП, точнее ООД нужен для того чтоб в ноги не стрелять.

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

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

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

SOLID это не простые правила. Ну, зазубрить-то легко, а где как использовать, чтобы стуктурная придурь не вскочила…. Скажем так, далеко не все практикующие знают «простые правила проектирования». Они вот научатся по всяким курсам, потом после их результатов работы за ними кто-то должен вытирать.

Все решения есть, они логичные и простые.

ООП логичный и простой (относительно) только на уровне «машинок», в реальном мире имеем фабрики фабрик и прочую шизофазию.

Чем больше людей будет писать хороший код, тем легче будет программистам работать.

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

Я всё сказал. Для справки - сам пишу ООП для денег и процедурно для души.

SOLID это не простые правила.

Sendi Metz расскзаывает о других правилах практического дизайна, без всяких акронимов и по житейски практично. Уже один раз я писал об это на LOR. Кому надо почитает ее книгу и послушает ее лекции. Там все действительно просто, надёжно, практично.

ООП не нужен там, где нет состояния или это состояние одно. Множественные состояния - это то, нафиг вообще нужны объекты

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

Если писать классы как сборник статических функций на бекенде то конечно

ООП не нужен там, где нет состояния

Состояния есть всегда. У памяти МТ. У процесса продукции других формальных языков. И самое главное - человеческий мозг мыслит дискретно, и поэтому в нём тоже состояния.

Только так и надо писать. Если нет обычных функций.

Потому что потом надо будет поднять голову от клавиатуры. Ведь если ООП, то следующим шагом будут паттерны, а там и до DDD недалеко.

Очевидно, потому что либо не понимают ООП вообще, либо думают, что понимают, но не умеют использовать. Второй вариант встречается наиболее часто. Глядя на такой код, реально думаешь: «блин, лучше бы ты про ООП вообще ничего не знал».