(Programming to an interface v/s working with concrete class) when there is just one concrete class

Question

In an OO component, when you have only one implementation available for an class and that class is not 'published' to other components, is it still advisable to have an interface and work with the interface instead?

I am fully aware of 'programming to an interface' design principle and also use it extensively.

Lately, I have been observing that most of the time a different implementation (although possible and would make sense) is never needed. As a result of always working with interfaces, the application code would have a fair amount of interfaces with just one implementation for each and the interface seems sort of an overhead.

Instead, is it preferable to just work with the concrete class and introduce the interface only when a second implementation is needed? Anyway, nowadays extracting an interface using IDEs is a breeze. And when the new interface is introduced, references to the old concrete class can be changed to use the new interface instead.

What do you think?

Answer 1

To my knowledge, there are three situations where an interface is justified:

1. It's part of the architecture (I admit this one isn't very well defined).
2. You have more than 1 implementation.
3. It's a public interface.

Don't be afraid to use concrete classes. Don't mechanically generate an interface for every single class.

Answer 2

One reason I continue to program to an interface even with only one implementation is because it makes writing my tests a lot easier. I can set up proxies to test whatever I want to test and I don't have to worry about tight coupling.

This isn't always going to be advisable, but it's something worth thinking about when you're trying to decide. Do you think you'll need to extensively test around this class/object? If you think you will be it can be a lot easier dealing with the interface as opposed to the concrete class.

The alternative to that would be to not use the interface and subclass the concrete class, which works too, but again it depends.

Answer 3

Creating interfaces for concrete types is a delicate balancing act as you can easily create an interface explosion that provides no benefit and only complicates the domain space with redundant types.

My rule of thumb is to only create interfaces for types that are part of a public-facing API. All types that are dedicated to the implementation of the API and are never exposed from the API don't need an interface.

Answer 4

Interfaces should be evolved, not created. You should have a specific need for an interface before creating one. If you haven't needed more than one implementation, you don't need an interface. Always remember, YAGNI

Answer 5

In addition to the good answers given already (ease of testing and public APIs) I like using interfaces because it makes it easier to focus on "what" your classes should be doing than "how" they are doing it.

Answer 6

Generally: No. You don't need an interface if you're just implenting the functionality once. Interfaces like everything have a tradeoff: they introduce some more work (cost), and might introduce some more benefit. If the cost outweighs the benefit, you probably shouldn't do it!