3

I understand that I cannot add preconditions on an interface implementation. I have to create a contract class where I define contracts on elements that are seen by the interface.

But in the following case, how can add a contract on an internal state of the implementation that is therefore not known at the interface definition level ?

[ContractClass(typeof(IFooContract))]
interface IFoo
{
  void Do(IBar bar);
}

[ContractClassFor(typeof(IFoo))]
sealed class IFooContract : IFoo
{
  void IFoo.Do(IBar bar)
  {
    Contract.Require (bar != null);

    // ERROR: unknown property
    //Contract.Require (MyState != null);
  }
}

class Foo : IFoo
{
  // The internal state that must not be null when Do(bar) is called.
  public object MyState { get; set; }

  void IFoo.Do(IBar bar)
  {
    // ERROR: cannot add precondition
    //Contract.Require (MyState != null);

    <...>
  }
}
cedrou
  • 2,780
  • 1
  • 18
  • 23

1 Answers1

3

You can't - that postcondition isn't appropriate for all implementations of IFoo, because it's not declared in IFoo. You can only refer to members of the interface (or other interfaces it extends).

You should be able to add it in Foo though, because you're adding a postcondition (Ensures) rather than a precondition (Requires).

You can't add an implementation-specific precondition because then a caller wouldn't be able to know whether or not they were going to violate the contract:

public void DoSomething(IFoo foo)
{
    // Is this valid or not? I have no way of telling.
    foo.Do(bar);
}

Basically, contracts aren't allowed to be "unfair" to callers - if the caller violates a precondition, that should always indicate a bug rather than something they couldn't have predicted.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • Can't right now - but the second half of my answer addresses why you can't do it. – Jon Skeet Sep 06 '09 at 12:08
  • Is this a limitation of contracts or is it a problem of design from my part ? Should I create another interface which includes the property I need to check ? – cedrou Sep 06 '09 at 12:19
  • It's a flaw in your design. How can a caller use your interface if they can't tell whether or not they're violating your contract? – Jon Skeet Sep 06 '09 at 12:33
  • @JonSkeet I was going to ask a similar question, but I'd prefer to ask you it in a comment. When you said "You can't add an implementation-specific precondition because [...]", you argue that Code Contracts won't support this use case because it's not possible that different implementations would *require* different pre-conditions. Am I wrong? But at the end of the day, implementations might need specific pre-conditions anyway. For example, an implementation of I interface needs to access a database thus it requires a connection string, but this cannot be reflected by the contract class – Matías Fidemraizer Sep 03 '14 at 13:36
  • @JonSkeet Wouldn't be this case a good argument to support implementation pre-conditions? – Matías Fidemraizer Sep 03 '14 at 13:36
  • @JonSkeet In fact, I'm thinking how this would be solved and I believe there's a good solution+design: I interface, implementers and consumers of its implementations won't know that a db-backed implementation would require a database. But I can create another interface which implements I called IWithDbStore (or who knows) which inherits the most abstract contracts and also adds a pre-condition to ensure that any IWithDbStore requires a specific configured connection string.... – Matías Fidemraizer Sep 03 '14 at 13:43
  • @MatíasFidemraizer: Well, if a client only knows about the existing interface, you're still adding constraints to that... – Jon Skeet Sep 03 '14 at 14:31
  • @JonSkeet http://stackoverflow.com/questions/25647220/how-to-ensure-that-implementations-of-an-interface-have-a-connection-string-if-t/25647221#25647221 Check, I've published an auto-answer to explain a possible approach. Would you like to discuss it there? :D – Matías Fidemraizer Sep 03 '14 at 14:42