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

между отделами заключаете договора и в случае чего подаете в суд на соседний отдел из той же компании

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

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

То есть ты согласен с ТС?

А я даже не вникал в то о чем говорит ТС, он какой то бред пишет.

Если ты понял этот бред то сформулируй в паре предложений и я скажу согласен или нет.

Формулирую.

1. ООП вредно и его надо избегать.

2. ООП насильно впаривают в вузах, с этим надо бороться.

Так я понял, в общем смотри че происходит.

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

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

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

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

Гм… вот до сих пор я считал, что это и есть «писать в стиле ООП».

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

Вот и ТС из таких.

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

Книжку напишешь?

ооп это не хорошо и не плохо это инструмент и да им нужно уметь пользоваться.

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

Книжку напишешь?

Они уже есть https://www.litres.ru/robert-s-martin/chistaya-arhitektura-iskusstvo-razrabotki-program-39113892/

молоток это хорошо или плохо?

Хорошо для забивания гвоздей.

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

ООП хорошо для замены множественных выборов по типу значения

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

ООП хорошо для замены множественных выборов по типу значения

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

это упрощает внесение изменений в программу и то не всегда

Не упрощает.

Без ООП

button_display(btn, disp);

void button_display(button *btn, display *disp)
{
  switch(btn->type)
  {
    SIMPLE_BUTTON: ...
        break;
    COMBO_BUTTON: ...
  }
}

С ООП

btn.display(disp);

Вносить изменения одинаково.

Упрощает «переиспользование». То есть с ООП можно добавить новый тип кнопки не меняя код библиотеки.

Зачем ради этого целый ООП тащить, бывает же просто полиморфизм, без всех остальных ООПшных вывертов.

А что такое «целый ООП» кроме диспетчеризации по типу?

это упрощает внесение изменений в программу и то не всегда

Не упрощает. ….. То есть с ООП можно добавить новый тип кнопки не меняя код библиотеки.

Всё верно. Изменение кода не упрощает. Позволяет шире использовать без изменений. Если библиотеку менять можно, то ООП не нужно.

В библиотеке без ООП можно сделать функцию регистрации плагина.

Это и есть внесение изменений, добавление фичи и тд и тп. Работа программиста упрощается.

Это и есть внесение изменений, добавление фичи и тд и тп.

Нет. Внесение изменений — это внесение изменений в существующий код. А не объявление всего уже написанного святым писанием и попытка переиспользовать только через интерфейс.

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

Нет. Внесение изменений — это внесение изменений в существующий код. А не объявление всего уже написанного святым писанием и попыткой переиспользовать только через интерфейс.

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

Вот чем проще тебе это будет сделать тем лучше. внезапно.

Вот чем проще тебе это будет сделать тем лучше. внезапно.

Единый switch/case поменять проще, чем писать новый метод класса. ООП хорош только если существующий код запрещено менять.

прочитай книгу.

Что? Отстань от меня со своим ООП, я пооффтопить про водку пришёл.

Странная книга. Инверсия зависимостей существовала всегда, но это преимущество ОО.

В примере с SRP пишет, что есть проблема, если две несвязанные функции в одном классе используют одну и ту же функцию regularHours и предлагает разбить несвязанные функции на отдельные классы. Но про regularHours ту же забывает. Её предлагается копипастить? Или делать ещё один класс HourCalculator (и вернуться к начальной проблеме, что этот класс используется в двух несвязанных классах)?

ты че уже прочитал?

Треть.

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

А что такое «целый ООП» кроме диспетчеризации по типу?

Все есть объекты, обменивающиеся сообщениями, инкапсулирующие состояние с поведением и наследующиеся друг от друга, вот этот весь метафизический беспредел.

а читаешь так что бы понять или так что бы прочитать?)

Чтобы понять. Но 90% идей для меня не новы (уже читал в других местах), поэтому получается быстро. Примеры новы, но с моей точки зрения, больше запутывают, чем разъясняют.

А… Ну тогда «целый ООП» вообще нигде не нужен. Разве что какую компьютерную игру с ИИ писать.

ну может перевод не самый удачный, я помню что когда читал иногда заглядывал в оригинал

я помню что когда читал иногда заглядывал в оригинал

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

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

DRY это не про одинаковый код, внезапно. DRY нужен тогда когда тебе приходится менять что то одно и то же в разных местах. А в том примере на методе regularHours висят два независимых актора бухгалтерия и HR, они независимо друг от друга пишут таски и ни чего между собою не согласовывают.

То есть у тебя в результате есть regularHours1 и regularHours2 одна для бухгалтера вторая для HR. Если бухгалтер ставит задачу мы меняем первую, если HR ставят задачу то меняем вторую.

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

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

Ребят, я вам сразу с monk вместе отвечу. И по поводу бурной дискуссии, развернувшейся после моих вопросиков, тоже.

Для начала, monk, ты в этих вопросах крут, lesswrong читаешь, и не только. Таких секачей можно сразу на третий уровень вопросов ставить. Но остальные участники дискуссии нас не поймут))

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

И в этом смысле ООП, само по себе, это «язык изложения и фикстации мыслей» (поддержанный на уровне ЯП), который позволяет инженерам как раз-таки уйти от ситуации «Это все интуитивно понятно, я не знаю, почему это непонятно тебе. Ты, наверное, просто тупой». У этого «языка изложения мыслей» есть серьезные ограничения, которые и привели к кризису ООП, но они свойственны и всем остальным «языкам изложения мыслей». Поэтому какой-то эффективной системы коммуникации «промежуточного инженерного материала» предложено не было. И этому тоже есть объяснение, почему, например, вещи типа ТРИЗ, не взлетают за пределами узких областей применения. Data-oriented design тоже не решает этих проблем, он просто смещает фокус.

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

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

Теперь по дальнейшей дискуссии между вами. Вышеобозначенная мною проблема «языков изложения мыслей» происходит из того, что попытки начать рассуждать о предмете быстро «гибнут в рекурсиях» и хождениях по кругу. Тут есть очень хорошая картинка на эту тему. Еще другая иллюстрация проблемы, из философии разума: Homunculus Problem (там картинка есть). Во что вы друг с monk и попали сразу. И по этой же причине я тут избегаю длинных дискуссий на все эти темы.

Т.е. level 1 вопроса о программировании — это рефлексия на интуицию.

Level 2 — это когда все участники дискуссии способны распознать попадание в «бесконечную рекурсию» (проблема остановки, гы) и конструктивно выйти из неё, продолжив эту дискуссию.

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

Они уже есть https://www.litres.ru/robert-s-martin/chistaya-arhitektura-iskusstvo-razrabotki-program-39113892/

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

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

То есть языки, заявляющие о поддержке OO, фактически ослабили превосходную инкапсуляцию, некогда существовавшую в C.

https://vk.com/wall-51126445_24407

http://prof.mau.ac.ir/images/Uploaded_files/Clean%20Architecture_%20A%20Craftsman%E2%80%99s%20Guide%20to%20Software%20Structure%20and%20Design-Pearson%20Education%20(2018)%5B7615523%5D.PDF

Ну и как, мы правильно вышли из рекурсии?

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

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

Честно говоря, я всего не читал. Технически «выйти из рекурсии» не проблема. Рано или поздно все стороны просто устанут. Дело тут в том, как из неё выйти на другой уровень, когда еще даже непонятно, а есть ли он, этот другой уровень, вообще. Не говоря уже о том, what is it like to be on a different level?

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

И меня печалит/пугает тут то, что оно всё, вообще говоря, не в вакууме находится. И дизайнеры языков далеко не первыми столкнулись с проблемами, которые они пытаются решить применительно к своему домену деятельности. Печалит то, что мало у кого (ну вот monk у нас тут приятное исключение) возникает желание «изучить вопрос». Да, трудозатраты тут будут вовсе не как на почитать статью на Хабре. Непонятно, что изучать, когда тот же LessWrong — не такой уж и less wrong. Нет привычных нам ориентиров «куда смотреть», и мануалы с туториалами еще не написаны.

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

напиши откуда ты всего этого набрался, что почитать?

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

Поставьте в морозилку хеннеси

Ну это преступление. Разные напитки по разному пьют. У коньяков, виски и прочих дистиллятов вкус сильный, их достаточно немного охладить. Я предпочитаю пить без льда, чистый (neat).

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

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

Ну вот, ты уже хочешь побить меня ногами. Пока что, образно.

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

напиши откуда ты всего этого набрался, что почитать?

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

Ну вот, ты уже хочешь побить меня ногами. Пока что, образно.

Да нет, у тебя там прямая претензия на сакральность:

Таких секачей можно сразу на третий уровень вопросов ставить. Но остальные участники дискуссии нас не поймут))

только и всего, я сказал как есть.

У меня есть заготовочка как раз для таких случаев.

The following is my (Victor Smirnov) personal view on AI that other committers and contributors may not necessary share or support.

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

только и всего, я сказал как есть.

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

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

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

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

ок, почитаю

Что же касается «сакральности». Давай, я поясню на примере условных Васи, Пети и Димы.

Вася — рационалист, физик-математик, педагог. Имеет ученую степень и перспективу в Академию Наук. Ведет блог, популяризирующий науку и несколько долгосрочных opensource проектов.

Петь — интуитивист. Дизайнер UI/UX, «тонко чувствующий пользователя» и на этом создающий отличные интерфейсы продукта. У него есть своя мастерская дизайна, где он дает уроки мастер-класса своим «ученикам». Его «ученики» тоже успешны.

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

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

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

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

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

ООП можно применять на любом языке, но на некоторых «ты не захочешь», а на других — можно не применять, но ты опять не захочешь, «потому что классы же!» и «потому что язык же разрабатыался как объектно-ориентированный!», даже если язык уже это давно перерос :)

если цель именно в том что бы донести мысли до человека.

Это не так уж просто, когда ты не знаешь еще, с кем говоришь)

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

Но там ведь не только моя писанина. Там есть ссылки на теории, на которых эта писанина основывается. Или я должен обязательно сослаться на кого-то другого?

Есть вероятность что ногами бьют именно за это, а не из за вопросов.

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

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