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

Doc>Помогают. Но при этом, чем больше самого кода — тем больше вероятность ошибки.
Кэп, ты? Больше то оно больше, только в одном случае ошибку можно сделать в одном, очевидном, месте, а в другом в куче месте.

Doc>Причем тут запихаем все в один? Но при этом же не надо плодить сущностей сверх меры. Понятно что у каждого она своя. Однако, создавать класс на каждый чих BL (там где вполне подходят стандартные), это перебор.

А причем тут 100500, которые ты выдумал? Откуда взялась какая-то мера? Как ты определяешь где перебор, а где нет? Типа в проекте уже слишком много классов будет пихать в существующие?

Doc>Определись, ты хочешь менять возраст или нет. )
18 это константа у тебя в тексте. Причем тут хочу я менять или нет? У меня логика проверки в одном месте у тебя во всех методах с контрактом.

Doc>Угу. Т.е. exception из контракта это ой ужас, а из конструктора — это прям прелесть
Ужас. Но там заведомо известно, что он не случиться.

Doc>Т.е. как я сказал вместо 1 строки с float(или int), в месте которое хорошо покрывается тестами, ты делаешь уже Age, Adult<Age>, фабричный метод в статик классе, ну и общие Either и Error. Добавь тесты на все это добро.

Фраза "хорошо покрывается тестами" ужасно смешная. Она покрывается тестами так как программисту кажется достаточным его покрыть, что, собственно, не гарантирует ничего, а в отличии от типов. Если весь метод MakeAdult состоит из одной проверки, то тесты там вообще не нужны. И кстати какие еще фабричные методы? Зачем они?

Doc>Но главное, ты опять путаешь BL и контракты. Давай на примере покажу
Doc>Допустим у нас есть закрытая область (раз уж взяли это Age). Посмотрим на 2 метода
Doc>1) Login(User user). Тут просто обычная проверка user.Age и возврат кода. У этого метода не может быть в контракте 18 < user.Age, т.к. попытаться залогиниться у нас может любой юзер. Если что — вернем Error, HttpStatusCode.Forbidden или что еще там надо
Doc>2) GetShopContent(..., User user). А вот тут уже контракт что user обязан быть старше 18. И если сюда как-то попал младше, то как я сказал явно проблема в реализации BL. Поэтому кидаем исключение и ловим его на самом верху, программу закрываем, т.к. дальше уже работать нет по сути смысла.

Ты так и не понял о чем я говорю. Да, у тебя проблема в реализации BL, так как не может быть никакого User в GetShopContent с возрастом меньше 18, так как тип должен быть Adult<User> или Validated<User>. И в отличии от "проблема, исключение, креш, недовольный юзер" — это просто не может сломаться.
Контракты это способ искать где ты сломал логику, а типы это способ ее не ломать.

Doc>Как я уже сказал, ловим такое на самом верху, сохраняем/отправляем что надо для дебага, завершаем работу.
Ну т.е. в случайном месте прервалось выполнения, поэтому просто свалились. Так оно и происходит, я не понимаю почему ты это описываешь как что-то хорошее?

Doc>>>Далее, в метод, где не может быть возраст меньше заданного пролез такой возраст.
PJ>>Что значит "пролез"? Как он туда может пролезть?

Doc>Вот именно. См чуть выше пункт (2).
Что вот именно? Это был вопрос? Как возраст меньше 18 может пролез в Adult<Age> чисто технически?

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

Doc>Помогают. Но при этом, чем больше самого кода — тем больше вероятность ошибки.
Кэп, ты? Больше то оно больше, только в одном случае ошибку можно сделать в одном, очевидном, месте, а в другом в куче мест.

Doc>Причем тут запихаем все в один? Но при этом же не надо плодить сущностей сверх меры. Понятно что у каждого она своя. Однако, создавать класс на каждый чих BL (там где вполне подходят стандартные), это перебор.

А причем тут 100500, которые ты выдумал? Откуда взялась какая-то мера? Как ты определяешь где перебор, а где нет? Типа в проекте уже слишком много классов будет пихать в существующие?

Doc>Определись, ты хочешь менять возраст или нет. )
18 это константа у тебя в тексте. Причем тут хочу я менять или нет? У меня логика проверки в одном месте у тебя во всех методах с контрактом.

Doc>Угу. Т.е. exception из контракта это ой ужас, а из конструктора — это прям прелесть
Ужас. Но там заведомо известно, что он не случиться.

Doc>Т.е. как я сказал вместо 1 строки с float(или int), в месте которое хорошо покрывается тестами, ты делаешь уже Age, Adult<Age>, фабричный метод в статик классе, ну и общие Either и Error. Добавь тесты на все это добро.

Фраза "хорошо покрывается тестами" ужасно смешная. Она покрывается тестами так как программисту кажется достаточным его покрыть, что, собственно, не гарантирует ничего, а в отличии от типов. Если весь метод MakeAdult состоит из одной проверки, то тесты там вообще не нужны. И кстати какие еще фабричные методы? Зачем они?

Doc>Но главное, ты опять путаешь BL и контракты. Давай на примере покажу
Doc>Допустим у нас есть закрытая область (раз уж взяли это Age). Посмотрим на 2 метода
Doc>1) Login(User user). Тут просто обычная проверка user.Age и возврат кода. У этого метода не может быть в контракте 18 < user.Age, т.к. попытаться залогиниться у нас может любой юзер. Если что — вернем Error, HttpStatusCode.Forbidden или что еще там надо
Doc>2) GetShopContent(..., User user). А вот тут уже контракт что user обязан быть старше 18. И если сюда как-то попал младше, то как я сказал явно проблема в реализации BL. Поэтому кидаем исключение и ловим его на самом верху, программу закрываем, т.к. дальше уже работать нет по сути смысла.

Ты так и не понял о чем я говорю. Да, у тебя проблема в реализации BL, так как не может быть никакого User в GetShopContent с возрастом меньше 18, так как тип должен быть Adult<User> или Validated<User>. И в отличии от "проблема, исключение, креш, недовольный юзер" — это просто не может сломаться.
Контракты это способ искать где ты сломал логику, а типы это способ ее не ломать.

Doc>Как я уже сказал, ловим такое на самом верху, сохраняем/отправляем что надо для дебага, завершаем работу.
Ну т.е. в случайном месте прервалось выполнения, поэтому просто свалились. Так оно и происходит, я не понимаю почему ты это описываешь как что-то хорошее?

Doc>>>Далее, в метод, где не может быть возраст меньше заданного пролез такой возраст.
PJ>>Что значит "пролез"? Как он туда может пролезть?

Doc>Вот именно. См чуть выше пункт (2).
Что вот именно? Это был вопрос? Как возраст меньше 18 может пролезть в Adult<Age>, чисто технически?