Когда использовать ООП?

go*не

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

сишке

То же самое, максимум - генерики(ещё не засахаренные).

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

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

почитать кого-нибудь из классиков

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

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

Я ведь привёл один критерий ненужности генериков.

это какой?

В очень многих задачах связи/зависимости невозможно отобразить в ацикличные графы

и почему это аргумент против ООП? Или аргумент против чего? Потрудитесь более развернуто выражать ваши мысли

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

Какой критерий - ненужные аннотации.

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

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

не надо путать теплое с мягким

и почему это аргумент против ООП?

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

А против тех, кто везде видит ООП

Цитирую вас

то делать, когда много абстрактных классов с множественным наследованием и вообще нет иерархии

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

циклы в данных это вовсе не циклы в «понятиях»

Поменяй уровень абстрации и «понятия» станут данными, классы -объектами.

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

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

Так вот, наглядно на тему для фанатов генериков(если такие здесь ещё есть). Как на генериках выразить что-то такое: (auto map, auto key) { return map[key]; }. У меня на всё про всё ушло несколько десятков символов. Могут ли генерики хотя бы приблизится по выразительности?

Каких «классиков» надо читать для решения задач, где нет иерархии объектов и типов?

Жду ответа.

Да любого, если у тебя в проекте есть объекты (или вообще данные) без типа, начинать надо буквально с букваря, что-нибудь из школьного курса

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

Потому что ООП и классы - это сложно. Реализуют это ООП пара языков, остальные пытаются закосить под ООП. Отсюда все эти «трейты, интерфейсы, композицию структур».

В проекте типы-суммы, типы-произведения, рекурсивные типы. Какого «классика» ООП читать?

ООП и классы - это сложно.

Как будто это хорошо.

Я пока не говорил хорошо это или плохо. Я говорил о причинах появления якобы альтернативных механизмов. Вот, причина - неосилили.

Каких «классиков» надо читать для решения задач, где нет иерархии объектов и типов?

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

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

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

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

целых три вида типов, которые отлично выстраиваются в иерархии.

Рисуй иерархию… для рекурсивного типа, например, list a = nil | cons a (list a). Иерархия типов будет того же размера, что реальный список?

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

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

Ага… и где кодеров искать, чтоб не сидели на чем-то и не ломили ЗП!??

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

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

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

Есть программисты, которые действительно написали серьёзные проекты. Вот только они чаще всего молчат и ничего никому не рассказывают. Редко когда рассказывают. Но когда рассказывают - надо слушать. Но и то - с опаской. Всё равно это лишь их мнение.

Про Фаулера - хз. Я его книжку Refactoring прочитал сто лет назад. Хорошая книжка. Вроде как он всё очевидное написал, но на том этапе для меня это было прочитать и уложить в голове полезно. И он эту книжку написал правильно - он сразу делает упор, что любой рефакторинг работает в обе стороны. Общее выражение можно вынести в локальную переменную, а также локальную переменную можно заинлайнить. И то и другое - рефакторинг. Какой выбирать - включайте свою голову, а я вам просто показываю варианты, вдруг вы не в курсе. То же про паттерны гоф. К примеру паттерн визитор - клёвый. Я бы до него сходу не додумался. Хотя применял пару раз и все пару раз в итоге заменил на свитчи, но вполне может быть, что когда-то он таки будет к месту и я, зная про него, его применю к месту.

А вот именно к дяде Бобу у меня отношение отрицательное.

И вообще я считаю проще надо быть. Сложно написать любой дурак может. А ты напиши просто.

object Nil: ListItem<*>
data class ... : ListItem<T>

Это какой «классик» ООП так пишет? Показывай тип-сумму в классическом ООП

ListTail<T>(val value:T, next: ListItem<T>)

Тут в классическом ООП теряется информация о типе (посмотрю, как реализуешь тип сумму на ООП)

Тут в классическом ООП теряется информация о типе

Сохрани информацию о типе в объекте, в чем проблема?

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

Когда Бугаенко впервые появился на арене нашего цирка, это был этакий краснощекий пылкий мужик лет 35ти, который всем своим видом пытался изобразить, как же он устал от творящегося вокруг идиотизма. И он начал вещать, что все вокруг не понимают, как надо, а знает только он. Этакий Мессия. В его религиозной повестке было крайнее неприятие концепций Java EE и подобных, и он провозгласил, что если ты уверовал и последуешь за ним, то через год у тебя будет фреймворк в сто раз лучше, чем Спринг. Прошло лет десять. Спринг по прежнему с нами и радует нас новыми версиями, а веселый паноптикум фриков продолжает спонсировать пустомелю Егора, который за эти десять не сделал ничего. Только бабла поднял на дурачках.

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

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

А класс уже существует.

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

для рекурсивного типа, например, list a = nil | cons a (list a).

это «определение» говорит лишь о том, что нечто может быть как нулевым значением(это собсвенно косвенный конструктор типа), так и имеет операцию list.cons(element), неясной семантики.

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

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

Это проблемы ООП, а головохвостые списки - базовый тип во многих языках программирования, нет никаких проблем бесконечными (иерархическими) типами

это не рекурсивное определение списка. это жопорукое определение вида:

class List<T> {
  List();
  List& cons(T value);
}

Если List заменить на Something - то вообще непонятно что это. Натуральные числа подпадают под этот шаблон. любые классы, что имеют функцию fff(T) тоже ему тождественны.

из «списка» тут только само имя.

хамской манере. Охлади траханье.

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

Позвольте на этом закончить разговор с вами! Премного благодарен!

мальчики, не ссортесь

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

Кому опять пришла в голову светлая идея разрешить анонимов? Зачем вы это делаете?

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

Наоборот, про путь Бугаенки нужно говорить, чтобы молодым инженерам не повторять его ошибок.

1. Ехать работать программистом в Амстердам и Кремниевую долину смысла мало ибо посадят на скучную работу по исправлению ошибок в чужом коде и могут запросто заменить в любой день. Скорее всего, именно на этой наискучнейшей работе Егор понял о вреде изменяемости внутренностей объектов в многопоточном коде.

2. На открытом коде не заработаешь денег даже на еду и съемное жильё. На своём докладе про открытую разработку Егор рассказал о каком-то испанце или мексиканце, которому платит какой-то фонд сто тысяч долларов США в год за поддержку и развитие его открытого проекта. Одному единственному человеку выплачивают столько, сколько зарабатывает программист средней руки в США, коих множество. Сможет ли человек опередить весь белый свет и стать таким же? - Как известно, Егор сам не смог и сидит на зарплате в корпорации.

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

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

А у него ООП возведён в абсолют.

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

https://github.com/yegor256/cactoos можешь ознакомиться с этой библиотекой, если ты в теме джавы.

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

Может кому-то такой подход и понравится - ради бога.

Когда программируешь. Чтоб понять, надо начать писать код. Обычно такие вопросы задают когда и строчки не написано.

я не слишком в теме жавы. понял, спасибо за информацию

это «определение» говорит лишь о том, что нечто может быть как нулевым значением(это собсвенно косвенный конструктор типа), так и имеет операцию list.cons(element), неясной семантики.

cons — не «операция неясной семантики», а конструктор, с единственной семантикой объединения элемента в качестве головы и списка в качестве хвоста. Стандартное определение иммутабельного ордносвязного списка в любом языке ФП.

операций удаления, и вставки тут нет.

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

это не рекурсивное определение списка.

Это рекурсивное определение списка.

понятие          определение
  |          ___________________
  V         /                   \

list  a  =  nil | cons a (list a)

  ^                        |
  `-----------------------'
  ссылка на определяемое понятие
  из определения, т.е. рекурсия

Натуральные числа подпадают под этот шаблон.

Конечно подпадают. Смотри «кодирование Чёрча», например.

из «списка» тут только само имя.

«список» — это имя, да.

подскажите литературы/статей по архитектуре приложений/информационных систем.

Please, keep in mind in these lists: the last is not the least!

• https://bytebytego.com/
• https://www.poodr.com/
• https://martin.kleppmann.com/
• https://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215
• Software Architecture Patterns (c) Mark Richards. Всего 55 страниц. Раздавалась бесплатно на O’Really.
• https://www.martinfowler.com/

База: Курячий, Столяров, Кетов.

• https://uneex.org/
• http://stolyarov.info/books
• https://vk.com/dketov (Внутреннеу устройство Linux, цикл лекций на youtube)
• https://citforum.ru/operating_systems/posixbook/

База: Таненбаум !!!!!

P.S. Много, много, много, много, много, много, много, много, много, много программировать. Без поставленного программирования, все разглагольстования о дизайне - пустая болтовня. Можно себя вообще не утруждать, а остаться спорить на LOR.

• https://adventofcode.com/
• https://www.codewars.com/
• https://leetcode.com/
• https://app.codesignal.com/
• https://www.codility.com/

а это - рекурсивное определение списка?

class List<T> {
  List();
  List& cons(T value);
}

Потому что ООП и классы - это сложно.

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

а это - рекурсивное определение списка?

А это не знаю что.