Inverse of Extract Interface refactoring

Question

I'm working with a Java project that has several interfaces, many of which have only one implementation. (See related question)

For a given revision of the software, one could think this acceptable because the interfaces were some plan for future extensions. However, when I look at the 200+ revisions over several years, those interfaces never had more than one implementation, (nor were they used in unit-testing).

It seems that in these cases of probable bloat (YAGNI) owing to the Interface Anti-pattern, it would be useful to apply the inverse of Extract Interface. However, Inline Class (the supposed inverse according to refactoring.com) is not what I'm referring to.

What's the name of the refactoring that removes an unused interface, substituting the sole class that implements it?

Answer 1

Merge Interface (on the expectation that the class has at least some other members)?

As suggested, Merge Interface and Implementation would be even more descriptive. I don't recall ever seeing it in an IDE.

Answer 2

Going by the naming conventions I've seen (especially on refactoring.guru), I'd recommend the simple description of Replace interface with class. As you describe it, it's functionally equivalent to inlining, but I agree that it doesn't quite make sense to be called inlining (for both Inline method and Inline class, you both start and end with methods/classes, whereas you're getting rid of the interface when you're done).

Like you say, it should be pretty straightforward in its definition:

1. Find all calls to the interface. Replace these with calls to the implementing class.
2. Delete the interface.

As for the rarity of it, I suspect it's partly because interfaces are typically introduced for a specific purpose. This means pretty much the only time you're going to need to replace them with the implementing class is the sort of situation you describe: falling foul of YAGNI because an interface was introduced ready for multiple implementers, but they never materialised, so you're just left with a single concrete class using the royal "we".

I'd definitely say it's good practice to clean up with the refactoring - apart from the fact that future implementations may have different ideas of what should be included in the interface, there's also other trade-offs that interfaces have, such as indirection making things a little more complicated and time-consuming to debug.