StringConcat - разработка без боли и сожалений

Евгений

Работаем со студентами над курсовым проектом и неожиданно уперлись в проблему, которая на первый взгляд кажется тривиальной. Value Object. Казалось бы, что может быть проще? Паттерн элементарный, тесты пишутся очень просто, всё логично и прозрачно. Но на…

В комментах к прошлому посту справедливо спросили: а зачем вообще такая строгая валидация? Хороший вопрос. Давайте разберёмся.

Первый сценарий — когда нам нужно просто что-то отобразить. В этом случае можно обойтись минимальными проверками. Условно, проверили, что поле не пустое — и хватит. Тут и правда нет смысла городить сложные правила, мы скорее переживаем за то, чтобы верстка не поехала.

Второй сценарий — когда объект реально участвует в предметной области. И вот тут начинаются настоящие приключения.

Например, числовые значения. Их желательно приводить к конкретной точности. Иначе арифметика начинает жить своей жизнью: где-то округлили слишком рано, где-то потеряли пару копеек — и всё, отчёт уже не сходится. Сначала ошибка на пару рублей, потом на пару сотен тысяч, и внезапно прибыль компании уже не прибыль.

Другой пример — ИНН. Если пользователь ошибся хотя бы в одной цифре, этот ИНН может улететь в другие системы, включая государственные. А дальше начинается квест. Пользователь приходит и говорит: «Ой, знаете, я там одну циферку перепутал, давайте поменяем». А мы понимаем, что этот «битый» ИНН уже где-то в налоговой, где-то в бухгалтерии, где-то в стороннем сервисе (ведь там есть валидация, правда же?). И исправить это всё задним числом — очень сложно.

Вот поэтому строгая валидация — это не перфекционизм. Это защита от будущих проблем. Да, иногда можно ограничиться проверкой «строка не пустая». Но если речь идёт о данных, которые реально живут в предметной области и пересекают границы разных систем, здесь без жёстких правил никак.

🔥17💯8👍4❤1

www.tgoop.com/stringconcat/353

2.42K viewsЕвгений, Sep 2 at 10:45

В комментах к прошлому посту справедливо спросили: а зачем вообще такая строгая валидация? Хороший вопрос. Давайте разберёмся.

Первый сценарий — когда нам нужно просто что-то отобразить. В этом случае можно обойтись минимальными проверками. Условно, проверили, что поле не пустое — и хватит. Тут и правда нет смысла городить сложные правила, мы скорее переживаем за то, чтобы верстка не поехала.

Второй сценарий — когда объект реально участвует в предметной области. И вот тут начинаются настоящие приключения.

Например, числовые значения. Их желательно приводить к конкретной точности. Иначе арифметика начинает жить своей жизнью: где-то округлили слишком рано, где-то потеряли пару копеек — и всё, отчёт уже не сходится. Сначала ошибка на пару рублей, потом на пару сотен тысяч, и внезапно прибыль компании уже не прибыль.

Другой пример — ИНН. Если пользователь ошибся хотя бы в одной цифре, этот ИНН может улететь в другие системы, включая государственные. А дальше начинается квест. Пользователь приходит и говорит: «Ой, знаете, я там одну циферку перепутал, давайте поменяем». А мы понимаем, что этот «битый» ИНН уже где-то в налоговой, где-то в бухгалтерии, где-то в стороннем сервисе (ведь там есть валидация, правда же?). И исправить это всё задним числом — очень сложно.

Вот поэтому строгая валидация — это не перфекционизм. Это защита от будущих проблем. Да, иногда можно ограничиться проверкой «строка не пустая». Но если речь идёт о данных, которые реально живут в предметной области и пересекают границы разных систем, здесь без жёстких правил никак.

BY StringConcat - разработка без боли и сожалений