Лучший способ утверждать предварительное и последующее условие аргументов и значений в .NET?
В последнее время я думал о проектировании по контракту, и мне было интересно, что люди думают о наилучшем способе утверждения предварительного и постусловия значений в .NET? то есть проверка значений аргументов для метода.
Некоторые люди рекомендуют Debug.Assert, в то время как другие говорят об использовании оператора if и создании исключения. Каковы плюсы и минусы каждого из них?
Какие из доступных фреймворков вы рекомендуете?
Ответы 5
Я предпочитаю исключения утверждениям, потому что, если это должно быть так, а не так, я хочу знать об этом, чтобы исправить это, а покрытие, которое мы получаем в режиме отладки, далеки от реального использования или покрытия, поэтому просто использования Debug.Assert недостаточно.
Использование утверждений означает, что вы не добавите раздувания в свой код выпуска, но это означает, что вы сможете увидеть, когда и почему эти контракты будут нарушены, только если вы поймаете их на этом в отладочной сборке.
Использование исключений означает, что вы можете видеть разрыв контракта всякий раз, когда это происходит, при отладке или выпуске, но это также означает, что ваша сборка выпуска содержит больше проверок и кода.
Вы можете использовать промежуточный подход и использовать Trace для отслеживания ваших предварительных и пост-условий в каком-то журнале приложения, который можно использовать для отладки проблем. Однако вам понадобится способ сбора этих журналов, чтобы узнать, с какими проблемами сталкиваются ваши пользователи. Есть также возможность комбинировать это с исключениями, чтобы вы получали исключения для более серьезных проблем.
Однако я вижу это так: если контракт стоит принудительно исполнять, то при его разрыве стоит выбросить исключение. Я думаю, что это несколько зависит от мнения и целевого приложения. Если вы действительно генерируете исключения, вам, вероятно, понадобится некоторая форма системы отчетов об инцидентах, которая предоставляет отчеты о сбоях, когда возникшие исключения остаются необработанными.
Другой вариант - Спецификация #.
SpeC# - это расширение объектно-ориентированного языка C#. Он расширяет систему типов, включая ненулевые типы и проверенные исключения. Он предоставляет контракты методов в форме предварительных и постусловий, а также инвариантов объектов.
SpeC# идеально подходит для такого рода вещей, если вы можете включить его в среду сборки.
SpeC# - это способ сделать это, который является расширенным набором C#. Теперь у вас есть "Кодовые контракты", которая является независимой от языка версией SpeC#, так что теперь вы можете иметь контракты кода, например, в VB.NET.
В конечном итоге мы будем использовать кодовые контракты, когда появится .NET 4.0. Однако в нашем производственном коде прямо сейчас мы добились большого успеха с классом «Guard» вместе с обычным способом генерации исключений.
Для получения дополнительной информации см. мой пост об этом.
Вы можете взглянуть на фреймворк Fluent на http://conditions.codeplex.com/ Его открытый исходный код и бесплатный.
Вообще говоря, идея хорошего решения DBC заключается в проверке во время компиляции пост-и предварительных условий, что дает вам более жесткий цикл обратной связи по исключениям.