Попробую написать коротенький такой пост про то, как бы по моему мнению идеально выглядело бы внедрение DBC в язык программирования, так сказать - мечты ;)
Допустим что у нас есть некий проект в котором есть классы с описанными инвариантами, пред и пост условиями. Ну и представим, что их описание довольно легкое, скажем так, нас в первую очередь сейчас должен волновать не способ их описания ;) Что теперь с этим описанием необходимо делать?
Ну можно делать, например, разного рода ворнинги. Например, есть метод у которого в предусловии у первого параметра стоит, что он должен быть больше нуля, а мы передаем туда переменную просто типа int. В таком случае необходимо добавить warning о том, что переменная может быть и меньше нуля. Ну или есть у нас еще некий класс у которого есть свойство для которого задано, что оно больше нуля и именно это свойство мы передаем в метод - в таком случае ворнинга быть не должно быть.
Под категорию таких же проверок может подойти так же, например, вызов метода из другого метода. Есть метод1, который внутри себя где то в середине вызывает метод2, передавая ему расчитанные в методе1 параметры. В зависимости от входных данных метода1 зависит передаваемый параметр в метод2, т.е. в зависимости от ограничений на входные данные метода1 зависит то, какой параметр мы можем передать в метод2. Анализируем ограничения на параметр в методе2 и, быть может, выдаем замечание о том, что ограничение на параметр в методе1 можно и усилить, т.к. при некоторых его значениях вызов метода2 будет некорректен.
Пусть у всех пред пост условий и инвариантов есть приоритет - в таком случае при компиляции можно указывать, какие проверки в итоге можно включать результирующий код, а какие нет. Это так сказать - игра с балансом производительности и безопасности.
Возможность автоматического тестирования на основе все тех же пред пост условий и инвариантах.
В общем говоря, DBC должен открыть возможность дополнительного анализа кода (ведь появилась некая дополнительная мета информация о нем), а не просто добавлять проверки в код ;)
Ну можно делать, например, разного рода ворнинги. Например, есть метод у которого в предусловии у первого параметра стоит, что он должен быть больше нуля, а мы передаем туда переменную просто типа int. В таком случае необходимо добавить warning о том, что переменная может быть и меньше нуля. Ну или есть у нас еще некий класс у которого есть свойство для которого задано, что оно больше нуля и именно это свойство мы передаем в метод - в таком случае ворнинга быть не должно быть.
Под категорию таких же проверок может подойти так же, например, вызов метода из другого метода. Есть метод1, который внутри себя где то в середине вызывает метод2, передавая ему расчитанные в методе1 параметры. В зависимости от входных данных метода1 зависит передаваемый параметр в метод2, т.е. в зависимости от ограничений на входные данные метода1 зависит то, какой параметр мы можем передать в метод2. Анализируем ограничения на параметр в методе2 и, быть может, выдаем замечание о том, что ограничение на параметр в методе1 можно и усилить, т.к. при некоторых его значениях вызов метода2 будет некорректен.
Пусть у всех пред пост условий и инвариантов есть приоритет - в таком случае при компиляции можно указывать, какие проверки в итоге можно включать результирующий код, а какие нет. Это так сказать - игра с балансом производительности и безопасности.
Возможность автоматического тестирования на основе все тех же пред пост условий и инвариантах.
В общем говоря, DBC должен открыть возможность дополнительного анализа кода (ведь появилась некая дополнительная мета информация о нем), а не просто добавлять проверки в код ;)
А стоит ли вообще оставлять инварианты и условия в production-версии. Я это дело вижу так: пишутся тесты, создается интерфейс (классы методы), уточняется интерфейс (DBC), реализуются методы, все это дело рефакторится и повторяется до готовности.
ОтветитьУдалитьПо поводу ворнигов - тут как раз можно задействовать аспекты. Сообщения, например, можно записывать в файл, но лучше в базу для последующего анализа. Таким образом, можно будет автоматом выявлять самые "ошибкоемкие" классы. Что скажешь?
Часть быть может и надо ;) Кто знает. Обычно это условия типа [NotNull] :)
ОтветитьУдалитьНу если ловить ворнинги во время исполнения приложения, то да... Но, вообще, я имел в виду ворнинги во время компиляции кода. Т.е. когда код скопмилировался (ошибок нет), а вот ворнинги есть - что бы разработчик видел, что код то скомпилировался, но вот ворнинги остались (интересно на них, вообще, кто нибудь смотрит)