Time to abandon pattern name suffixes?

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. FooFactory. BarController.

Wouldn't it make more sense to find more concise, speaking names instead?

Comments

[Sander Hoogendoorn]

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?

[rhymes]

I like Go's take on this, from golang.org/doc/effective_go.html?#...

For instance, the buffered reader type in the bufio package is called Reader, not BufReader, because users see it as bufio.Reader, which is a clear, concise name. Moreover, because imported entities are always addressed with their package name, bufio.Reader does not conflict with io.Reader. Similarly, the function to make new instances of ring.Ring—which is the definition of a constructor in Go—would normally be called NewRing, but since Ring is the only type exported by the package, and since the package is called ring, it's called just New, which clients of the package see as ring.New.

BTW the image is hilarious and so true!

[Alain Van Hout]

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

[Sergei Munovarov]

Classes like AbstractSingletonProxyFactoryBean belong 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.

[Sander Hoogendoorn]

Classes like that should be in the bin.

[Bertil Muth]

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.

[Alain Van Hout]

Forest? ;-)

[Bertil Muth]

Haha. Why not.

[Daniel]

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.