[alzoid]

We had a vendor deliver some C# source code that was exactly this. A 'repository' interface that had a concrete class that called an abstract data access class etc. A path of 3 or 4 calls to run a SQL statement against a MSSQL Server. There were no requirement for this.

The Gang Of Four design patterns are great when you actually use them to solve the problem they were designed for. I worked on a product that grew in complexity and a factory was needed. Implementing was easy in Netbeans - right click and extract interface and provide the new implementations and the creation logic.

I'm not sure when using patterns all the time got so prevalent. As the saying goes, when all you have is a hammer, everything looks like a nail.

[vsareto]

That's pretty typical in C# land (another is service->repo->data access with DI/interfaces for each). Very likely the dev had that pattern down as a reflex. There was no consideration on their part because they already knew a solution that worked. They could move on to the other problems or requirements.

As another poster elsewhere said, the annoying thing is only the single implementation for the interfaces, and no real code that makes use of the abstraction. It only really alleviates other devs from asking "where are the interfaces for these classes?"

[malka]

Using an interface forces one to think about a clean API, that does not rely on internals.

[imtringued]

That doesn't make any sense. Java already has private and public as modifiers. The only meaningful difference is that interfaces prevent you from using private. That's such a shallow benefit. If you have the discipline to create interfaces you also have the discipline to use the right modifiers. The reality is that all those interfaces will just mirror the class and cause extra friction even though polymorphism is never needed.

[lmz]

In theory. Sometimes it only has one implementation and the details leak through.