Здравствуйте, Sinclair, Вы писали:

S>Прекрасный пример. Давайте разберем его поподробнее.
S>1. Логика проверки зипкода инкапсулирована внутрь объекта "кастомер". Тебе это очень нравится, но на самом деле это означает, что у нас нет никакого способа узнать, валиден ли зип, не попробовав выполнить присваивание свойству. С точки зрения внешнего кода, кастомер — это чёрный ящик.
S>Возникают вопросы примерно такого рода:
S>а) как нам проверить валидность зипа прямо в UI, где недоступен экземпляр класса "кастомер"?
S>б) как нам получить осмысленный результат проверки, а не просто исключение и роллбэк? Ну, там, чтобы, к примеру, было сказано, где именно в индексе ошибка, и образец правильного заполнения?

S>2. Наша "сущность" начинает резко утяжеляться. Вот сейчас ей уже нужна по соседству табличка со всеми странами. Ну, то есть на самом деле надо будет еще и хранить историю правил формирования зип-кодов для всех стран.
S>Это еще уменьшает шансы "оторвать" ее от сервера приложений и обработать где-то еще.
S>Я уж не говорю про повторное использование в другой ситуации.

Что-то в этом есть.

T>>А теперь рассказывай, как ты будешь с этим бороться:

T>>

T>>update customer set zipCode = "любой невалидный zip";
T>>

S>Очень просто. Такого кода в прикладном слое вовсе нет. Потому что модификация зип-кода проходит только через CustomerManager, который конечно же не забудет позвать все правила проверки пре-кондишнов. Это раз.

Откуда CustomerManager и как он может помешать изменить Customer-а напрямую?

S>Два, в большом-большом количестве случаев лучше этот код разрешить. В частности, к примеру, потому, что далеко не всегда при создании кастомера есть информация про его зипкод. При таком подходе очень быстро окажется, что "ой, проверить стоимость остатков нельзя без проведения заказа, заказ нельзя ввести без кастомера, а кастомера нельзя завести без корректного зип-кода и ИНН". До свидания, бизнес сломался.
S>А если подумать головой, то окажется, что зип-код нужен только в тот момент, когда выполняется отгрузка товара. Если кастомер хочет заказать и заплатить, то нет никакой причины требовать от него валидность ненужного сейчас зип-кода.

Ну это скорее аргумент в пользу изменени логики валидации — она должна запускаться только при определенном статусе заказа.

S>В итоге, вместо вшитой в ZipCode { set ; } логики мы получаем Precondition для операции "отгрузить заказ", как я и говорил.