Mike Chaliy wrote:

> Интерсно мнение, может ли идеологически сеттер кидать исключение?

Сеттер обязан кидать исключение, если какой-то аргумент может привести к
дальнейшей ошибке ПРЯМО СЕЙЧАС. Например, в аргументах передали какой-то
объект obj, а мы у этого объекта в сеттере забираем идентификатор или
значение obj.getId() — поэтому мы в самом начале сеттера ставим
Assert.notNull(obj) в случае приватного или внутреннего публичного
метода, или throw new IllegalArgumentException в случае внешнего
публичного метода (SJCP).

Проверки на диапазоны, допустимые значения, размеры и прочее НЕ должны
быть в сеттерах. Не забываем про принцип Single Responsibility
Principle, а также про то, что мы должны стремиться к тому, что весь
код, который может работать на основе публичного контракта класса должен
быть вынесен за пределы класса.

Поэтому мы имеем следующую схему:

1. Сущность, которая хранит значения и ловит уж совсем откровенные косяки.

2. Спецификация сущности. В спецификации мы задаем правила определяющие
валидность сущности. Правила могут быть как очень простыми (login !=
null), более сложными (match("\\w+", name), так и составными (password
== passwordConfirmation). Спецификация может храниться мильоном
способов: жестко-закодированном, во внешнем XML конфиге, в скрипте, в
виде аннотаций сущности и т.д.

3. Валидатор. Данный элемент перед сущность и ее спецификацию, и
начинает проверку. После чего выдает список несоответствий с кодами.

Для сущностей domain layer можно вызывать валидатор в DAO слое перед
сохранением и после загрузки сущностей и возбуждать исключение в случае
наличия хотя бы одной ошибки.