-2

Some may think I'm kidding, but I'm really stuck on this

Suppose you have some UserDao interface that you want to implement

What should you call it?

Here are a few points I'd like to make

  1. I firmly believe a subtype's name should end with the supertype name (perhaps, trimmed a bit if it's long). UserDaoImpl is not an option: it's not a subtype of Impl
  2. SimpleUserDao is not a good pick too. It may be "simple" today, not as simple tomorrow
  3. BasicUserDao is also problematic (though, it's my current pick): it's too similar to BaseUserDao which strongly implies the class is abstract (BaseX is generally reserved for abstract classes meant to be subclassed). My implementation is not abstract

Typically, you base your naming on some characteristic features of your type. However, there are no features at all, it's a "vanilla" implementation that communicates with a relational database in the most boring, straightforward way imaginable. There's no way we're going to ever use fancy no-SQL data stores so RelationalUserDao or something to that effect would raise a few eyebrows in my team, for sure

We don't use an ORM framework. Also, our DAO implementations are not coupled to any particular RDBMS (same implementations can hit both Oracle and Postgres DBs)

So what should I do?

Sergey Zolotarev
  • 1,948

1 Answers1

5

While I think this is fundamentally opinion-based, here is how I would approach the problem.

Typically, you base your naming on some characteristic features of your type.

You are on the right track. Keep going...

However, there are no features at all, it's a "vanilla" implementation that communicates with a relational database in the most boring, straightforward way imaginable.

Juuuuuuuust missed it. It communicates with a relational database. Think in terms of this characteristic. Which database? Are you using an ORM, and if so, which ORM? Some options to consider:

  • HibernateUserDao — assuming you are using Hibernate ORM. You could easily replace it with the name of a different ORM.

  • OracleUserDao — assuming you are using an Oracle database. Again, you could easily replace it with a different database to get the same effect.

  • UserDaoImpl because Java. And that's how the community does things. Consider it a quirk or idiom of the people who use the language. This is my least favorite option, but I can't think of a Java developer that would misunderstand it. The Principle of Least Astonishment can be your guide, worst case scenario.

Really, naming based on some characteristic of the type is usually a good strategy. The challenge is thinking that this type is "vanilla" and therefore has no characteristics. I would flip the idea around: the UserDao interface is "vanilla". What characteristic of the implementation adds flavor? It doesn't need to be something exceptional. It can be as simple as DatabaseUserDao.

Jory Geerts, in a comment on the question, also has good advice. If the interface and implementing class are in different packages, use the same name!

Often times the hardest part of naming things is to not over-think the name.

Greg Burghardt
  • 45,304