If you are certain there will only be one class in the rest of eternity including by any external code, then it is indeed redundant. It might save you a tiny bit of performance to skip the interface, but maybe not (if the compiler is smart and figures out there's only one implementation).

In other cases, it may seem like there will only be one implementation now, but few projects grow in such a predictable way. In this case, I think it's easier to adhere to the principle than to refactor later (you can't refactor external code, for one). It also adds consistency.

Depends ... in theory it could if you got a specific intention. An interface enforces a specific API an Object does not.

it can be overkill, but this is a design question, as such it does not matter if it's 1 or N it's -> do I want to make certain it looks this way.

If you just got one class and you are not certain it will remain that way -> probably you shouldn't add an interface at the moment.

If it's a core part and it has to be that way and some parts shouldn't change without noticing than you should add an interface.

In a lot of projects we wouldn't reference the objects directly, ever, and only reference the interfaces. There is more at stake than just the class implementation. An example will likely help:

Let's assume I have a class that reads a record from the database. I call that class "DataReader." The problem with not having an interface is that any time I refer to that class, I have to understand it's dependencies as well. If it is ready from MySQL, it likely takes a dependency on MySQL drivers/packages. That means anything I write that uses that class now is dependent on MySQL. In reality, however, I may be writing a simple test on an object that just depends on the data reader. Why should that project have to take on additional dependencies?

Then let's assume sales tasks me with building a "demo version" of the product that runs on their laptop that doesn't have MySQL. If my main code is talking to "DataReader" I'm stuck. If I implemented it as IDataReader, now I can write SalesDataReader that just returns a hard-coded/static value and I'm good to go.

From a design perspective the interface allows you to describe what the expectations are for a set of operations without the implementation. I almost always start with interfaces, and then implement the classes as needed. This helps scale projects.

Just one more example to help clarify: I was working on a project for a cable provider that involved building out a television guide. Unfortunately, they were migrating to a new database and rewriting their API implementation. We had data structures in place (i.e. a "program" looked like "this" and had "these fields") so we were able to write interfaces (fetch guide, fetch program, get ratings, etc.). Instead of waiting for the other refactoring to finish, we went ahead and created some "dummy" classes implementations that returned hard-coded shows and channels so we could get the user interface working and styled. Once the APIs came online, we simply swapped out the dummy classes with implementations that called to the APIs and "flipped the switch" to bring it live.

So much power in using interfaces, I wouldn't skip them just because of assumptions around how they'll be used.

Jeremy

Interfaces are a critical part of Dependency Injection and will allow you to Mock the functionality defined by the interfaces during Unit testing. I completely disagree with the idea that they are redundant if you think one class will ever implement them.

I have numerous applications where I have defined an interface and only have one class implementation of said interface. The power of interfaces lies in the ability to define abstractions in our programs and create dependancies on said abstractions to promote loose coupling. Interfaces aren't just used to achieve polymorphism. They allow for flexibility in your code...