In theory naming patterns are supposed to aid in understanding the
function of a class. Unfortunately, this isn't always the case. With
poorly selecting naming patterns, the results can be quite comical.
Take for example (from a real project) the
IAdapterAdapter.java.
What is an IAdapterAdapter, you ask? Well, in this system there
is a concept of an Adapter. What it specifically does isn't
important, it might as well be a Frobnotizer, in which case we'd have
an IFrobnotizerAdapter. It was realized that there may be many things
that need to be adapted (frobnotized) and that there wouldn't be a
single implmentation. In fact, most likely it would be another
existing component that wanted to do the adapting (frobnotizing).
Nodding to the adapter
pattern, an AdapterAdapter class was made to provide some base
functionality useful for adding to components that needed adapter
(frobnotizer) functionality. Being good coders we know that it's
better to work with an interface, and decided that our
FrobnotizerAdapter, er.. AdapterAdapter, needs an interface, which is
kindly marked with vaguely Hungarian I becoming an
IAdapterAdapter. It's really quite obvious, isn't it?
What's wrong here? There are several big problems. Let's start with the
base name - Adapter. Even if you never thought you would need to adapt
an adapter, it's a poor name because it conflicts with your naming
convention for (non-frobnotizing) adapters. I don't much care for the
adapter naming convention here, primarily because it's not really
an adapter. If you are going to name something after a design pattern,
you should at least pick one that matches.
Finally, there is that dreaded ISomethingOrOther convention for
interfaces. I can't figure out why people think this is clever. I
follow
the principal of least adornment, which suggests that the most
external class should have the least adorned name. Why? The base
name is what we focus on. When you see IColor, you think "Color". In
your code, you will want to work with Color objects and will try
gravitate towards that instead of the IColor interface you want people
to focus on. The interface should be the focus and the class is just
an implementation detail. The implementing class should really should
warn people away. I think the Impl convention is nice, at
least in this respect. A class named ColorImpl might as well have a
big "No Soliciting" sign on it. Anyone knocking is probably doing so
for a reason.
The moral here is to be careful with your naming conventions. Try
and choose good ones, but be willing to admit when they are breaking
down. Like coding conventions, they are general guidelines and not
hard rules. I know many people will disagree with me on this point
and insist that coding conventions are the only thing standing between
the code and complete chaos. But I don't mind bending the rules a bit
when they are doing more harm than good.
Previous Topic
