Здравствуйте, Poopy Joe, Вы писали:
Doc>>С чего это? Интерфейс (метод) диктует условия, условия в нем. Все логично. PJ>С того что это нарушает Single Responsibility Principle. Тут используем возраст, а тут его же и декларируем и проверем, и прочее.
А с чего ты взял что это разные ответственности?
PJ>Метод принимает не сферический Validated<User>, а тот кторый его удовлетворяет. Да имя не удачно, было выбрано только чтобы показать, что нет привязки к одному полю. Но сколько это можно пережевывать-то?
А кто говорил: >>> Либо вообще просто изменю тип Validated<User> добавив в него какие угодно ограничения.
Ты определись тогда — или Validated с кучей проверок или по 1 классу на каждый набор условий.
Doc>>Как только набираются разные условия, то или плоди по классу на условие и создавай кучу кода ну или как ты предложил ValidatedUser и нафиг все проверки :D PJ>Ни то, ни другое. По классу на "контракт".
А, все же каждая проверка — отдельный класс. Все тогда все понятно что это даст кучу дополнительного кода на ровном месте.
Doc>>А что помешает потом поменять логику в одном так, что все поломается? PJ>А что помешает написать неверный контракт? Да ничего.
Еще раз — контракт находится при методе для которого он нужен. Твой класс c проверкой — связан как я понимаю с несколькими другими классами.
Doc>>У тебя некрасивая манера общения — придумывать за оппонента. Поведение не строиться на исключениях. Исключения это как раз исключительная ситуация. PJ>Конечно строится. Ты заведомо планируешь, что программа может упасть, потому что в данных окажется мусор.
Не путай поведение по BL с обработкой исключительный ситуаций.
Doc>>Кроме того, ты специально игнорируешь мои слова что после исключения приложение завершает работу. PJ>И? Это самый худший случай. О чем ты тут хочешь поговорить?
Опять вырываешь из контекста.
Doc>>Забыли обновить контракт? Обновление контракта вообще исключительная ситуация. Ты точно путаешь BL и контракты. PJ>Да ну прям. Ты точно путаешь контракты и священные тексты. Контракты могут меняться при первом же рефакторинге.
Нет не путаю. Хотя верю что, учитывая число классов и кучу взаимосвязей — рефакторинг у тебя дело наверное еженежельное :D
Doc>>Вот и поглядим как выглядит твой подход. Я тоже самое на контрактах. Doc>>Согласен?
PJ>Пиши
Ты называешь linq запрос методом? Я просил показать класс с 5 методами, которые ожидают соответствующие параметры.
Ну хоть одно из твоего кода ясно, у тебя каждая проверка — отдельный класс. Т.к. как я и говорил до этого, у тебя будут что-то вроде FemaleWithMinHeightAndMaxWeightAndBlondHair
Что породит кучу кода как я и говорил.
Здравствуйте, Doc, Вы писали:
Doc>А с чего ты взял что это разные ответственности?
С того, что контракт выставляют на внешние сущности.
Doc>А кто говорил: >>>> Либо вообще просто изменю тип Validated<User> добавив в него какие угодно ограничения.
ДЛЯ ДАННОГО МЕТОДА. У тебя похоже аргументов, кроме как прицепится к словам не осталось.
Doc>Ты определись тогда — или Validated с кучей проверок или по 1 классу на каждый набор условий.
У меня это в явном виде написано буквально парой строк ниже.
Doc>А, все же каждая проверка — отдельный класс. Все тогда все понятно что это даст кучу дополнительного кода на ровном месте.
А, ну понятно. Экономим классы, но тратим время на отладку. Ну, удачи.
Doc>Еще раз — контракт находится при методе для которого он нужен. Твой класс c проверкой — связан как я понимаю с несколькими другими классами.
Контракт находится в месте где происходит потребление, только и всего. Это самое последнее место, дальше уже просто некуда откладывать. Это самое неудачное место куда его можно поставить, так как уже слишком поздно пить боржоми.
Doc>Не путай поведение по BL с обработкой исключительный ситуаций.
Если у тебя прошел в данных мусор, то вот такая у тебя BL.
Doc>Опять вырываешь из контекста.
Где? В твое контексте уронить программу это нормально.
Doc>Нет не путаю. Хотя верю что, учитывая число классов и кучу взаимосвязей — рефакторинг у тебя дело наверное еженежельное :D
Путаешь. Не, ну их конечно можно не менять, но тогда они просто вообще будет работать хаотически.
Конечно еженедельное, я могу менять код как хочу, так как компилятор мой помощник. А вот с контрактами код будет страшно трогать, чтобы все не посыпалось.
Doc>Ты называешь linq запрос методом? Я просил показать класс с 5 методами, которые ожидают соответствующие параметры.
У тебя проблемы с чтением кода?
Doc>Ну хоть одно из твоего кода ясно, у тебя каждая проверка — отдельный класс. Т.к. как я и говорил до этого, у тебя будут что-то вроде FemaleWithMinHeightAndMaxWeightAndBlondHair Doc>Что породит кучу кода как я и говорил.
Пока ясно, что ты ничего не написал, с чем можно сравнивать, ни привел ни одного корректного возражения.
S>Кэп: в том, что большинство проверок имеет смысл внутри одного-двух конкретных методов, а данные надо протаскивать по всему коду.
Твое утверждение совершенно высосано из пальца.
S>Т.е. на вход тебе приходит person, и твой каст к Adult<Person> с костылями в виде HasValue() от стандартңого BL.AssertIsAdult(person) отличается только количеством приседаний на ровном месте.
S>>>При этом по факту граница ещё более размыта. Получение определённых прав помимо возраста может зависеть от точности gps (Швейцария, в соседних кантонах разные правила продажи S>Кэп #2: будут гарантировать соблюдение всех предусловий значительно меньшими силами? Точнее даже не будут, а гарантируют, т.к. я всю эту радость на практике использую, а не теоретизирую
Не будет. Контракты вообще ничего не гарантируют, кроме того, что могут свалится в самом неожиданном месте. Ты тут пытаешься авторитетом задавить? Я тоже пробовал использовать, по результатам опыта — выкинул нафиг, как бесполезную ерунду.
S>Открываем 400-ФЗ и читаем :P
Т.е. контракты закончили и перешли к бухгалтерии? Что это вообще было?
S>И да, автоматизация расчёта подобных штук _очень_ нуждается в проверке кода всеми возможными средствами, от тестов и до ассертов/контрактов. Если подход с типами на таких масштабах сливается — имеет ли смысл его использовать на чём-то меньшем?
Ты сейчас возражаешь своему внутреннему голосу, потому что не озвучил проблему.
Здравствуйте, Poopy Joe, Вы писали:
Doc>>А с чего ты взял что это разные ответственности? PJ>С того, что контракт выставляют на внешние сущности.
Ну-ну. Контракт выставляется на параметры метода, а не на сущность.
Т.е. внутри метода выставление его же требований это чужая ответственность?
Просто для интереса — ты когда контракт на работу кто-то заключает, то выставление требований это его дело или обязанность кто-то со стороны. :D
PJ>ДЛЯ ДАННОГО МЕТОДА. У тебя похоже аргументов, кроме как прицепится к словам не осталось.
Как ты объясняешь, так и говорю. Тебе был вопрос "будешь писать по классу на каждое условие", ты сказал "напишу ValidatedUser с любыми условиями".
Doc>>А, все же каждая проверка — отдельный класс. Все тогда все понятно что это даст кучу дополнительного кода на ровном месте. PJ>А, ну понятно. Экономим классы, но тратим время на отладку. Ну, удачи.
С чего? То что делают куча твоих классов прекрасно делают контракты в несколько строк.
PJ>Контракт находится в месте где происходит потребление, только и всего. Это самое последнее место, дальше уже просто некуда откладывать. Это самое неудачное место куда его можно поставить, так как уже слишком поздно пить боржоми.
Еще раз "нарушение контракта — исключительная ситуация". Ее не должно быть в принципе. Это не средство управления, а средство как раз отладки и контроля.
Т.е. если у нас метод для логина пользователей только с подтверждённым email, то проверка наличия подтвержденного email это просто проверка, а не контракт.
Doc>>Не путай поведение по BL с обработкой исключительный ситуаций. PJ>Если у тебя прошел в данных мусор, то вот такая у тебя BL.
Ну я так понимаю сэр пишет вообще без багов. И его код используют разработчики которые пишут тоже всегда без багов. Ну только удивиться остается. :D
Doc>>Опять вырываешь из контекста. PJ>Где? В твое контексте уронить программу это нормально.
Это не нормально.
PJ>Конечно еженедельное, я могу менять код как хочу, так как компилятор мой помощник. А вот с контрактами код будет страшно трогать, чтобы все не посыпалось.
Еженедельный рефакторниг? :D Да, высокое качество кода без единого бага :D:D:D:D:D
Doc>>Ты называешь linq запрос методом? Я просил показать класс с 5 методами, которые ожидают соответствующие параметры. PJ>У тебя проблемы с чтением кода?
Твоего — видимо да. Покажи. Не вызовы, а твои методы.
PJ>Пока ясно, что ты ничего не написал, с чем можно сравнивать, ни привел ни одного корректного возражения.
Как только покажешь где у тебя те самые 5 твоих методов легко. Пока сравнивать не с чем.
Здравствуйте, Doc, Вы писали:
Doc>Ну-ну. Контракт выставляется на параметры метода, а не на сущность. Doc>Т.е. внутри метода выставление его же требований это чужая ответственность?
Он выставляется на те сущности которые не контролирует сам. В этом весь смысл.
Doc>Как ты объясняешь, так и говорю. Тебе был вопрос "будешь писать по классу на каждое условие", ты сказал "напишу ValidatedUser с любыми условиями".
Даже если было недопонимание, то я разжевал уже 10 раз, но ты продолжаешь свое. Видимо по делу возразить нечего.
Doc>С чего? То что делают куча твоих классов прекрасно делают контракты в несколько строк.
То-то ты их стесняешься привести. А такой был размах...
Doc>Еще раз "нарушение контракта — исключительная ситуация". Ее не должно быть в принципе. Это не средство управления, а средство как раз отладки и контроля. Doc>Т.е. если у нас метод для логина пользователей только с подтверждённым email, то проверка наличия подтвержденного email это просто проверка, а не контракт.
Если ее не должно быть в принципе, то зачем контракт? У меня вот ее не должно быть в принципе и ее в принципе и не будет.
Doc>Ну я так понимаю сэр пишет вообще без багов. И его код используют разработчики которые пишут тоже всегда без багов. Ну только удивиться остается. :D
Я так понимаю сэр перешел на передергивания?
Doc>Это не нормально.
У тебя нормально. Контракт ровно это и делает — роняет программу.
Doc>Еженедельный рефакторниг? :D Да, высокое качество кода без единого бага :D:D:D:D:D
Да хоть ежедневный. Я не боюсь менять код, ничего не развалится, как с контрактами.
Doc>Как только покажешь где у тебя те самые 5 твоих методов легко. Пока сравнивать не с чем.
Если ты не можешь читать код, то о чем вообще разговор? И это даже не код, а просто сигнатуры.
Здравствуйте, Poopy Joe, Вы писали:
S>>Кэп: в том, что большинство проверок имеет смысл внутри одного-двух конкретных методов, а данные надо протаскивать по всему коду. PJ>Твое утверждение совершенно высосано из пальца.
С чего бы это?
Возьмём самую простейшую штуковину: вендинговый автомат. Точнее сеть автоматов. С пивом-орешками-сигаретами-ещё чем.
На каждый из товаров есть свои ограничения по продаже, для простоты снова ограничимся пивом.
Опять-таки для полного счастья считаем, что все предусловия: возраст покупателя + местные законы + время суток известны. На входе у тебя Order с списком товаров + Customer + время-координаты от gps (автоматы часто возят по выставкам из штата в штат). На выходе — простой флаг: можно ли выдать заказ покупателю.
И, допустим, в одном кантоне пиво можно продать любому оболтусу, _но_ если автомат находится не в радиусе 500 м от школы/детского сада.
В другом — с 16 лет _или_ при наличии родителей (предлагает провести вторую карту), в третьем — только с 10 до 22-00 и только совершеннолетним. В четвёртых, часть марок предлагается только при заказе в комплекте с двумя пачками жвачки (одна из сетей проводит рекламную кампанию), в пятых — есть ещё и безалкогольное пиво, которое должно обрабатываться как пиво, ибо в зависимости от места продажи является подакцизным товаром.
Вперёд, можешь сам прикинуть трудоёмкость представления этой радости в виде системы типов. Напомню, проверяется на валидность не отдельный товар, а заказ в целом, т.к. промежуточное состояние вполне может быть невалидным.
С учётом того, что групп товаров — сотни (разные сети загружают разные товары), правила меняются динамически (не будешь же из-за очередной кампании перепрошивать все девайсы), а ответственность из-за нарушения правил торговли очень существенна и из-за штрафов и из-за репутации (потому что конкуренты тоже не спят).
А теперь учитываем, что помимо самих автоматов есть склады, логистика, интеграция с ПО поставщиков и тд и тп и вся эта радость по идее должна работать с одними и теми же данными.
Вперёд, попробуй распространить "проверенные" типы на всю систему
Можешь поверить, это далеко не самый сложный из возможных сценариев.
Здравствуйте, Poopy Joe, Вы писали:
PJ>Здравствуйте, Doc, Вы писали:
Doc>>Ну-ну. Контракт выставляется на параметры метода, а не на сущность. Doc>>Т.е. внутри метода выставление его же требований это чужая ответственность? PJ>Он выставляется на те сущности которые не контролирует сам. В этом весь смысл.
Во-первых, параметры метода не всегда сущности.
Во-вторых, контролировать сами сущности — не задача метода. Ему лишь надо данные в определенном состоянии.
Doc>>Ну я так понимаю сэр пишет вообще без багов. И его код используют разработчики которые пишут тоже всегда без багов. Ну только удивиться остается. :D PJ>Я так понимаю сэр перешел на передергивания?
Ни сколько. Ты же предполагаешь что нигде нет ошибок, все работает идеально, что в BL попасть что-то не то в принципе не может (багов то нет).
Doc>>Это не нормально. PJ>У тебя нормально. Контракт ровно это и делает — роняет программу.
Не надоело говорить за меня? Цитируешь одно и тут же утверждаешь обратное.
Doc>>Еженедельный рефакторниг? :D Да, высокое качество кода без единого бага :D:D:D:D:D PJ>Да хоть ежедневный. Я не боюсь менять код, ничего не развалится, как с контрактами.
Если тебе нужен постоянный рефакторниг это говорит о качестве твоего проектирования и кода. И боишься ли ты менять код или нет — тут не причем.
Думаю тут дальше говорить бессмысленно.
Doc>>Как только покажешь где у тебя те самые 5 твоих методов легко. Пока сравнивать не с чем. PJ>Если ты не можешь читать код, то о чем вообще разговор? И это даже не код, а просто сигнатуры.
В общем ты или прикидываешься или ... Я просил показать класс с 5 методами, которые ожидают данные. Ну хотя твой код показал главное — у тебя классы на каждый чих.
Вот тебе пример с контрактами. Обрати внимание, что IsAdult не требует контрактов.
Здравствуйте, Sinix, Вы писали:
S>>>Кэп: в том, что большинство проверок имеет смысл внутри одного-двух конкретных методов, а данные надо протаскивать по всему коду. PJ>>Твое утверждение совершенно высосано из пальца. S>С чего бы это?
С того, что ты взял с потолка утверждение и выдал его за какую-то общеизвестную истину.
S>Возьмём самую простейшую штуковину: вендинговый автомат. Точнее сеть автоматов. С пивом-орешками-сигаретами-ещё чем.
...
S>Опять-таки для полного счастья считаем, что все предусловия: возраст покупателя + местные законы + время суток известны. На входе у тебя Order с списком товаров + Customer + время-координаты от gps (автоматы часто возят по выставкам из штата в штат). На выходе — простой флаг: можно ли выдать заказ покупателю.
Э не, вот сейчас ты пытаешься натянуть сову на глобус и как-бы-ты-делал-на-проверках на систему типов. Мы это отвергаем.
У нас есть тип Order, вот он либо получится, либо нет. Никаких флагов и прочего бреда. В остальном задача прекрасно ложится на композицию типов. По мне так решать ее через проверки и ассерты это будет ад и израиль.
S>Вперёд, можешь сам прикинуть трудоёмкость представления этой радости в виде системы типов. Напомню, проверяется на валидность не отдельный товар, а заказ в целом, т.к. промежуточное состояние вполне может быть невалидным.
Да вообще никаких проблем. Каждое отдельное условие это один тип, что совершенно естественно, так как gps должен заниматься оделенный тип, как бы ты там не писал. Каждый тип имеет функции композиции с зависимыми типами. Если все зависимые типы сочетаются друг с другом на выходе тип Order, если нет, то ошибка, если чего-то не хватает то каррированый объект ожидающий недостающий тип. И то, что ты пытался запугать количеством вариантов тут перестает иметь значение, потому что количество условий для одного типа ограниченно и поддерживается довольно легко.
S>С учётом того, что групп товаров — сотни (разные сети загружают разные товары), правила меняются динамически (не будешь же из-за очередной кампании перепрошивать все девайсы), а ответственность из-за нарушения правил торговли очень существенна и из-за штрафов и из-за репутации (потому что конкуренты тоже не спят).
Именно поэтому я удивлен, что кто-то предлагает использовать ассерты. Этож свихнуться можно такое поддерживать.
S>Можешь поверить, это далеко не самый сложный из возможных сценариев.
И? Он разве выглядит страшным?
Здравствуйте, Doc, Вы писали:
Doc>Во-первых, параметры метода не всегда сущности.
А что это?
Doc>Во-вторых, контролировать сами сущности — не задача метода. Ему лишь надо данные в определенном состоянии.
возраст это не состояние, это именно контроль параметров.
Doc>Ни сколько. Ты же предполагаешь что нигде нет ошибок, все работает идеально, что в BL попасть что-то не то в принципе не может (багов то нет).
Я тебе предложил сломать и передать в метод мусор. Вместо решения ты начал разводить демагогию.
Doc>Если тебе нужен постоянный рефакторниг это говорит о качестве твоего проектирования и кода. И боишься ли ты менять код или нет — тут не причем.
При чем. Если ты боишься менять код, то это говорит о качестве твоего кода, а не то, что он у тебя написан идеально или требования не меняются. Остальное отмазки.
Doc>В общем ты или прикидываешься или ... Я просил показать класс с 5 методами, которые ожидают данные. Ну хотя твой код показал главное — у тебя классы на каждый чих.
Это ты прикидываешься. Я тебе дал полное решение, а ты половину. Ты приведи как ты их будешь использовать, сигнатуры с контрактами я могу представить и без тебя.
Doc>Вот тебе пример с контрактами. Обрати внимание, что IsAdult не требует контрактов.
Это просто отличный пример убогости контрактов.
Doc>
Doc> public class SomeClass
Doc> {
Doc> private readonly int _minAdultAge = 18;
Doc> private readonly int _maxRequiredAge = 40;
Doc> private readonly float _minWeight = 60.0f;
Doc> public bool IsAdult(int age) => _minAdultAge <= age;
Doc> public void DoSomething1(string email, int age)
Doc> {
Doc> Contract.Requires(!string.IsNullOrEmpty(email)); <--- пишем любую чушь, сгодится за email
Doc> Contract.Requires(_minAdultAge < age); <-- _minAge = -220, age = 9 -> контракт даже не пискнет. Возраст как у баобаба? Никаких проблем.
Doc> // ...
Doc> }
Doc> public void DoSomething2(User user)
Doc> {
Doc> Contract.Requires(user != null);
Doc> Contract.Requires(user.Sex == Sex.Male);
Doc> Contract.Requires(user.Age < _minAdultAge); <--- Age может быть меньше ноля
Doc> // ...
Doc> }
Здравствуйте, Poopy Joe, Вы писали:
S>>С чего бы это? PJ>С того, что ты взял с потолка утверждение и выдал его за какую-то общеизвестную истину.
Ну так это трюизм.
Подавляющее большинство контрактов имеет отношение только к конкретному методу.
Например, путь к файлу == null недопустим для сохранения документа, но обязателен для только что созданного. Для всего остального кода это ограничение не несёт никакого смысла.
Зато у них есть другие ограничения, которые имеют смысл тоже в ограниченном контексте.
Создавать по типу на каждый подобный метод — это полная и очевидная дурь. Пытаться выразить через систему типов все возможные состояния — дурь ещё большая из-за комбинаторного взрыва. Добавляем сюда неизбежную динамическую типизацию (спрятанную за OfType()/optional) и получаем те же ассерты, только в максимально извращённом виде.
Я серьёзно не вижу, как такой подход может масштабироваться дальше одного метода. Только не надо ссылаться на код из примера с возрастом — он вообще-то работать не будет.
var children = persons.Select(UnderAge<Person>.Create)
.Where(p => p.HasValue()).Select(p => p.Value)
.ToArray();
var q2 = children
.OfType<UnderAge<Male>>()
.Select(PlayWith)
.ToArray();
UnderAge<Person> не кастится к UnderAge<Male>.
PJ>У нас есть тип Order, вот он либо получится, либо нет. Никаких флагов и прочего бреда. В остальном задача прекрасно ложится на композицию типов. По мне так решать ее через проверки и ассерты это будет ад и израиль.
В том-то и проблема, что этот "валидный ордер" валидный в контексте ровно одной операции — получение заказа. Для оплаты, заказа предварительной доставки или оформления подарка тот же самый ордер может быть валиден. Что, будем городить свой тип для каждой операции?
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Poopy Joe, Вы писали:
S>Ну так это трюизм.
Не, всего лишь высосанное из пальца утверждение.
S>Подавляющее большинство контрактов имеет отношение только к конкретному методу. S>Например, путь к файлу == null недопустим для сохранения документа, но обязателен для только что созданного. Для всего остального кода это ограничение не несёт никакого смысла. S>Зато у них есть другие ограничения, которые имеют смысл тоже в ограниченном контексте.
Ты хоть пример давай. А то, в очередной раз, выдаешь какое-то утверждение с которым никто и не спорил. Ну не имеет, и что?
S>Создавать по типу на каждый подобный метод — это полная и очевидная дурь. Пытаться выразить через систему типов все возможные состояния — дурь ещё большая из-за комбинаторного взрыва. Добавляем сюда неизбежную динамическую типизацию (спрятанную за OfType()/optional) и получаем те же ассерты, только в максимально извращённом виде.
По какому такому типу? Типу Nullable? Ага, так не нужен, что аж в во фреймворк ввели. Хотя лучше бы ввели Optional и Either. Лучи поноса им за это.
Никакой динамической типизации в примере нет.
S>Я серьёзно не вижу, как такой подход может масштабироваться дальше одного метода. Только не надо ссылаться на код из примера с возрастом — он вообще-то работать не будет.
Этот подход прекрасно работает в функциональных языках, на нем практически все и построено. Ты серьезно не видишь как работают функциональные языки? Ну, это, при желании, поправимо и точно не проблема подхода.
S>UnderAge<Person> не кастится к UnderAge<Male>.
Кастится, если добавить оператор, либо сделать это в явном виде еще одним селектом. Вообще ни на что ни влияет. Что ты этим хотел сказать?
S>В том-то и проблема, что этот "валидный ордер" валидный в контексте ровно одной операции — получение заказа. Для оплаты, заказа предварительной доставки или оформления подарка тот же самый ордер может быть валиден. Что, будем городить свой тип для каждой операции?
Что значит "городить"? У тебя тоже фобия "лишнего типа"? А зачем "городить" классы вообще? Запихать все в один метод и наставить ассертов.
Здравствуйте, Poopy Joe, Вы писали:
Doc>>Во-первых, параметры метода не всегда сущности. PJ>А что это?
Значения, данные... в принципе называй как хочешь. Если методу из всего User нужны только, скажем, пол и возраст, то передавать весь User только вредит. Достаточно два значения.
Doc>>Ни сколько. Ты же предполагаешь что нигде нет ошибок, все работает идеально, что в BL попасть что-то не то в принципе не может (багов то нет). PJ>Я тебе предложил сломать и передать в метод мусор. Вместо решения ты начал разводить демагогию.
Угу, это все равно что предложить сломать Hello World. Попытка хорошая, но все равно не зачет.
Doc>>Если тебе нужен постоянный рефакторниг это говорит о качестве твоего проектирования и кода. И боишься ли ты менять код или нет — тут не причем. PJ>При чем. Если ты боишься менять код, то это говорит о качестве твоего кода, а не то, что он у тебя написан идеально или требования не меняются. Остальное отмазки.
Не уходи в сторону. Еженедельный рефакторинг это именно о качестве кода.
PJ>Это просто отличный пример убогости контрактов.
Нет, это твои примеры как раз показатель того, что до самих контрактов у тебя не вышло доколупаться. Кстати, мой код хотя бы скомпилируется
Doc>> Contract.Requires(!string.IsNullOrEmpty(email)); <--- пишем любую чушь, сгодится за email
Придраться к контрактам не вышло, и ты пристал к методу IsNullOrEmpty. Нет проблем — напиши IsValidEmail и поставь тут.
Задача была показать пример контрактов.
Doc>> Contract.Requires(_minAdultAge < age); <-- _minAge = -220, age = 9 -> контракт даже не пискнет. Возраст как у баобаба? Никаких проблем.
Ну да, а если сделать класс, то проверка на min сама волшебным образом появится.
Ты вообще в своем примере не показал проверки.
PJ>Ну и так далее.
В общем претензий к контрактам у тебя нет. Ты просто доколупался до проверок в примере.
Здравствуйте, Doc, Вы писали:
Doc>В общем ты или прикидываешься или ... Я просил показать класс с 5 методами, которые ожидают данные. Ну хотя твой код показал главное — у тебя классы на каждый чих. Doc>Вот тебе пример с контрактами. Обрати внимание, что IsAdult не требует контрактов.
Безотносительно всей дискуссии. Мне так кажется, что на IsAdult точно должен быть контракт. Потому как предусловие есть — возраст не может/не должен быть меньше 0 — это явно неправильные данные и метод невалидно с ними работает.
Здравствуйте, Andir, Вы писали:
A>Безотносительно всей дискуссии. Мне так кажется, что на IsAdult точно должен быть контракт. Потому как предусловие есть — возраст не может/не должен быть меньше 0 — это явно неправильные данные и метод невалидно с ними работает.
Ну я подразумевал что вернется bool (т.е. true — взрослый). Как я сталкивался, то обычно так себя ведут методы и свойства Is<Что-то>, возвращая true если условие "что-то" выполняется.
Здравствуйте, Doc, Вы писали:
Doc>Здравствуйте, Poopy Joe, Вы писали:
Doc>Значения, данные... в принципе называй как хочешь. Если методу из всего User нужны только, скажем, пол и возраст, то передавать весь User только вредит. Достаточно два значения.
Хм... И пол, и возраст это сущности. Я зачем ты сказал остальное я так и не понял.
Doc>Угу, это все равно что предложить сломать Hello World. Попытка хорошая, но все равно не зачет.
Ну у тебя и того меньше, одна я показал где у тебя могут быть ошибки.
Doc>Не уходи в сторону. Еженедельный рефакторинг это именно о качестве кода.
Нет, не говорит. А вот его боязнь говорит. Может голосование запустить.
Doc>Нет, это твои примеры как раз показатель того, что до самих контрактов у тебя не вышло доколупаться. Кстати, мой код хотя бы скомпилируется Вот именно этот факт и говорит об убогости контрактов.
Если у меня ошибка, то я просто не могу скомпилироваться, если у тебя ошибка может случится все что угодно.
Doc>Придраться к контрактам не вышло, и ты пристал к методу IsNullOrEmpty. Нет проблем — напиши IsValidEmail и поставь тут.
Чо? Все обсуждение вокруг этого и идет. Что у тебя проверки хаотические и размазаны по всему коду, а их валидность зачастую сомнительна. Может ты о чем-то своем говорил, но лично я вот о таком.
Doc>Задача была показать пример контрактов.
С их использованием. Одно без другого совершенно нелепо и ничего не показывает. Так что закончи.
Doc>Ну да, а если сделать класс, то проверка на min сама волшебным образом появится. Doc>Ты вообще в своем примере не показал проверки.
Потому что у меня есть тип, и делается все там. У тебя все делается в разных местах, никак не связанных.
Написать вторую половину коды ты вообще не осилил, а так хаоса добавится еще больше.
Doc>В общем претензий к контрактам у тебя нет. Ты просто доколупался до проверок в примере.
Есть и я их указал, если ты не понял в чем суть проблемы, то о чем мы вообще тогда?
Здравствуйте, Poopy Joe, Вы писали:
Doc>>Не уходи в сторону. Еженедельный рефакторинг это именно о качестве кода. PJ>Нет, не говорит. А вот его боязнь говорит. Может голосование запустить.
Ну хочешь поспорить сам с собой — вперед. Я не боюсь, мне, как видно в отличии от тебя, не надо рефакторить еженедельно.
Хотя, можешь узнать, что говорит о коде такой частый рефакторинг.
PJ>Если у меня ошибка, то я просто не могу скомпилироваться, если у тебя ошибка может случится все что угодно.
Ну да, нет у тебя проверок — нет ошибок.
Странно, как ты возможность скомпилировать код приравнял к тому, что в нем нет логических ошибок.
PJ>Потому что у меня есть тип, и делается все там. У тебя все делается в разных местах, никак не связанных.
Ну учитывая как ты придирался к моему коду, то в твоем нет проверок. И у тебя он не компилится и не работает
Doc>>В общем претензий к контрактам у тебя нет. Ты просто доколупался до проверок в примере. PJ>Есть и я их указал, если ты не понял в чем суть проблемы, то о чем мы вообще тогда?
Это не проблемы контрактов. Не написать проверку на min можно и в твоем коде. Ну или покажи как твой пример сразу укажет на отсутствие такой проверки.
Если ты считаешь что это проблема именно контрактов, то о чем мы вообще тогда?
Здравствуйте, Doc, Вы писали:
A>>Безотносительно всей дискуссии. Мне так кажется, что на IsAdult точно должен быть контракт. Потому как предусловие есть — возраст не может/не должен быть меньше 0 — это явно неправильные данные и метод невалидно с ними работает.
Doc>Ну я подразумевал что вернется bool (т.е. true — взрослый). Как я сталкивался, то обычно так себя ведут методы и свойства Is<Что-то>, возвращая true если условие "что-то" выполняется.
Если кто-то передал туда отрицательные значения — значит в вызывающем коде, что-то уже не так. И именно для этого и нужен конракт, обнаружить нарушение пред-условия -> возраст не может быть отрицательным. От того что там вернётся false станет только хуже, вызывающий код продолжить работать как ни в чём не бывало и ошибка всплывёт гораздо позднее.
Здравствуйте, Andir, Вы писали:
A>Если кто-то передал туда отрицательные значения — значит в вызывающем коде, что-то уже не так. И именно для этого и нужен конракт, обнаружить нарушение пред-условия -> возраст не может быть отрицательным. От того что там вернётся false станет только хуже, вызывающий код продолжить работать как ни в чём не бывало и ошибка всплывёт гораздо позднее.
Хорошее замечание. Согласен. Можно так или передавать byte/uint
Здравствуйте, Doc, Вы писали:
Doc>Ну хочешь поспорить сам с собой — вперед. Я не боюсь, мне, как видно в отличии от тебя, не надо рефакторить еженедельно. Doc>Хотя, можешь узнать, что говорит о коде такой частый рефакторинг.
Я не говорил надо, я говорил могу. Можешь посмотреть в словаре разницу. Мне пока видно, что ты записался в свет истины, все ему видно...
Doc>Ну да, нет у тебя проверок — нет ошибок. Doc>Странно, как ты возможность скомпилировать код приравнял к тому, что в нем нет логических ошибок.
Странно, что ты за 100500 сообщений так и не понял предмета обсуждения.
Doc>Ну учитывая как ты придирался к моему коду, то в твоем нет проверок. И у тебя он не компилится и не работает
В моем коде есть ошибка поэтому он даже не компилится, в твоем ест ошибки, но он компилится и работает неверно. Это достижение.
Doc>Это не проблемы контрактов. Не написать проверку на min можно и в твоем коде. Ну или покажи как твой пример сразу укажет на отсутствие такой проверки. Doc>Если ты считаешь что это проблема именно контрактов, то о чем мы вообще тогда?
Это будет странно, если ты пишешь тип, и совершенно нормально, когда ты пишешь однотипные контракты в 100500 мест. Одно и то же условие проверятся в 3х местах, т.е. нарушаются все приличные практики. И ты еще этим гордишься...
В общем, корректного возражения как можно сломать тип ты предъявить не смог. Код писать не захотел, что понятно, выглядеть будет это сильно хуже. Дискуссия пошла по кругу. На сем позволю себе откланяться.
Здравствуйте, Poopy Joe, Вы писали:
Doc>>Ну учитывая как ты придирался к моему коду, то в твоем нет проверок. И у тебя он не компилится и не работает PJ>В моем коде есть ошибка поэтому он даже не компилится, в твоем ест ошибки, но он компилится и работает неверно. Это достижение.
Ну так твой тоже работает не верно
Doc>>Если ты считаешь что это проблема именно контрактов, то о чем мы вообще тогда? PJ>Это будет странно, если ты пишешь тип, и совершенно нормально, когда ты пишешь однотипные контракты в 100500 мест.
Тебе уже не только я сказал — одинаковые контракты на методах это очень не частое явление. С тем же успехом ты можешь каждый if в коде заворачивать в класс. Но ты придумал себе что-то, сделал из этих фантазий выводы ...
PJ>Одно и то же условие проверятся в 3х местах, т.е. нарушаются все приличные практики.
Придуманные тобой?
PJ>В общем, корректного возражения как можно сломать тип ты предъявить не смог. Код писать не захотел, что понятно, выглядеть будет это сильно хуже. Дискуссия пошла по кругу. На сем позволю себе откланяться.
Согласен, остановимся на том, что ты пишешь кучу лишнего кода на каждый if Который кстати еще и поддержки требует. Но как я понял, ты эти классы даже не тестируешь из соображений типа "а чему там ломаться". Так что удачи
Я тоже пробовал использовать, по результатам опыта — выкинул нафиг, как бесполезную ерунду.
