interface Sort
class DefaultSort

interface Strategy
class DefaultSortStrategy

Max.

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?

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 UserDaoImpl reference, 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

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