No interface without contract? – Part 1: Why plain interfaces aren’t enough

An interface is an interface – why this is not always right.

What is an interface?

Wikipedia says:

Interface generally refers to an abstraction that an entity provides of itself to the outside.

In C#, interfaces are realized using the interface keyword. It is explained as follows:

An interface contains only the signatures of methods, delegates or events. The implementation of the methods is done in the class that implements the interface, […]

You have to separate between these two definitions:

The “logical” side

An interface’s purpose is abstraction. Or, to express it more detailed, it abstracts the real implementation from the behavior a class ought to display. Interfaces perform some kind of grouping. They unite classes that behave similar in some situations. This allows writing much more general algorithms that only rely on the behavior that’s actually needed.

The “syntactical” side

As interfaces abstract implementations, it’s quite logical that they do not allow members to provide any of it. Classes implementing an interface must provide the implementation for the interface members.

What does it actually do?

Well – let’s look at this nice interface:

public interface ICanSayHelloWorld
{
    string SayHelloWorld();
}

If you want to use this interface with the knowledge you have about it now, you’ll run into problems. As SayHelloWorld it called that way and returns a string, it seems likely that it returns a string that can be used to greet the world. After some thinking we write the following line of code:

ICanSayHelloWorld greeter = //...;
Console.WriteLine(greeter.SayHelloWorld());

Maybe some other persons now write an implementation of your interface. They could look like the following ones:

First One
public sealed class Class1 : ICanSayHelloWorld
{
    public string SayHelloWorld()
    {
         return "Hello World";
    }
}

This code would fit best to that we wrote.

Second One
public sealed class Class2 : ICanSayHelloWorld
{
    public string SayHelloWorld()
    {
         Console.WriteLine("Hello World");
         return "SUCCESS";
    }
}

The author of this implementation thought that SayHelloWorld itself is responsible for printing out its greeting. Returning “SUCCESS” indicates a successfully completed operation.

Third One
public sealed class Class3 : ICanSayHelloWorld
{
    public string SayHelloWorld()
    {
         throw new Exception("Goodbye World");
    }
}

Looking at this implementation, the author may have thought that it is a mistake to great the world – his implementation will always thrown an exception.

Fourth One
public sealed class Class4 : ICanSayHelloWorld
{
    public string SayHelloWorld()
    {
         if (DateTime.Now.Hour > 12)
              return "Good evening World!";
         else if (DateTime.Now.Hour != 3)
               return "Good morning world!";

          throw new InvalidOperationException();
    }
}

Also this implementation is possible: Depending on the current time, the world is greeted differently. However, if it’s three o’clock in the morning, there will occur an exception.

Which implementation is the “correct one” now?

Short answer: None of them and still all. As the plain interface is all we have, no one of them did something wrong. All behaved as the C# Compiler claims them to do; they provide an implementation for the interface member.

Conclusion

We need to specify the behavior of our method much better (meaning:  more precisely). You will see in the next part how Pre- and Postconditions help us doing this.

About these ads

One Response to “No interface without contract? – Part 1: Why plain interfaces aren’t enough”

  1. DotNetShoutout Says:

    No interface without contract? – Why plain interfaces aren’t enough…

    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: