One thing I’ve inherited in my new work place is a coding standard that requires the “Impl” suffix for every interface implementation. I feel very dirty and ashamed. I’ve long held a very strong point of view here – that if there is not a generalised use of a class’ interface then don’t carry around that interface code. Particularly since embracing new IDEs with refactoring tools I’ve been very strict on this one – don’t introduce interfaces until there is a genuine need. “Impl” is a really bad smell to me. Most of the time the way my design falls out means that the interface name does not match the class name exactly anyway e.g. the FooPersistence interface is implemented by the FooPersistenceService which also implements the PersistenceService interface. Very often the interface name is an adjective – e.g. Startable interface for a Service class. I really don’t like “Impl”.

It’s not entirely that simple however. In this environment the convention applies to service interfaces that are implemented on CORBA. The interface is required by the generated CORBA stubs and skeleton classes. You are only hand-writing one implementation of the interface. What else would you call it? TheRealFooService?

The nice thing about being forced to have interfaces for services is that unit testing is easy – it’s easy to stub or mock the interfaces without any magic. Particularly in the mock testing area there seemed to be a bit of debate (at least a couple of years ago when I bothered to read) about whether people should be able to create ‘dynamic’ mocks of concrete classes. The argument against seemed to be that you should have more clean separation of interface and implementation. To me it seemed that if you did a lot of mock testing then you would end up littering your code with a bunch of artificial interfaces. Don’t discount the cost of maintaining a bunch of worthless interfaces – a little bit in code maintenance but a LOT in code readability.

This led me to a heuristic that I’ve used for a while – if I’m testing component A, I often mock the interfaces provided by component B but rarely mock internal parts of component A. I effectively mock at the edges of components and this works quite well. I also find mock testing quite brittle, and the public interfaces that are used between components tend to change less frequently so my tests do seem a bit more robust in this way.

This does however have the occasional side-effect of introducing some ‘artificial’ interfaces, but I can live with that. I don’t call the implementation “Impl” though 🙂

Martin Fowler talks about Implicit Interface Implementation. I’ve occasionally had the same thought, it would definitely save a lot of false interfaces…