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

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

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

Зачем слово ООП тут. Просто процедуры и норм.

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

ну я очень рад тогда )

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

Мне вообще это его подход очень фп напоминает.
constructor overloading заменяет pattern matching.
Оставляем в обьекте по 1 методу, чтобы получились лямбды.
Получаем фп.

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

Или более подходящий для такого ООП.

Я лично считаю, что нет другого ООП, кроме как по Алану))

Допустим у нас есть VO DateRange, тогда у него может быть метод bool intersects(DateRange). В таком случае он(метод, а следовательно и VO) будет скрывать в себе информацию о том, как определять пересекаются ли диапазоны дат.
Если говорить про инкапсуляцию как защиту от переходов в непредусмотренное состояние, тогда по идее тоже может, например VO Money может иметь проверку в конструкторе, что деньги не могут быть отрицательным значением.
А "соединение кода и данных" - это как-то непонятно 🤔

проверка в конструкторе это ещё та стрельба в ногу

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

я и про инкапсуляцию и про хайдинг написал

> Если говорить про инкапсуляцию как защиту от переходов в непредусмотренное состояние

нельзя так говорить. про сокрытие можно

тогда непонятно что такое инкапсуляция, "соединение кода и данных" - так себе определение

тогда пример с методом intersects подходит и всё равно VO инкапсулирует в себе логику работы с данными 🤔

почему?