How to understand the meaning of "Contract"

Question

I always see the word contract and it seems to have different meanings or at least it is how it looks to me (I am not a native English speaker) so when I see the word "contract" I cannot be sure what I should understand and expect from it. I don't know if anyone else is having the same trouble but this bugs me a lot. For example, when I see "interface" it makes me think "abstraction, dependency injection, inheritance, etc." and I know what I am looking for and it is getting formed in my mind nicely and easily.

But when it comes to the word contract I cannot visualize a pattern, class etc. whatever it is. Is it something formed using interface or a class or maybe an attribute etc.

For example, there is a class here (in Json.NET) which talks about something called IContractResolver and the page is explained what it is used for :

The IContractResolver interface provides a way to customize how the JsonSerializer serializes and deserializes .NET objects to JSON without placing attributes on your classes.

The explaination is very comprehensible but I cannot just form the idea when I see Contract and I cannot say :

"Umm, I am expecting some methods which do this and that so I can override it and later I use this class here/there to change/fulfill some functionality etc."

and this bugs me a lot. I read some article about it but they are talking about Design by Contract and it is not something useful for someone who has troubles with the meaning of "contract".

So can some one please explain how I should understand this term and what I should expect when I see it? It would be very nice you could add some sample code in order for me to visualize it.

Answer 1

In "Design by Contract", a contract means an agreement between the developer of a library (class, function) and the consumer.

It could be an agreement that no one will pass null for a certain parameter. It could be an agreement that a particular method always completes in less than 200ms. Or that events are raised on the thread which created the object. What's important is that there is some document full of rules and both caller and function agree to those rules.

IContractResolver sounds like it provides a data format. It is not a contract. (There may be a contract that says both endpoints of the communication will use this format for particular messages, but a format is not by itself a complete contract. A contract would need to also describe when each message should be sent, and so on.)

Answer 2

Contract is an agreement among at least two parties. In this context .NET contracts make perfect sense.

In design by contract context, it's similar. Designing by an agreement, you're agreeing on an interface and some verifiable obligations.

Answer 3

Contract is rather broad term, but have some specific meanings. So to understand it correctly you should know the context. The general definition is (from here):

A binding agreement between two or more persons or parties

It can be agreement on what operations are provided (partially synonymous to protocol), like here:

The service contract specifies what operations the service supports.

Or in what format data has to be passed (here):

A data contract is a formal agreement between a service and a client

Also interface sometimes is called contract - because it is exactly it: binding agreement on what can be called and how.

Contracts in data-driven development are also agreements on what data can be passed, what data can be returned, and what are valid states of objects. It is essentially the same thing as in first quote: binding agreement between two different pieces of code.

So if you are not sure about context, try to use common sense. If you are not familiar with context, try to understand or ask:

• What does contract define in this case?
• How is it defined?
• What are the parties that are involved?

Answer 4

Well, contract is one of those burdened words which have many meanings depending on context.

To me, it is any agreement between two parties, so it can be an interface in the sense of .NET interface (i.e. a type), or it can be a set and sequence of messages exchanged between the parties (i.e. a protocol) or in your JSON example a mapping between an object and its persisted form.

It is interesting that you mention "interface" as clearer because it is not necessarily so. I don't associate it with abstraction, dependency injection or inheritance (especially that last one), but more loosely with any kind of protocol. Maybe the reason is that I started with languages which don't have interface built in with specific meaning and as a keyword (e.g. C++). The point is that it also depends on context.