Code contracts and inheritance problems, what goes where?

Question

I might be misunderstanding code contracts, but here's my situation.

I have the following code:

interface IFetch<T>    // defined in another DLL
{
    T Fetch(int id);
}

interface IUserFetch : IFetch<User>
{
    IEnumerable<User> GetUsersLoggedIn ();
}

class UserFetch : IUserFetch
{
    public User Fetch(int id)
    {
        return (User) Database.DoStuff (id);
    }

    public IEnumerable<User> GetUsersLoggedIn ()
    {
        return (IEnumerable<User>) Database.DoMoreStuff ();
    }
}

I'm trying to add a relatively simple contract: Contract.Requires (id != 0);, and I want it validated on Fetch. When I add it to Fetch directly, I get the warning that Method Fetch(int id) implements interface 3rdParty.IFetch<User> and thus cannot add Requires.

I created an abstract code contracts class implementing IFetch and pointed it to/from UserFetch using the ContractClass and ContractClassFor attributes respectively. I still get an error like CodeContracts: The class 'FetchUserContracts' is supposed to be a contract class for '3rdParty.IFetch<User>', but that type does not point back to this class. However, since 3rdParty.IFetch is a generic type, I don't think I can ever put a code contract on it specifically.

Has the problem been made clear, and if so, how do I solve it?

Answer 1

I believe Ɖiamond ǤeezeƦ’s answer is correct. I will just add a bit of explaination.

You cannot add a Contract.Requires decoration to a method in a closed constructed type (such as IFetch<User>). You must add it to the open constructed type (IFetch<>). The reason for this is exactly the same reason that you cannot add a Contract.Requires decoration to a concrete method that is used to implements an interface: code contracts are designed to be verifiable at compile time when the full type of an object instance may be unknown.

Suppose it did allowed you to put the contract on the concrete method implementation.

public User Fetch(int id) 
{ 
    Contract.Requires (id != 0);, 
    return (User) Database.DoStuff (id); 
} 

Now suppose someone tried to use a variable of the interface type.

class DataDisplayer<T>
{
    Label myLabel = new Label();
    public void Display(IFetch<T> fetch, int id)
    {
        myLabel.Text = fetch.Fetch(id).ToString();
    }
}

Does this allow a contract violation or not? It is impossible to tell, because we don't know what the concrete type of fetch will be at runtime.

Putting the contract on a particular closed constructed type like IFetch<User> does not solve this problem. We still don't know what type T is in the calling code.

The Liskov Substitution Principle, which is a cornerstone of all object orient programming, means that we can never assume anything about the runtime type of an object beyond what the variable's type indicates. And since the variable's type may be a generic interface, code contracts cannot place any additional burden on the caller than what is in the generic interface definition.

Therefore, Contract.Requires must be put on the open constructed type, so that any object that implements the interface will have the requirement, and any potential call to the method through a variable of the interface type can be verified for correctness with respect to that requirement.