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

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

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

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

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

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

А не потому что это БЫСТРО решает поставленную задачу? Не безошибочно, не идеально в сферическом вакууме, а именно что - быстро. Не торопитесь, подумайте.

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

Нет. Это им тоже так сказали, а они и поверили, т.к. идиоты.

Попробуйте рассмотреть ООП в Java как говно сделанное для дебилов.

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

Потому что задача бизнеса (побыстрее окупаемость и прибыль) и задача разработчика нанятого бизнесом (сделать так чтобы работало нормально) - противоречивы.

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

Нет. Это им тоже так сказали, а они и поверили, т.к. идиоты.

Для вас будет открытием, но с большинством из них никто даже не говорил. Это вам во сне приходит Рич Хикки и рассказывает как все было. До других он не снисходит.

Попробуйте рассмотреть ООП в Java как говно сделанное для дебилов.

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

Отказ от ответственности и скорость разработки это две взаимоисключающие задачи которые пытается решить современный бизнес.

Сейчас мы наблюдаем попытку сохранить отказ от ответственности и оставить скорость работы. Эдакий микс Java и С++. Да, я говорю о Go - языке для индусов который не позволяет даже оставлять неиспользованные переменные в коде. Плох ли он как язык - безусловно да, хорош ли он в разработке - безусловно да.

И в чём ваше мнение отлично от лавсановского? Копрорации хотят поделки из говна и палок и для этого предоставляют такие же инструменты. Программисты пишут за деньги на чём скажут. Всё.

А тут чувак одну из крутейших 32 битных машинок (на то время) себе взял просто так.

Не просто так, а чтобы пройти Prince of Persia, чем он и занимался первые три месяца.

И в чём ваше мнение отлично от лавсановского?

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

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

Воля ваша, а я между «ООП в Ява говно, потому что всё говно» и «ООП в Ява говно, потому что вот такая наша жисть, малята» не вижу принципиальной разницы.

Имеете полное право так считать. Не думал что для кого-то окажусь с Ловсанчиком в одной лодке, но эвона как жизнь то повернулась…

Полагаю, вас обманом заставили учиться программировать

Не, в добровольно принудительном порядке еще в школе.

а истинное знание скрыли от профанов

Возможно и так. Причем с детства скрывали, нарыл книгу «Юный кибернетик» 1976-го года издания.

Термину «планируемое устаревание» уже почти век.

Попробуйте рассмотреть ООП и его развитие в Java как механизм отказа от ответственности.

Очень хороше определение! Именно подобное я слышал ИРЛ от одного трища про java.

яркие примеры безобразия: gobject, perl

4.2 Perl ООП уже запилили в 5.38 Corinna in the Perl Core

А не потому что это БЫСТРО решает поставленную задачу?

Могу печатать со скоростью тысяча знаков в минуту, но такая хня получается… :)

Лучше то ничего нет, поэтому выбираем меньшее из зол.

С/С++ где ноги отстреливаются дуплетом на бегу бизнес не рассматривает (исключения типа операционок есть, но мы говорим об остальном крупняке уровня транснациональных корпораций, финансов и тд).

Ну тоесть по мнению Obezyan крупняк не использует например оракловскую субд.

Initial release 1979; 45 years ago

Это ж ещё при Брежневе было. Можно подумать тогда какие-то иные варианты кроме C просматривались.

Есть, конечно

Намекаете что с 79-го ничего не изменилось, а новые версии это только цифирка? :)

Например?

Не могу представить, чтобы там встал какой-нибудь менеджер на совещании и заявил: „Мы тут в команде посовещались и подумали, а давайте Оракл на node перепишем“.

Все и разом никто не перепиливает, но в процессе жизни трансформироваться в другой вариант вполне может, тем более за 45 лет.

CLOS не осилил

Представляю себе, что будет, если внезапно выйдет новый положняк стандарт CL, в котором будут иммутабельные персистентные коллекции по умолчанию, литералы для векторов и мапок, STM и прочее хиккоугодное. В которую сторону переобуваться будете, милостивый государь? %)

в процессе жизни трансформироваться в другой вариант вполне может

Это очень больно и дорого => никто этого делать не будет.

в процессе жизни трансформироваться в другой вариант вполне может

Это очень больно и дорого => никто этого делать не будет.

Я же написал «Все и разом никто не перепиливает». Понадобилось перепилить один кусок, перепилили. Через какое-то время другой... То есть не перепиливание ради перепиливания, а не более чем изменения в процессе жизни.

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

А что, с другими подходами как-то по-другому дело обстоит? Сначала внимательно, вслух и с выражением читаем исходники каждой библиотечной функции, и только потом используем? %)

читайте внимательно то что в скобочках.

Понадобилось перепилить один кусок, перепилили.

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

И потом поддерживать франкенштейна на разных языках

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

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

У вас разрабами называют макак которые умеют только в один ЯП?

усложнить процедуру найма и погружения в проект новичков

Слово «новичков» похоже тут стоит понимать как «новичков в программировании».

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

Продолжайте жечь.

Прочитал, там написано:

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

Повторю свои слова: Ну тоесть по мнению Obezyan крупняк не использует например оракловскую субд.

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

т.е ща куча кодов это структурный ассемблер в мириадах синтаксисов

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

ООП это про фреймворки и их использование

То есть речь про GUI или Web фреймворки, например? Если брать GUI, то там вроде бы абстрактные классы не используется. Вначале наследуется конкретный класс формы (панели, виджета), потом этой форме передаётся список контролов (кнопочек, полей ввода и т.д.), а затем уже связывается событие нажатия на кнопочку с каким-либо методом («пресловутый Inversion of control»).

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

там как раз требуется отделение абстракций от реализации

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

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

с той разницей, что его нельзя создавать.

инстанциировать

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

крупняк не использует например оракловскую субд.

Замшелый крупняк мечтает о миграции на оракл с DB/2 и отдельных индексно-последовательных наборов данных.

А когда мечты, наконец, сбываются, то далеко не всегда результат радует.

Кроме GUI и логики в играх, где ООП идеально подходит к предметной области, этот подход быстро вырождается в «ООП ради ООП». Хорошо, можно на базе этого сделать эдакие микросервисы-без-сети - у тебя есть отдельные кубики, которые между собой взаимодействуют заранее оговоренным образом. Но - у тебя каждого класса будет по 1 объекту. Глаз не режет, внутренний перфекционист не блюёт с такого?

Основной подразумеваемый аргумент: «вся индустрия так делает». И исторический вклад программистов Германии в спасение рискованного проекта поспособствовал.

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

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

Плюс уже к тому времени тонны зарубежного (американского) софта. И вот планировалось, что IBM в основе Единой Серии послужит мощным локомотивом индустрии. Заведомое отставание при этом не сильно волновало принимающих решение, они видимо смотрели тут по аналогии с автомобильной промышленностью.

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

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

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

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

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

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

В любом где фреймворк оперирует глобальным состоянием и ожидает от пользователя фреймворка только списки указателей на функции. Когда в программе будет достигнуто то одно то другое состояние будут вызваться подходящие функции из предоставленных списков. Вот он чистый Inversion of control.
Из описания понятно что ООП как бы и не нужно, нужны только указатели на функции или любое техническое решение позволяющее делать dynamic dispatch.

Если взять тот же rust (который я не знаю) то он позволяет практически все это, и инкапсуляцию, и dynamic dispatch, и отделение абстракций от реализаций, там только нет наследования которое как бы и не нужно.

В ООП языках все больше и больше отказываются от иерархий классов, большая иерархия легко порождает проблему fragile base class. Насколько я понимаю эту проблему пытаются таргетировать внедрением SOLID где следование принципу под буковой L должно было бы её решить, только пишут программы не так.

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

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

Вы все-таки меня не поняли или я некорректно выразился. Я имел ввиду что сейчас большие конторы в массе своей не используют С/С++ для разработки своего продукта. СУБД является продуктом для самой Oracle, а не для HSBС Bank, например.

Другими словами крупняк использует такую СУБД но не РАЗРАБАТЫВАЕТ ее. То что они разрабатывают, пишут на других языках.

Но - у тебя каждого класса будет по 1 объекту. Глаз не режет, внутренний перфекционист не блюёт с такого?

так просто сделать их анонимными классами и всё

первично тут вообще свое развитое микроэлектронное производство

Не такое уж оно было и микро- …

https://archive.computerhistory.org/resources/text/IBM/IBM.System_360.1964.102646088.fc.lg.jpg

Иммутабельность, STM и упоротое ФП никому нахер не сдалось, потому что библиотеки таких коллекций есть, и их никто не использует.

Литералы для векторов есть, для хэш-таблиц - есть у большинства реализаций. Clojure-подобные пишутся с бодуна за час.

Мда, похоже вы из тех кто умеет только в молоток.

библиотеки таких коллекций есть, и их никто не использует

Потому что нет поддержки со стороны стандартной библиотеки — ни одна стандартная функция с иммутабельными коллекциями работать не будет. Конечно, мало кто готов пилить самостоятельно половину лишпа.

Так же и в жопаскрипте — immutable.js есть, поддержки языка/стандартной библиотеки для него нет. В итоге большинство продолжает по старинке жахать массивчики с объектиками in place, регулярно из-за этого огребая головняков. Более просветлённые личности делают вид, что массивчики и объектики неизменяемые и тоже продолжают ими пользоваться. Ладно хоть там многопотока нет, повезло, повезло.

А вот если бы это было в стандарте… %)