Thanks for your loong comment. I really enjoy your comments! Discussion is the foundation of every further development.
In my opinion, the empty EMail object can sometimes not only be necessary in cases where my API expects it. Moreover, a really important case in my opinion is handling data through any kind of UI.
In a broader range, sometimes it would be necessary to have an empty or temporarily invalid object, thus to bring direct data binding of this object to the UI (e.g. Silverlight) to life. This would temporarily break the contract of the object, but that’s ok, since the user has recently inserted the new/empty item and is now editing it and brings it to valid state. I don’t see that this can easily be managed through contracts directly by using invariants.

Either way, I think we are both agreeing on the “it depends” term. It depends on the situation where to have contracts and for what to have them. If you like, I would exchange some more information with you via E-Mail (please not empty ), thus to make up my mind even further. There are many questions and I think through discussion I could get a deeper insight. If you like, please send a short ping to (moved).

Thanks, Matthias

Yes it is validation, but not runtime validation instead contractual validation (All contracts are after all data validation ( For example method parameters store data, and you validate the values of the parameters, Contracts add “data” constraints (shape, size, etc) as opposed to only type constraints which a typed language already has)).

> I could imagine cases of empty EMail objects

This depends on what your API expects, I could just as well design an API that doen’t handle empty mail messages and express that as a contract, on the other hand if I’d design the API to handle empty mail messages I wouldn’t express that as a contract, but some form of runtime validation where necessary, or method contracts.

> But should this be modelled as invariant? What’s your opinion about this?

Not necessarily as an invariant, you could model it as a contract on the Send() Method for example which only accepts mails that have all the required fields. But the way you design it, it is a choice basically, and I think there are advantages to modeling a eMail class as invariant as it can potentially simplify the validations the code has to to in various places, and bring a bit more consistency to the API (but only if handling empty mail messages is not required)

Anyway great series of posts, and I think the exploration of what code contracts could potentially do to make code better has just begun, and the do’s and don’ts still need to be discovered for the largest part.

Nice to see your example. I see, that you’re using the object invariants for some kind of data validation, right? I don’t know if I would use them in the same way. In general I would say: it depends

I could imagine cases of empty EMail objects, where the invariants don’t fit. Just when I want to save them, I would validate the EMail object. Especially (besides of this EMail example) if I have depending constraints and would bind the object to an UI, perhaps I must be able to temporarily break one constraint, if I change a value, until I change the value of a depending property.

Thus there could be problems that arise by handling data validation through invariants. It generally leads to the question: what to model through contracts and there is just few concrete information/best practices on this. Well, it really depends, but if there would be some showcases, in my opinion this would really help. First programmers and second DbC itself to get more popular.

~ Matthias

public class EMail {
public string To { get … set …
public string Subject { get … set …
public string Body { get … set …

[ContractInvariantMethod]
protected void ClassConstraints()
{
Contract.Invariant(To != null);
Contract.Invariant(Subject != null || Body != null);
}
}

I definitely think the same way because of the same reasons you mentioned (following the LSP)! This example is not to show good code, but just to have a showcase for the problem at hand. Personally, I wouldn’t implement Square in this way,.

Perhaps I’ll find another (better) example. If you have any ideas, please let me know

~ Matthias

What you are doing is a Rectangle that is constrained to be a square (a special case for rectangle), which breaks Liskov substitution principle.

The Square inherits Rectangle is a classical “what you should not do” object oriented design problem …

The consumers of the Rectangle class expect that all inheritors of the class respect the contracts the base class imposes, and in this case the Square class, breaks the parent class imposed contracts, by narrowing the contract accepted input, anyone working polimorphically with the Rectangle class will run into issues when a Square is received.

Classic example of Liskov substitution principle being violated:
http://www.oodesign.com/liskov-s-substitution-principle.html