Комментарии 10
Ценность примитивных типов - в простой сериализации. Есть вариант не городить обёрточные классы, а просто покрыть код юнит-тестами нормально. Тогда и перепутать process(userId, itemId) с process(itemId, userId) не получится. Тестами вообще многие пробелы в типизации закрыть можно.
В некоторых языках новые типы тоже не плохо это делают "из коробки" (ну или путем не сложных манипуляций). Тесты – это хорошо, но в данном случае немного поздно. Вместо того чтобы получить ошибку при компиляции (или в среде разработки при вводе) переносить определение настолько простой ошибки на тестирование мне кажется несколько чрезмерно.
Есть вариант не городить 100500 юнит-тестов для тривиальных проверок, а использовать систему типов, чтобы она облегчала нам жизнь. Эти 100500 тестов ещё и поддерживать потом надо.
Типизацией вообще многие виды простых тестов закрыть можно.
Как можно такое вообще перепутать? Даже если в процессе набора аннотация не показывается, то что мешает go to definition сделать, две секунды.
Согласен с тем, что типизация очень хорошо решает такие проблемы. Даже кажется грехом не использовать типизацию для этого.
Особенно учитывая, что есть mapstruct и Jackson, которые, если нужно умеют разворачивать вложенные объекты.
username.value -> username
time.Duration из Go крайне неудачный пример типизации, потому что позволяет time.Sleep(time.Hour * time.Hour)
В тэги и/или перед первым примером кода нужно добавить язык примеров.
Спасибо! Здесь разные примеры кода на разных языках. Смена языка без предупреждения, действительно, может сбивать с толку. Добавил в текст перед рассмотрением примеров язык, когда он меняется. В тэги добавлять, думаю, не стоит, т.к. статья больше не про сами языки, а про подходы, которые в различных языках существуют.
За всю карьеру ни разу не встретил реального случая с перепутанными входными параметрами. Потому что IDE великолепно показывают порядок и ошибиться сложно. Даже если ошибся, код не отдается тестерам без проверки, а при дебаге или даже поверхностном просмотре сразу видно несоответствие. Я даже не говорю про юнит тесты, которые исключают подобные проблемы совсем. ИМХО проблема была описана когда код писали без IDE и любили передавать по 20 параметров. А потом стала не актуальной. Передавать всегда нужно так, чтобы код был простым и очевидным, чтобы работа не превращалась в героическое преодоление надуманных проблем. Это важнее чем страховка от очень очевидных и очень маловероятных ошибок.
Антипаттерн Primitive obsession: практические способы устранения