Действительно пытаясь любить CodeContracts в C#

Я наконец играю в догонялки со всем новым, которое было включено к.NET 3.5/4.0 Платформы. Последние несколько дней я работал с CodeContracts и я действительно очень стараюсь любить их. Мне любопытно, что другие люди думают о реализации CodeContracts в C#? А именно, как люди организуют вещи как классы Контракта для интерфейсов, методы контракта для Инвариантов Контракта и т.д.?

Мне нравится проверка, которую предоставляют контракты, на первый взгляд они выглядят великими. С несколькими простыми строками я могу получить некоторую хорошую сборку, проверяющую, прежде чем я даже выполню свой код. К сожалению, мне нелегко преобладать над чувством, что путем, которые кодируют контракты, является реализация в C#, они загромождают мой код больше, чем они документируют контракты. И в полной мере воспользоваться контрактами, я замусорил свой код предположениями и утверждаю и т.д. (который я знаю, что некоторые скажут, хорошая вещь); но поскольку некоторые мои примеры ниже покажут, это возвращает единственную простую строку к 4 или 5 строкам и действительно не добавляет достаточное значение, по-моему, по альтернативным подходам (т.е. утверждает, исключения и т.д.).

В настоящее время мои самые большие разочарования:

Интерфейсные контракты:

[ContractClass(typeof(IInterfaceContract))]
  public interface IInterface
  {
    Object Method(Object arg);
  }

  [ContractClassFor(typeof(IInterface))]
  internal abstract class IInterfaceContract
  {
    private IInterfaceContract() { }

    Object IInterface.Method(Object arg)
    {
      Contract.Requires(arg != null);
      Contract.Ensures(Contract.Result<Object>() != null);
      return default(Object);
    }
  }

Это чувствует себя подобно такому cludge мне, мне жаль, что не было более чистого способа зарегистрировать требования, или через атрибуты или через некоторую форму созданных в поддержке языка. То, что я должен реализовать абстрактный класс, который реализует мой интерфейс, именно так я могу указать, что контракт кажется утомительным в лучшем случае

Чрезмерное увеличение размера кода:

typeof(Action<>).MakeGenericType(typeof(Object);

Требует нескольких предположений только для проверки информации, которая легко доступна. Я ценю, что весь анализатор знает, то, что он воздействует на Тип и таким образом должен работать над теми ограниченными знаниями, но он все еще расстраивает меня, которого одна строка кода требует, чтобы я переписал как

var genericAction = typeof(Action<>);

Contract.Assume(genericAction.IsGenericType);
Contract.Assume(genericAction.GetGenericArguments().Length == 1);

genericAction.MakeGenericType(typeof(Object));

Только для хранения вещей зарегистрированными (да я знаю, что могу использовать ContractVerificationAttribute для выключения этого для метода/класса и т.д. или SuppressMessageAttribbute для предназначения для определенных сообщений но это, кажется, побеждает цель, поскольку код быстро стал бы замусоренным подавлениями и т.д.

Кроме того, беря случай как

  public class MyClass
    : IInterface
  {
    private readonly Object _obj;

    public Object Property
    {
      get
      {
        Contract.Ensures(Contract.Result<Object>() != null);
        return _obj;
      }
    }

    public MyClass(Object obj)
    {
      Contract.Requires(obj != null);

      _obj = obj;
    }
  }

obj требуется, чтобы не быть пустым, и установлен на поле только для чтения, которое не может быть изменено, все же я все еще обязан добавлять метод "разметки" к своему классу так, чтобы мое требование свойства для не возврата пустого указателя могло быть доказано:

[ContractInvariantMethod]
private void ObjectInvariant()
{
  Contract.Invariant(_obj != null);
}

Существует больше, но я полагал, что, вероятно, разглагольствовал достаточно, и я был бы очень признателен за понимание людей, намного более умных, чем я, чтобы помочь мне "как" Контракты Кода и заставить это чувство помехи кода уйти. Любое понимание о том, как лучше структурировать код, обходное решение wonkiness проблемы и т.д., значительно ценилось бы.

Спасибо!