No Interface Without Contract? – Part 3: Finding Pre- and Postconditions

“If you give me a string not beeing null or empty, I will give you a number greater zero” – Pre- and Postconditions made easy.

In the previous part, we found out that pre- and postconditions improve the quality of our code.

Note: I primary announced that part 3 is about writing them down. However, while writing I realized that it is better to split up this part.

Example

Let’s take a look at our sample class first:

public sealed class Foo
{
    public static bool IsValidProperty(string value)
    {
        return !String.IsNullOrEmpty(value)
                && value.All(Char.IsDigit);
    }

    private string property;

    public string Property
    {
        get
        {
            return this.property;
        }
        set
        {
            this.property = value;
        }
    }
    public bool IsValid
    {
        get
        {
            return Foo.IsValidProperty(this.Property);
        }
    }

    public Foo()
        : this(null)
    {
    }
    public Foo(string property)
    {
        this.Property = property;
    }

    public int Bar()
    {
        Random r = new Random();

        int index = r.Next(0, this.Property.Length);
        return this.Bar(index);
    }
    public int Bar(int index)
    {
        char value = this.Property[index];
        return Convert.ToInt32(value);
    }
}

Now try to find some pre- and postconditions for the members.

Note: Doing so we won’t care about factors which are (normally) outside our influence in code: corrupted binaries, out of memory scenarios, etc.

I found the following ones (please let me know if there are more!):

Bar (no parameter)

As you can see Bar has a precondition which must be fulfilled in order to complete successful:

  • IsValid must be true (and therefore must be not null and only contain digit characters).

Its postconditions are not that clearly, but it has some:

  • The return value is between 0 and 9 as neither negative digits nor digits bigger than 9 exist – you would need more than one character (leaving out other number systems for a while ;-) ).
  • Property contains the string representation of the return value.

In addition, the state of Foo is not affected by a call of Bar.

Bar (int)

Preconditions:

  • IsValid must be true (and therefore must be not null and only contain digit characters).
  • index must be greater equal 0 and less than Property.Lenght

Just like the overload with no parameter, there are the following postconditions and one new:

  • The return value is between 0 and 9
  • Property contains the string representation of the return value.
  • The string representation of the return value equals Property[index]

Just like the overload with no parameter, Bar doesn’t affect the state of Foo.

Default-Constructor

The default constructor has no preconditions.

Instead, there are some postconditions:

  • Property is null
  • IsValid is false (as Property is null)

Constructor expecting a string

You could think one precondition is that the parameter must not be null or empty. This, however, is wrong – you can pass an “invalid” string. IsValid just will be false. So this constructor has no preconditions, either.

The postconditions refer to the parameter

  • Property equals property
  • IsValid is IsValidProperty(property)

IsValidPropertyName

IsValidPropertyName has no preconditions, but two postconditions depending on the return value:

  • If the return value is true, value is not null or empty
  • If the return value is true, value only consists of digits

IsValid

To save redundant conditions, we can say (as a postcondition):

  • The return value equals “IsValidPropertyName(this.Property)” which implies that Property is neither null / empty nor it contains any non-numeric character

Like all  property getters should, IsValid comes with no state-changing actions.

Conclusion / Outlook

We saw that finding pre- / postconditions is a little bit tricky sometimes.

You often won’t be find all possible postconditions which is not necessary either.

In the next part, we will look on possibilities to really write them down in a comfortable way.

About these ads

One Response to “No Interface Without Contract? – Part 3: Finding Pre- and Postconditions”

  1. DotNetShoutout Says:

    No Interface Without Contract? – Finding Pre- and Postconditions…

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


Comments are closed.

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: