The Dark Side of Interfaces

During Episode 1, we discussed the pitfalls of using explicit interface method implementations. I’ve put this article together to illustrate some of the confusing scenarios. The intent of this article isn’t to illustrate all of the pitfalls, but instead to illustrate enough to help explain why explicit interface method implementations should be carefully considered before use.

First, let’s briefly go over the structure of these examples. Each example program creates a simple command line application that creates a list of a class type, with the intention of displaying the list contents before and after a sort operation. Since I want to focus on the interfaces, the example application classes will all inherit from a base class, Example, that provides a static method, SomeExample(Type t), that will be the heart of each command line application. This will allow us to simply pass in the class type that we want to use.

To set this scenario up, we first need to create a base class that implements an interface explicitly. Since IComparable only requires we implement one method, it makes for a nice and simple interface for use to illustrate this.

As you can see, there’s nothing fancy here. Our base class, SomeClass, provides some storage for an integer, SomeData, and explicitly implements IComparable.CompareTo. To help see what happens when we do any comparisons on SomeClass, I’ve added a Console.WriteLine statement.

So I’ll create a simple command line application that looks like the following.

And it produces output similar to this.

Everything is as expected so far, again, nothing fancy. We have a List of SomeClass objects, each with an assigned random number. When we print out the original version of the list, we see the objects in the order they were added to the list. Next, we see some debug statements displaying which IComparable.CompareTo method was called. And lastly, we see what the list looks like after the list has been sorted, with the results listed in order of lowest to highest.

So far, everything looks fine.

Now let’s suppose we now have a need to subclass our base class with a new class, SomeChildClass.

At first glance, there isn’t much difference. The Console.WriteLine statement writes a different message, and the result is multiplied by -1, which produces output similar to this with the results listed in order of highest to lowest.

Let the confusion start. For starters, notice that the implementation of CompareTo isn’t explicit in the subclass and it’s not declared with the override keyword. Also, notice that we declared CompareTo as public.

Let’s look at a third example where I’ve removed the public keyword.

Now, let’s see what happens when we run this.

Wait, what? The parent’s private explicit interface method implemenation was called, as noted by the output and the sorted list’s printed order. But why?

For starters, by not declaring SomeOtherChildClass.CompareTo as public, the compiler automatically marks it as private. Now we have an object with two private methods that seem to share the same name, but only the one from the base class is the interface implementation. Why did I say they seem to share the same name? They don’t share the same name since the method from the base class is named explicitly. See how others reading this code could easily get confused?

When the sort operation calls IComparable.CompareTo, only the method from the base class can be called since it’s the only implementation of the interface.

OK, OK, so maybe we just need to let our subclass call our base class’s implementation. But how? The method is marked private by the base class, so we can’t call base.CompareTo. Here’s a temptation.

This looks OK, right? We’ll just cast this to IComparable and call CompareTo. Let’s see what happens now.

StackOverflowException from too much recursion huh? Well that sucks. So how do we call the base class? We would have needed to create a virtual method, CompareThis, in our base class, SomeClass, and allow it to be the meat of our comparison calculation. Then in our subclass, we could use the override keyword to create a new method that can safely call the base class method when and if needed.

So, I’ve modified the base class to look like this.

And I’ve modified the child class to look like this.

Which produces this final output.

Now, that works just fine, as along as you have the access and ability to modify the base class. However, that’s not always the case.

As stated earlier, if you can avoid explicit interface method implementations, then you probably should. But when you must use them, do so with caution and be aware of the pitfalls.

Download the examples discussed in this article here.