No interface without contract? – Part 2: About Pre- and Postconditions

Pre- and Postconditions: What they are, why you should use them and how they help you.

In the last part, the result was that we need something helping us to specify those kinds of “Implementation-Requirements”.

I already alluded to Pre- and Postconditions.

What are Preconditions?

In general: They are conditions that have to be fulfilled that a method (or a property’s getter / setter) can be invoked.

Preconditions say what a member expects from the caller.

What are Postconditions?

You may be able infer from the previous definitions that postconditions are conditions which will be fulfilled after the method executed completely.

Postconditions say what the caller can expect after the member has returned.

Pre- / Postconditions and Side-Effects

There is one important difference between Pre-/Postconditions and Side-Effects of members: While Side-Effects come with a real change (e.g. Foo.Test will be 5), Pre- and Postconditions only cover conditions which will be true – regardless whether they were true before the method execution.

What do Pre- and Postconditions cover?

Although this is not always completely true, both of them rely only on for the caller apparent conditions. Therefore, the caller must be able to check them before calling the method.

While Preconditions often rely on parameters, Postconditions deal with return values.

Exceptions and Preconditions

Even if you did not think about before you have certainly formulated Preconditions for your members:

public void Foo(string parameter)
    if (String.IsNullOrEmpty(parameter))
        throw new ArgumentNullException("parameter");


Here the Precondition is: parameter must not be null or empty.

Another “kind” of exceptions are no Preconditions: Exceptions, that occur as something has changed within the method execution (e.g. a network connection broke, …).

Finding Pre- and Postconditions

Finding suitable Pre- and Postconditions is not always an easy work.

While Preconditions can be found comparatively fast, it is almost never possible to find for really everything a method does suitable Postconditions.

You should always ask yourself: Is this Precondition really necessary? The less Preconditions you have, the easier the use of your member (of course, accepting every state and value and behaving very different depending on them makes using much more complicated). You have to find the happy medium.

And on the other side: Isn’t there something more my method guarantees? Even if something is very self-evident, it could be not for someone else. Very common postconditions are: “The return value is not null”; “Property X equals parameter x”; …


… trying to find them comes with a very accurate looking into your code. You may even realize some cases you didn’t think about before.

So formulating Pre- and Postconditions not only helps the user of your classes but also you improving your Codingstyle / finding possible unhandled cases.


Formulating Pre- and Postconditions improves the quality of your code.

In the next part, I will show how to write them down.


One Response to “No interface without contract? – Part 2: About Pre- and Postconditions”

  1. DotNetShoutout Says:

    No interface without contract? – About Pre- and Postconditions…

    Thank you for submitting this cool story – Trackback from DotNetShoutout…

Comments are closed.

%d bloggers like this: