Cedric on Interface naming convention:
Some argued that using ‘I’ adds noise. Usage of ‘Impl’ suffix takes care of this problem too. I wonder if the author of this remark noticed the irony of this comment
Neeraj Kumar left a good comment on this, which is similar to what I was thinking: Both “I” and “Impl” add noise - the question is which one is less evil.
Here’s why I prefer “*Impl”.
- The interface is part of the core code. Using a container like Spring, implementations are hidden away in config. So “Impl” is less invasive than “I“.
- Furthermore, it’s easier to search for “Impl” than “I” in an IDE, especially when some code will use the “I*” convention and other code won’t (ie most external/legacy code).
Actually, I usually prefer Impl’s to tell me what kind of Impl. Even if there’s only one Impl, it’s sometimes useful to provide a hint about what other Impl’s might be possible. To use the canonical example, I’d rather see BubbleSortImpl than SortImpl. Also worth noting that if you’re doing TDD, you probably have mock implementations as well; with JMock, they’re not defined classes because they’re instantiated using dynamic proxy. However, they are present, so I like to keep in the back of my mind that the class name “XImpl” is really shorthand for XProdImpl.
1 response so far ↓
1 Anonymous // Jun 14, 2005 at 8:47 am
There is never a need to use an “Impl” suffix. Doing so indicates that the code has a poorly thought out system of names. The warning sign is that Impl is an example of duplicated code: “class FooImpl implements Foo” repeats the same information twice in one line and so breaks the “Don’t Repeat Yourself” and “Once and Only Once” principles!
Impl classes are usually used when the interface itself is badly named. One can clearly defining interfaces from classes by naming interfaces after relationships or capabilities and classes after concrete things or implementations.
Leave a Comment