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

Конструктор никогда не возвращает 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 - нет.

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