This is a straight up violation of the YAGNI principle and I strongly recommend against doing it that way. It is so easy to introduce an interface later when you really need it that you should not even bother creating it up front. I heard this is a quite common pattern among Java folks but don’t ask me why, I have no idea.

However, if this is a team project on which you collaborate, you should follow the established standards, even though they are bad.

This is a common with partial applications of SOLID principles to a project, and not necessarily a bad thing.

Coding against interfaces instead of classes is a reasonable way to maintain Dependency Inversion, and is very useful (some say necessary) for creating testable software components.

However, if your system as exactly 1 interface for every class, and vice versa, you’re probably not respecting Interface segregation, and you’re almost certainly violating the guideline of You Ain’t Gonna Need It.

Consider the cost in development time (now and in the future) of creating interfaces for each class, and evaluate whether better interface segregation would benefit your project. These principles and guidelines exist only to enable you to understand the tradeoffs in various designs, and communicate about them effectively. The decision on which conventions to follow, and how strictly, is in your hands.

Yes, this project is going way overboard. There are two main reasons why this may happen:

• The programmer was blindly following some dogma without understanding where it would actually yield benefits and where not
• The programmer is doing test-driven development and makes heavy use of a mocking framework for the tests, and that mocking framework does not (or did not, either when the project was created or when the programmer learned the technique) support mocking concrete classes.

Having an interface to each class is extreme. You spotted that right.

However, having interfaces implemented by only a single class is not that unusual as you may think. If you are familiar with the Agile principles, they usually say that interfaces belong to the client, which is both logically correct and technically practical. So you may create interfaces to define behavior to the client and compile clients without the real classes available and thus reducing compile times or delivery of modules. Because modules will depend on interfaces, they will be deliverable independently and without a concrete implementation. Than you can just swap implementations as you wish.

If you take this to extreme, you and up with what you see. It’s not good at all, but it would be worse to have no interface at all.

I know the general recommendation is to code to an interface rather than an implementation, but isn’t this taking it a bit too far?

(IMO) yes. If you have an interface with only one implementor, then you don’t really need the interface.

That said, many places will always require 2 implementors. The actual implementation and a mock implementation to allow unit testing of the things that consume it. If your object is just data, or can be used by tests in isolation, great.

The other case where interfaces make sense is as a public interface to an API. That can serve as protection to your consumers even if there is only one implementor (for now).