I've seen the canonical class/interface naming questions on StackOverflow and read a lot of other opinions on the subject, but I have a related question that I'm not sure is answered in any of those places. I tend to hate either the IInterface or ClassImpl naming conventions because they're unnecessary (given modern IDE's), make the code harder to read, and in many cases the need to use one of those naming schemas seems to imply an incorrect design.
However, I often run into a scenario where I have an interface that I want to expose as part of my API (usually in a separate package), and then I create an abstract implementation of the interface to contain some common functionality that I expect most (but not all) concrete implementations to derive from. For example:
public interface Foo {
public String getBar();
}
public abstract class BasicFoo implements Bar {
private String bar;
@Override
public String getBar() {
return bar;
}
}
In practice I tend to prefix the implementation name with Basic, but what I'm doing is essentially exactly what some folks are using the Impl suffix for: providing a basic/default implementation. I could try a name that implies that it's a Foo backed by in memory storage (for example of Bar), but that always capture all the functionality in BasicFoo. I'm also not convinced that I should throw out the interface and expose the implementation directly because the interface provides additional flexibility and decoupling.
Thoughts on a better way to handle this scenario, or a logical naming convention?