По поводу "инкапсуляции" обсуждали когда-то в нашем маленьком приватном чате. Продублирую:

Алан Кэй прямым текстом зачем был создан ООП:

Though OOP came from many motivations, two were central. The large scale one was to find a better module scheme for complex systems involving hiding of details, and the small scale one was to find a more flexible version of assignment, and then to try to eliminate it altogether. As with most new ideas, it originally happened in isolated fits and starts.

Зачем нужно сокрытие? Для контроля состояния

Тот самый холивар титанов на тему OOP: https://twitter.com/Grady_Booch/status/1302678071049216000?s=19

Если состояния нет, сокрытие не нужно. Потому что ничего не "поломается". В ФП не нужна инкапсуляция.

Конечно не нужна. Там же состояние неизменяемое.
https://twitter.com/mfeathers/status/29581296216

Супер

Это, кстати, ответ на вопрос, почему FP != Anemic Domain Model.

Да. Но это отдельная большая тема

Лично прогал и на Фортране, и на Паскале, и на Плюсах, и на Яве. Преподавал Пролог и немного Лисп. Прочувствовал боли процедурщины и ощутил ограничения ООП.

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

Вот эта статья оказала на OOP значительное влияние, по мнению Г.Буч. Она как раз про сокрытие информации:
http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.132.7232

Цитата Г.Буч:
https://twitter.com/Grady_Booch/status/1302747652426145793?s=19

Иван, можно в 3-х словах?

В одном из проектов как то упустил момемент и не выстроил процесс арх контроля. Через год в проекте было более 500 модулей. Ужасная связанность, куча циклов, на DSM смотреть было нельзя. Попутно развивать функционал и рефакторить было невозможно. При разборе сложившейся ситуации, выяснилось что ребята приняли довольно простой и к ужасу повсеместно распространнёный принцип. Описание поведения - интерфейс должен быть явно отделён от реализации, что привело к тому что буквально каждый класс реализовывал как минимум один интерфейс.  На сколько я помню это были временя ещё 5-6 явы. Код выродился в jar hell со сложно трассируемыми бизнес связями, и для того что бы хоть как то возложить верификацию этих связей явно на компилятор народ начал использовать передачу классов вместо интерфейсов. Что сильно цементировало циклические зависимости и сводило "модульность" на нет. Что характерно, на тот момент у меня было мало опыта работы с Java, но было за плечами довольно много С++, я чётко понимал принципы разделения на уровне едениц компиляции (объектные файлы) и едениц рантайма (dll). и к удивлению для себя обнаружил что реальная модульность и изолированность делается средствами процедурными со многими отступлениями от ООП.

Алексей, а какой выход из такой ситуации? Напиши, если не трудно.

Alexei, современная ИТ религия диктовала что вам надо перейти на DevOps и микросервисы 😊

>В ФП не нужна инкапсуляция

Почему же ? А структурное программирование - как предтеча ООП ? А отсутствие goto ? В ФП является вполне хорошим тоном разбивать код программы на процедуры и публичные API; управлять зоной видимости переменных; а данные бить на рекорды, кортежи, множества .. Дейкстра, Буча и Вирт сильно в этом преуспели - "Алголоподобные" языки основа сегодняшних ЯВУ. Симулу тоже по привычке обзывали "Алгол с классами".. Но что прикольно - так оно по сути и осталось. Многие недостатки и оверхед от ООП сегодня решает ... компилятор через инлайны. И например java в этом сильно преуспела

elendill "Угу, я тоже пытался) Предположу, что суть месседжа оракула в том, что ООП - это поделка на продажу любителям простых решений. И нет никакого единого и правильного ООП и быть не может. (таже логика для ФП, имхо)."
На 100500 соглашусь. Рад что к утру все само собой образумилось. Программирование, как инструмент управления - подчиняется всем его канонам теории. Начиная с теоремы Котельникова (как вариант принципы полноты Геделя) - обьект является управляемым, только если мощность (в математическом смысле) системы управления превышает мощность обьекта управления. Так и теории частичного управления и устойчивости (Найквист, Ляпунов, Гурвиц и пр) - не бывает управления без ограничений - по ресурсам, энергии, времени, полноты входной информации и пр. Соответственно любой метод вы обязаны, как архитектор сопровождать исчерпывающим списком границ его применения. И чем эффективнее метод, тем _уже_ может быть его сфера применения.  Но это уже не нравится продавцам и миллениалам, им подавай snake oil... В вышеупомянутой статье Дейкстры есть пассаж - что манипуляции "а в реальной жизни",  "вы жизни не знаете", "а теперь забудьте чему вас учили в университете" с которыми встречаются выпускники университетов - часто сквозит грустная мысль - что "реальная жизнь" стала по сути "антиинтеллектуальной". Успех ИТ проекта все чаще происходит по косвенным, не зависящим  технологии причинам, доказывая чаще "ошибку выжившего".. И соответственно Enterprise Architector обязан владедеть и этими навыками "реального мира", умело перескакивая в системы координат стейкхолдеров. Например, мало кто и т.н. дипломированных "банковских аналитиков" мог ответить на мой простой вопрос - а скажите, а какие документы в банке чаще всего подделываются ? Welcome to real world ! ;-)

Ошибка выжившего вообще классный кейс. Вот хвастается какой то стартапер что он стал успешным. И объясняет это что он правильно разрабатывал софт - по айджайлу, в команде и пр.. но только не договаривает - что где то рядом трудилось еще 100 тыс. стартаперов - у которых не вышло ничего..  А первому помог тупо "случай".. Так и EA могут топить за TOGAF, Archimate и обьяснять что именно это им помогло успешно спроектировать АСУ в какой то Росгидропушнина.. Но о том что то же ФГУП Росгидропушнина до этого кинуло с деньгами тысячи таких экспертов, и годами тратило миллиарды с весьма посредственым успехом с другими аналитиками, тоже наверняка знавшими FEA, DODAF и прочие ГОСТ 34 - сравнивать результат отказываются... Ибо опять же только его величество случай тут в правильном порядке выбросил кости.. А мог бы и не выбросить...

Пришлось бить набат и каяться в своей некомпетентности ))))
С инженерной точки зрения пришлось изобретать велосипеды.
1.    Натягивать SOLID на уровень модуля.
2.    Жестко выстроить процессы сервисного дизайна, всё что делает модуль – это сервис, описанный контрактом. Создание объекта – ответственность модуля, через публичный АПИ (инъекция).
3.    Всё что не АПИ – приватно в рамках модуля. (в Java – это очень не удобно, так как сокрыть кроме как в пакете не реально).
4.    Качать скилы аналитиков правильно применять принципы изоляции.
Это конечно привело к распуханию модулей, но резко сократило их количество и спрятало все циклы в границы пакетов, что вполне было приемлемо. Вообще все чесали репу почему бы не переписать все на Eiffel. ))))) На всё про всё + 1 год. Но проект жив и здравствует до сих пор , вполне гибко развивается.

Сейчас конечно есть много инструментов которые дают DI IOC из коробки.

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