Everyone knows that a good interface is a good thing for a Java program. Interfaces help keep your program flexible and loosely coupled while also enforcing a solid contract between your objects.
But like everything else, too many interfaces are too much of a good thing. Abusing interfaces makes your code hard to follow. There can be too much code hiding, it becomes a burden to have to remember which implementation of your interface is being used. You can get to an explosion of files due to each class having an interface defined. This is one mistake I've been making lately. It's time to define some guidelines:
1. Don't use "Impl" in the class name.
If you can't think of a good descriptive name for your interface, maybe you shouldn't be defining it. I've found that for each class I have named MyInterfaceImpl I only ever have one implementation and that it probably would never make sense to have another implementation. Later on, if you do create a new implementation, a good name will probably also reveal itself. Refactoring to use the new interface is pretty straight forward.
2. If your interfaces keep changing, maybe you're better off without it.
An interface that is constantly changing may indicate that it is too fine grained. Maybe you can change that interface to use more general terms, or maybe you want to ditch it completely till it reveilles itself later.
3. Keep the interfaces small.
Noone wants to mock your 50+ method interface. (Yes, I'm looking at you ResultSet) Your interface should fit on an index card. If it can't, ask if you really need it. Is it too fine grained? Can you generalize it or break it up?
Dispite all this, remember that interfaces are still your friend. If you can cleanly define one, by all means do it. Just don't over do it.
