Programming against an interface with only one class implementing said interface

Question

I can understand why to program against an interface rather than an implementation. However, in an example like the following (I find this a lot):

public interface ISomething
{
    void BlahOne(int foo);
    void BlahTwo(string foo);
}

public class BaseSomething : ISomething
{
    public void BlahOne(int foo)
    {
        //impl 
    }

    public void BlahTwo(string foo)
    {
        //impl
    }
}

public class SpecificSomethingOne : BaseSomething
{
    public void SpecificOne()
    {
        //blah
    }
}

public class SpecificSomethingTwo : BaseSomething
//and on..

The current example of this is the component based entity system in my game. (I have IComponent, Component, PosComponent, etc).

However, I cannot see a reason to have ISomething. The name may look nicer, but it doesn't seem to have a purpose. I can just return BaseSomething all the time.

Is there a reason to have an interface when you have a single base implementation everything uses? (I can see the use for, say, IComparable or IEnumerable)

EDIT: For a slightly different scenario (yet still related enough to not need a different question), if I assume I have this structure for everything, would there be much difference if I were to use ISomething for parameter types and variables compared to BaseSomething?

If there will only ever be one single implementation, yeah, you don't really need an interface from a practical perspective. However, ask yourself: Is that the case, and are you willing to go through your whole codebase if it turns out it isn't? — , May 22 '11 at 13:52
This is for a new project, so pretty much none of it is done yet. I've worked this way for a while and only just started doubting it. If I had an existing codebase, I wouldn't bother. — PrettyPrincessKitty FS, May 22 '11 at 13:54

score 13 · Answer 1 · answered May 22 '11 at 14:59

I prefer "lazy design" - extract the interface from BaseSomething when you need it. Until then, keep it simple and skip it.

Right now I can think of two reasons for having an interface when there is only one implementation:

There is another mock implementation for unit tests (i.e. there is a second implementation, although not in production code).
The interface and the implementation are defined in different class libraries. E.g. when using the Model-View-Presenter pattern, the view can reside in an .exe project that is dependent on the .dll where the presenter is implemented. Then an IView interface can be put in the .dll and the presenter's reference to the view supplied through dependency injection.

This answer is far more helpful than the accepted answer IMHO. Thank you. — Dan Bechard, Nov 01 '12 at 12:51

score 2 · Accepted Answer · edited May 23 '17 at 11:46

Correct answer to your question would be "It depends".

You can look at it in many different ways and it's all about perspective. When you have a concrete or abstract base class, it means your objects have something in common functionally. And derived objects are inter-related in some way or the other. Interfaces let you confirm to a functional contract only where each object implementing the interface will be responsible for the implementation.

Again, when you program again interfaces, you strictly know the capabilities of the object since it implements the given interface. And you need not worry about how each object functionally implements this.

It'd not be completely wrong, If I say each of your objects are completely independent when it comes to implementing the interface ISomething, given that SpecificSomethingOne and SpecificSomethingTwo do not derive from BaseSomeThing and each implement their own ISomething.

You can refer to this answer on the same matter.

score 1 · Answer 3 · answered May 22 '11 at 13:53

it is not really necessary but it is a better design if you want to extend your program later or you want to implement another Base-Class. In your case I would not implement the Base-Class. The Interface only is just fine if you dont want to have a default-behaviour. If you want a default-behaviour then just write the Base-Class without an Interface

score 0 · Answer 4 · answered May 22 '11 at 14:41

If your BaseSomething were abstract and you had implementing specific things that provider overloads to abstract methods, the only way to program to them at that point would be to the ISomething interface. However, in the example you showed, there is really no reason for ISomething unless you could have multiple base implementations.

Programming against an interface with only one class implementing said interface

4 Answers4