A talk by Kevlin Henney inspired me to remove the
Exception suffix from classes in a project I am working on.
In the context of a checked exception being caught or an unhandled runtime exception, it's pretty clear that it's an exception you're dealing with.
Besides, in that project, all exceptions are in an
exception package. Pretty easy to guess what's happening.
That got me wondering. It's a pretty common practice to append the name of patterns to class names.
Wouldn't it make more sense to find more concise, speaking names instead?
Top comments (10)
AbstractSingletonProxyFactoryBeanbelong in libraries, where they make perfect sense. Client code is a different story though, and I think it's perfectly OK to use different naming scheme within a team.
Classes like that should be in the bin.
I didn't see the talk but, without providing an alternative, I don't get why this would be a good idea.
Most of those names convey a lot of information about the class responsability, so they are useful. What are the advantatges of not using this information, besides shorter class names.
On the other hand, naming can be good or bad, no matter if the classes are named after common patterns or not.
I like Go's take on this, from golang.org/doc/effective_go.html?#...
BTW the image is hilarious and so true!
It's an interesting concept. At least in part, I/we already use that in our team, in the sense that we e.g. only use the 'service' suffix for a very specific subset of usages, while other classically service-suffixed Spring beans are given more direct (and typically shorter) names.
For exceptions in particular, the value of the approach also depends on the granularity of the exception classes. When you have many classes with specific concerns, Kevlin Henney's can indeed be beneficial. When you have generic exception classes(*) that have internal state that reflects the differences in meaning, then there may be far less benefit (though in that case, class names also tend to be shorter already).
(*) whether that in itself is good/bad/not-OOP is a separate discussion
I try to avoid such suffixes like that as much as possible. So, I experimented with using plurals for repositories (in the DDD sense). So, instead of UserRepository we used Users. That kind of works. And I use the names of use cases in code, just like I model them, so ManageUsers, or CreateProfile. But, how about gateways (in the PoEAA sense), so what's the alternative to the UserGateway?
As a further example: for classes that manage other objects, say Trees, and don’t do anything else, I used to write TreeContainer or TreeManager. Nowadays, I call such a class Trees.
Haha. Why not.
By the way, here is the the talk! 👀 🦄