Liskov Substitution Principle & Contracts

When working with contracts, there are several unpleasant things that have to be circumvented. For example, the Liskov Substitution Principle, which Contracts developers adhere to, does not come at night.


For example, we have a class that inherits an interface from an external library. And we define in the class the implementation of the method from this interface:

public class A : Interface1 { public void MethodInterface1( object sender, Event e) {...} } 

')
So, the ambush is that, according to the principles described above, we should not directly check the incoming values, since this is the responsibility of the library's postconditions, the interface provider. Those. This code is considered incorrect:

 public void MethodInterface1( object sender, Event e) { Contract.Requires(sender != null, "Sender is null"); Contract.Requires(event != null, "Event object is null"); ... } 

Moreover, even this implementation will issue a warning (warning CC1033):

 public void MethodInterface1( object sender, Event e) { if (sender == null) throw new ArgumentNullException("sender", "Event sender is null."); if (evt == null) throw new ArgumentNullException("evt", "Event object is null."); Contract.EndContractBlock(); ... } 

Apparently, the developers hope that the creators of interfaces understand in the rules of inheritance and the theory of building hierarchies a little more than usual ...

Ps. It is necessary to use the old method of validation instead of contracts in processing such inherited interfaces, removing the contract specification.