В тему Java.

Об этоп перце (Егор) я впервые услышал в контексте книги Elegant Objects
https://www.yegor256.com/elegant-objects.html

Признаюсь что еще не читал но пошел по ссылкам от того кто такой автор.
Потом были несколько конференций с темами "Объектно-ориентированное вранье",
"Utility классы нас убивают", "ORM - это обидно"

Предлагаю на ваш суд один из последних видосов на тему Силиконовой долины и Тайм-менеджмента
и Zerocracy.

[spoiler]

Из его репок.

Вот проект takes.org который сам Егор называет "убийца Спринга".

https://github.com/yegor256/takes

Еще проект под названием Кактус.

https://github.com/yegor256/cactoos

Давай не будем узкомыслящими. В конце концов его идеи гораздо шире просто композиций.
Если мы будем оценивать Егора с позиции обструкции - то мы будем похожи на слепых которые
ощупывают слона и тут-же делают мгновенные выводы.

Мы-же не хотим быть слепыми дураками? Надо посмотреть идею в совокупности.

Коде-ревью - это просто консенсус группы людей которые по джентльменски
собрались и решили что такой код ПРИЕМЛЕМЫЙ для них и сопровождение
его не доставит проблем.

А теперь вопрос к тебе - как ты предлагаешь улучшить этот код? Не забывай также про KISS/YAGNI. Их никто не отменял.

Java создавалась изначально в 1996 году как язык для управления встраиваемой техникой. Холодильниками
и кофеварками. И вопрос расчета финансовых величин остро не стоял. Главное было - поддержать базовый ООП
и безопасную память и фундаментальный типы short/int/long.

И поэтому мы сегодня имеем просто наследие. Хотя я согласен что спека языка - несовершенна для описывания
сложных типов или трейтов. Вобщем все кто хотели сложных типов ушли в Scala.

Это ты что-то недоучил.

Конструктор никогда не возвращает null в Java. Он или всегда отрабатывает или бросает неконтролируемое исключение
но в этом случае нам плевать на return потому что исключение выбросит нас раньше чем return.

По личному наблюдению языки с динамикой (JScript/Python) имеют смысл на прототипах или на малых проектах.
Чем больше он будут расти в монолит (а это закономерный конец почти всех проектов) тем сильнее и сильнее
будет влияние рандомных ошибок типизации. В самом деле. Кто в крупном проекте с динамикой сможет гарантировать
что данный метод корректно вызовут при условии что компиллятор даже этого не знает. Сведенья о типах появятся в рантайме.
Поэтому бородачи потягивающие смузи имеют большой технический долг. Или они - крайне безответсвтенны и их
кажущаяся беззаботность имеет другую природу. Не техническую. Но мы об этом не будем говорить тк тема топика - Java.

Некоторое время назад я пожалел что мы еще не на Скале. Мы часто используем generics.
В части например таких




Это удобно для конструирования всякой логики. Но беда подобных дженериков в том что они совершенно
скрывают информацию о том что за величина лежит внутри. У нас были id-шники разных типов. Они все были int
но несли разную семантику. ID-order, ID-local, ID-global, и эти-же величині (lnt,Long) использовались для меток
времени timestamps. Понятно что ошибка программиста в толковании этого значения приводила сложным
и трудно улавливаемым дефектам. А если-бы мы могли сделать дефиницию типа наподобие.




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

Оборачивать каждый Int обёрткой мы пробовали. Неудобно.

Опять-же это не какое-то моё личное решение. Так решала вся команда.

Если ты не Project Owner то ты на проекте не принимаешь таких решений. Я имею в виду декомпозицию.
Ты - работаешь просто в команде над общей задачей. Ты не можешь просто сказать - "Эй посоны я тут
придумал давайте мы возьмем топор и расколем наш монолит на 4 части и всё будет круто!"

Если ты говоришь о том как НАДО-БЫ сделать или как ты бы ХОТЕЛ сделать - это совсем другая тема.
Но мой тезис остаётся по прежнему верный и для большой и для малой системы. Просто он стоит остро
для большой системы.

Кстати для микросервисов отсутствие явного типа на ендпоинте - это тоже поблема. Тоесть к типизации
вы все равно подойдете но через другую головную боль. Через SOAP/Swagger/GraphQL e.t.c.

Я как-то предложил в одном проекте заменить все аргументы всех методов на Object (где нет примитивов).
Мой поинт был в том чтобы показать фронт-девелоперу как выглядит остутствие типов для Java и к какому
семантическому ужасу это приводит.

Дженерики в Java - это идея которая не была до конца продумана. Например в С++
вы можете генерализовать примитивы. А в Java - нет.

Это прозвучало - по Егоровски!

В этоху XML/XSLT (2000-е годы) была такая технология. Вобщем основная идея. Веб-сервер отдает только XML-контент.
А преобразования из XML осуществляет сам браузер. А микро-код для транформации зашит в XSL(t) скрипте.
Чисто функциональный язык.

Получается Pipeline: XML => XSLT+XML => HTML/TXT/e.t.c

Скорее всего это хардкодный скрипт типа каскадых стилей. Он не меняется. Его имя - статично по отношению
ко всему контенту. Как index.html, styles.css. Поэтому автор решил его не параметризировать тк. смысла нет.