Что такое практическое использование Контрактов Кода в.NET 4.0?
Чтобы полностью понять и использовать в своих интересах новые возможности, и улучшения предоставили то, чтобы выйти из новой Платформы.NET 4.0, я хотел бы получить пример реального приложения Контрактов Кода.
- У кого-либо есть хороший пример приложения этой функции?
Я хотел бы заставить пример кода с кратким объяснением помогать мне встать и работающий с ним.
3 ответа
Из Руководство пользователя по контрактам кода :
Контракты позволяют вам выражать предварительные условия, постусловия и инварианты объектов в вашем коде во время выполнения проверка, статический анализ и документация.
Контракты кода используются для статической проверки ; представьте, что во время компиляции вы обнаружили не только синтаксические ошибки, но и логические ошибки . Это видение статической верификации программ.
Пример из реального мира
Вы можете использовать контракты (и статическую проверку), чтобы снизить стоимость тестирования ... в частности, регрессионного тестирования. В качестве примера предположим, что я пишу код, который удовлетворяет некоторые потребности бизнеса ... но позже требования к производительности изменились, и мне нужно было оптимизировать. Если я сначала напишу контракт, а затем - когда мой новый оптимизированный код будет проверен - если он больше не соответствует исходному контракту, я получу сообщение об ошибке в моей среде IDE, как если бы у меня была ошибка времени компиляции. В результате вы обнаруживаете и устраняете ошибку почти сразу, что стоит меньше, чем раунд тестирования.
В грядущей книге C # in Depth, второе издание есть свободно доступная глава о контрактах кода . От какого-то парня по имени Джон Скит, некоторые из вас могут быть знакомы с ним :)
Что касается практического использования. Вы можете использовать их в любом месте вашего кода, но особенно если вы разрабатываете библиотеки типов фреймворка / API, которые будут использовать многие люди, я ожидаю, что они пригодятся. Статическая проверка вашего кода экономит много времени по сравнению с обнаружением во время выполнения, что вы не справились с некоторыми крайними случаями.
Вы можете документировать использование вашего метода сколько угодно, но будут ли люди читать эту документацию? Разрешено ли иметь строковый параметр x в методе y равным нулю или нет? Кодовые контракты могут предоставить эту информацию, чтобы исключить догадки из уравнения.
Вот пример такого случая:
static int CountWhitespace(string text)
{
Contract.Requires<ArgumentNullException>(text != null, "text");
return text.Count(char.IsWhiteSpace);
}
Проверка выдаст жалобу, если кто-нибудь попытается передать в CountWhitespace строку, которая может быть нулевой. Кроме того, он вызовет исключение ArgumentNullException во время выполнения.
Я только недавно преобразовал свою частную библиотеку классов в .NET 4.0, но я планирую добавить к ней контракты кода в ближайшее время.
Вы когда-нибудь видели NullReferenceException и хотели бы, чтобы компилятор мог предупредить вас об этом во время компиляции, чтобы избежать трудностей - когда ваша программа выйдет из строя?
С помощью контрактов кода вы можете писать такие вещи, как:
Contract.Requires(foo != null);
Это не просто проверка во время выполнения - вы можете настроить ее так, что если вы вызовете эту функцию с аргументом, который может быть нулевым, вы получите ошибку компиляции.
Вот реальный пример:
Address GetAddress(Customer customer)
{
Contract.Requires<ArgumentNullException>(customer != null, "customer");
return addressBook.FindCustomer(customer);
}