As a follow up to my last post here are some more common Java prefixes/suffixes.
By the way, have you subscribed to the new blog location yet? http://blog.joda.org/feeds/posts/default
More common Java prefixes and suffixes
The last post focussed on class names in the presence of an interface.
SimpleFoo were my choices, with
FooImpl being ones I rejected. But there are lots of other common naming patterns used in Java.
The purpose of these naming patterns is to increase the readability of the codebase as a whole. This is very similar in concept to other coding standards like "no tabs" or "braces at end of line". Its also part of my belief in doing the best we can when writing long-lived code to help those in the future who will read, use and maintain the code.
So, here are some additional naming patterns:
Foo - The basic named concept should always have the best name (for this blog, it could be a class or interface).
FooUtils - A set of utilities that support usage of Foo. This is particularly common with interfaces, but does not have to be limited to them. In some cases, particularly in a hierarchy or group of classes, it can make sense to separate out common utilities, leaving just static factory methods on the main class. I'll note that a Javadoc annotation to mark a method as a factory is long overdue.
FooBuilder - An implementation of the builder pattern that is used to create an object in a fluent manner. This is especially useful for large, complex objects, particularly when the end result is immutable. Sadly in Java, a builder is quite a lot of effort to write well.
FooManager - I prefer manager to
FooFactory because I generally find that a factory does more than just creation, for example registering a lookup. However, I tend to avoid explicit managers/factories. For classes, I would prefer to see the manager/factory as static methods on the class itself, so this would most often be used for interfaces. However, I tend to find that most of my interfaces either require the user to pick the concrete class or are injected by IoC.
DelegatingFoo - A class that exists as an abstract base to wrap a Foo and add some behaviour by delegation. Most of the time I would say that it is not worth creating the decorating abstract base class, and only having the concrete version as it makes each class simpler to understand in isolation.
FooProxy - A class that stands in for the complete set of data as part of a lazy loading strategy. I believe that this is sometimes used for the delegation case, but I find that confusing.
Fooable - This would be used for an interface where the implementations are in some way related to
Foo. An example would be
Identifiable. In this case, the -able suffix implies that the implementing class "can be identified". In code terms that usually means a single
Note that I haven't covered every last prefix/suffix - there are many more. Sometimes a computer name list or thesaurus is useful.
Some other possibilities are:
FooUtil - I find
FooUtils to be a much nicer name.
Foos - I use
FooUtils, as I would see the plural suffix as a JDK style, as in
FooFactory - As discussed above I find when I do need a separate factory it is usually more of a
FooManager than just a factory.
ForwardingFoo - An alternative to
DelegatingFoo notably used by Google Guava, mostly a matter of preference as to which to choose, but be consistent.
DecoratingFoo - Another alternative to
I should just note that both this and the last post are quite Java focussed. Other languages have different "styles" of coding that naturally result in different naming patterns.
I should also note that most of the time class names should express what makes them distinctive. However, it is sometimes more useful to have a naming convention as it aids learning of the system.
Again, there are no cast-iron certainties in class naming or coding standards in general. However, it is useful to have a common starting point at least within one project.
Opinions welcome as always.