Java Class Naming Conventions
Ok, I'm about to go on a rant, because I come across something regularly that really, really, REALLY irritates me:
Whenever you see a class that implements an interface SomeName, and the name of that class is SomeNameImpl.
Guess what folks, EVERY implementation of an interface is an 'Impl'. If you suffix 'Impl' at the end of your class name, you're being short sighted and portraying a potential lack of understanding of Interface-Driven Design: that you can have more than one implementation.
What if you ever create a new implementation? What if, when testing other components, you create a TestSomeName implementation or a MockSomeName implementation? Then the SomeNameImpl doesn't make much sense anymore, does it? It could be a cause of confusion as to why you have more than one 'Impl', or, worse, perhaps it might make people think that you should only ever have one 'Impl'.
Instead, if you need a default implementation, and can't yet think of other cases where you might have other implementations, just call it DefaultSomeName. Then you're telling the world, "Hey, this is our default implementation of this interface, and if any more ever are needed, we can create them, prefixed with a more meaningful name.".
Yes, I'm an OO naming zealot, but you'd be surprised at how this little change, in conjunction with other 'trivial' changes, make code more readable, easy to understand, and most important, adaptable to change over time.
September 24th, 2009 - 15:15
I really hate that *Impl stuff in APIs and libraries, but i never found the perfect naming strategy. You did. Thanks. Your approach is way better.
December 9th, 2009 - 12:33
I do agree to some extent but I tend to use a different package to group implementations. For example, i might have a dao, dao\jpa, dao\hibernate package with classes named SomeDao, SomeDaoImpl, SomeDaoImpl.
For model objects I would tend to just use the ModelObject and ModelObjectImpl convention as there is really only every one implementation.
I also use the naming convention that you have outlined in other situations, for example naming Strategy implementations.
Overall, I would say all these naming conventions have merits.
John
December 9th, 2009 - 14:46
@John
I’ll guess we’ll have to disagree a little
I believe that distinguishing implementation strategies by a package name alone is an inconvenient solution. When you’re looking at source code in a file, and see a
UserDaoImplreference, when was the last time you looked at an instance’s fully qualified class name to understand why it exists? I personally wouldn’t want to do this.Also, most OO conventions prefix more specific information to the class name – not suffix it (e.g. *Impl), for good reasons that correspond to natural language tendencies and make code easier to read.
That is, HibernatUserDao, JpaUserDao, CachingUserDao, etc are all easier to read and easily distinguishable compared to UserDaoImpl. Referring to a fully qualified package name to easily identify the implementation purpose is not as nice IMO.
I’ve also found that segmenting package names based on core application concepts (
com.company.remoting.*,com.company.messaging.*, etc.) instead of implementation technologies is more resilient to change over time. Libraries come and go, but an application’s data model and core architectural concepts change the least frequently. This translates into a fairly stable source tree that doesn’t have to be refactored as often as one that doesn’t employ these principles. Moving packages, although easy enough with good IDEs, translates to many files touched during refactoring, and adds a lot of noise to change history, which in turn makes it more difficult to see the *real* impact of a change. There are other repercussions too, but that kind of gives you a foundation for my reasoning.My recommendation is to always keep OO naming clean and consistent – if one uses the prefix convention for Strategy implementations, IMO there is no good reason not to use the same convention for all classes. I think it is confusing to mix naming conventions across the code base.
The best advice I have for anyone writing implementations are my following “Golden 3″ OO naming rules:
1. Classes are always nouns. No exceptions.
2. Methods are verbs or verb clauses. No exceptions.
3. Interface implementations or subclasses prefix their implemented interface name or parent class name, adhering to natural language principles and being able to immediately understand the class’s purpose. (UserDao -> HibernateUserDao, JdbcUserDao, etc).
Cheers,
Les
April 26th, 2010 - 17:06
Hi. I ran into a situation that I’m puzzled.
I have an Interface: ClassName
I have a default impl: DefautClassName
I have an strategy for this impl: DefaultClassNameStrategy
Now I default impl for this strategy: DefaultDefaultClassNameStrategy
???
I believe that the strategy is very specific for the DefautClassName, other implementations of ClassName would not, might not use the same strategy.
Therefore I believe that the strategy should be attached to an implementation rather than generic interface…
But I can see people complaining in my team: DefaultDefault…???
Suggestions?
June 6th, 2010 - 13:58
@Pedro, I assume that your DefaultClassNameStrategy is an interface and DefaultDefaultClassNameStrategy is a concrete class. In this case having DefaultClassNameStrategy as an interface is not a good idea. Instead I would have a Strategy interface that defines common behaviour for all strategies and have DefaultClassNameStrategy as a Strategy implementation for DefaultClassName class.
For example,
interface Sort
class DefaultSort
interface Strategy
class DefaultSortStrategy
Max.