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