Vanilla interface implementations. What should I call it? [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Because this question may lead to opinionated discussion, debate, and answers, it has been closed. You may edit the question if you feel you can improve it so that it requires answers that include facts and citations or a detailed explanation of the proposed solution. If edited, the question will be reviewed and might be reopened.

Closed 10 months ago.

Improve this question

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?

• Doc Brown: That's a Java problem. In the .Net world, the interface would have been called IUserDao, so an implementation can be called UserDao. To be fair, the I prefix brings its own set of issues.
• Doc Brown: See Interface naming in Java on Stackoverflow (which was closed as being too opinionated, so don't be astonished when this happens to this question again).
• Jory Geerts: Are these classes in the same package? If not, naming both UserDao seems fine, the package will tell you what you're dealing with.
• Philip Kendall: If there's actually only one implementation, just remove the interface. It adds no value.
• Greg Burghardt: You might be interested in reading Do I need to use an interface when only one class will ever implement it? - it might be relevant to your current conundrum.

Answer 1

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.

• Alexander: @SergeyZolotarev What's the purpose of the interface then? What are the possible implementers?
• Alexander: If it's just a POJO of data, there is no behaviour. There's nothing to be swapped out. There's nothing SOLID about that, one way or another.
• Greg Burghardt: @SergeyZolotarev: I think what Alenxander is getting at is if this interface just belongs to the application and there is literally one and only one implementation, then don't use an interface. This changes, however, if you want to write unit tests for code that needs access to data. Then you have two implemenations of the DAO interface: the database implementation, and a mock or stub for testing purposes.
• Alexander: @SergeyZolotarev I do believe you're misunderstanding the principle. You're following the letter of the law, but not its spirit. Inverting dependencies with interfaces isn't done for its own sake, it's done in pursuit of a generally-worth-while goal: to make it easier to swap in implementations. But that only makes sense in a context where multiple possible implementations are even possible. For example, you could abstract Math.sqrt() behind an interface, but that wouldn't make sense: there's only 1 sensible implementation of sqrt(), and it's Math.sqrt(). Likewise, you're using...
• JimmyJames: "Absolutely not. It would be confusing. No-one would bother checking the types' fully-qualified names" I think you might be too quick to dismiss this idea. I would agree if developers are working in notepad or something but who does that? In any decent Java IDE. you can see the qualified name of a type by hovering over it.