Shub
из-за приватного конструктора DU
Shub
для рекордов будет еще интереснее - ты будешь копировать все поля в свой самодельный конструктор с упорством обреченного
Roman
Value ты вынужден создать, потому что у тебя паттерн матчинг отвалился
Большая проблема? Можно активный паттерн написать
Roman
для рекордов будет еще интереснее - ты будешь копировать все поля в свой самодельный конструктор с упорством обреченного
Я уже там писал, что приватный рекорд не имеет смысла
Roman
то есть, если у меня будет 15 правил валидации - они все будут в доморощенном конструкторе?
Если они все относятся к валидации номера карты - да. В чем проблема?
Shub
Большая проблема? Можно активный паттерн написать
большая. ты вынужден писать тонны бойлерплейта. а мог бы не писать
Shub
тебе надо написать Value, тебе надо сообщить всем, что вместо прямого матчинга нужно использовать Value, ты должен написать конструирующий метод
Shub
чего ради, собственно?
Roman
Shub
что он сообщит? что Роман решил использовать конвенцию называть завернутый тип Value?
Roman
чего ради, собственно?
Чтобы гарантировать, что валидация не будет пропущена. Как ты по-другому это сделаешь?
Roman
что он сообщит? что Роман решил использовать конвенцию называть завернутый тип Value?
Если выставить Ап, то снаружи вообще разницы не будет видно
Vladislav
Чтобы гарантировать, что валидация не будет пропущена. Как ты по-другому это сделаешь?
тут вопрос надо ли это гарантировать
Roman
тут вопрос надо ли это гарантировать
Обычно все кричат, что надо, и пытаются добиться этого тестами. Бойлерплейта получается больше, поддержка тяжелее
Doge
тут вопрос надо ли это гарантировать
Смотря насколько это сложные правила и насколько с ними разумно работает инфраструктура.
Тот же refined в одном проекте мне очень успешно удалось применить, при этом получить читаемое описание в коде одного формата данных со всеми его ограничениями
Doge
А вот в проекте с более сложным данными стало понятно, что геммороя уже будет больше чем пользы и проще валидировать по старинке
Doge
Имхо, если эти правила разрастаются на десятки случаев, то это уже полноценный кусок бизнес логики, которых заслуживает выделения себя в какой-то отдельный модуль/сервис и т.п.
Фил Ранжин
с какого момента начинается переусложнение?
Фил Ранжин
если у меня есть метод, который может работать только с положительными числами - объявить его параметр как uint - переусложнение?
Фил Ранжин
я не про удобство
Фил Ранжин
удобно на жс писать
Фил Ранжин
я про защищённость
Фил Ранжин
вот этот мой финт с LessThan<100> - переусложнение?
Vasily
Ну т.е. как игра ума ок
Vasily
Но реальной пользы нет
Фил Ранжин
окей. А как делать?
Фил Ранжин
есть метод, для которого параметр, который больше сотни - невалидный
Фил Ранжин
твои действия?
Vasily
Для начала определимся со стеком
Фил Ранжин
любой
Фил Ранжин
давай F#
Vasily
Далее, что значит невалидный?
Vasily
Что я должен делать, если такой параметр пришел?
Фил Ранжин
а вот сам и думай, ты же метод проектируешь
Фил Ранжин
допустим у тебя фаерНфогет запускатор каких-нибудь сервисов
Фил Ранжин
где параметр - количество
Vasily
Воткну if внутрь метода, посру в логи
Фил Ранжин
твой запускатр сервисов дергают внутри других ифов в клиентском коде, впервые невалидное значение попало туда на проде, сервисы не запустились и человечество вымерло
Фил Ранжин
(ну или цены на носки некорректные в интернет магазине - смотря кто либу решил юзать)
Vasily
Ты же понимаешь, что пример из пальца высосан?
Vasily
Что проблема не в ограничении набора входных параметров
Фил Ранжин
ну слушай, я на работе код не пишу, откуда у меня нормальные примеры возьмутся?
Фил Ранжин
Что проблема не в ограничении набора входных параметров
но в них тоже, и это ты можешь предотвратить
Фил Ранжин
я если что не спорю - я точно знаю, что ты прав. Но сформулировать не могу
Vasily
Для таких вещей проще использовать fallback value
Фил Ранжин
грубо говоря, вот фундаментальный вопрос - если я могу гарантировать, что определенной доли ошибок не случится, заплатив за это читаемостью, почему мне не стоит это делать?
Фил Ранжин
резалт пулять?
Фил Ранжин
Vasily
Фил Ранжин
например?
Vasily
Тут вопрос управления сложностью
Фил Ранжин
Нет, просто подставлять дефолтное и срать в логи/кафку/ватэвер
а если дефолтное в клиентском коде недопустимо?
Vasily
Например, ты убрал ошибку, которая возникает в 0.1% случаев
Фил Ранжин
видишь, пидоры могут не прочитать доку метода, но мой тип им с радостью надаёт по щам, и они блядь поймут, что нужно проверить значение
Vasily
видишь, пидоры могут не прочитать доку метода, но мой тип им с радостью надаёт по щам, и они блядь поймут, что нужно проверить значение
Ну с той же вероятностью можно кинуть ошибку
Фил Ранжин
ну ты пилишь библиотечный код - ты понятия не имеешь, как где и зачем он будет использоваться
Vasily
Точнее с тем же результатом
Vasily
Вот тут я советую определиться
Фил Ранжин
я когда первый раз писал код на тс - дико бомбил, что он ругает за отсутствие проверки на нулл
Vasily
Если ты написал хуевый код, это не проблема тех, кто его использует
Фил Ранжин
я когда первый раз писал код на тс - дико бомбил, что он ругает за отсутствие проверки на нулл
тоже думал - переусложнение
Vasily
Особенно, если методы настолько хрупкие
Фил Ранжин
подход с возвращением option/result - тоже переусложнение
Фил Ранжин
но он гарантирующий, по сравнению с трайкетчами
Vasily
Нихуя он не гарантирует
Vasily
Он гарантирует только джоб секьюрити
Фил Ранжин
ну да
Фил Ранжин
а ексепшны вообще ничего не гарантируют
Vasily
Ну и все тебя будут считать типа умным
Vasily
Гарантий нет вообще
Vasily
Единственная гарантия