M>>Спасибо. Это все равно возвращает к изначальным:
M>>- кто и как будет проверять, правильно ли реализована логика в этих типах
M>>- не впихивать же 40 условий, половина из которых зависит от конфигураций, в эти инициализаторы

G>1. так же как и раньше,

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

G>просто некоторая часть ошибок найдется компилятором, а не тестером.

Какая часть?

G>те этот механизм ничего конечно не гарантирует, кроме того, что какой-то процент ошибок найдется раньше. так же см пункт 2.
G>2. ну вот поэтому я и не любитель таких методик, практика показывает, что гораздо быстрее найдется вылетевший NPE, чем ты озверев впихнешь всю бизнес-логику в систему типов. БОлее того, если уж ошибка проскочит компилятор, то найти ее будет сложнее, чем банальный NPE в примере с билдером.

:D Вот я как бы к этому веду и намекаю

G>PS. немного подумав. и все-таки, для некоторых вещей такие техники вполне имеют смысл, например для каких-то базовых сущностей системы. Например, ордер в торговой системе инварианты которого проверяются компилятором это скорее добро, чем зло, учитывая, что модифицируется он крайне редко и можно потратить силы на систему типов один раз.

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