One of the more interesting pieces of programming advice I have received in my career relates to the naming convention you use for your objects. Typical OOP paradigms suggest that you name objects after what they do. However there is one caution that must be respected to this rule. Avoid naming items that end in ER. Sounds silly right? Let me explain.
The intention here is not to go off on some religious vendetta about naming conventions. That is not my intent. Rather I have found that in my time as a programmer almost every time I come across a class or object ending in an ER there is almost always a better name for it. A better name that allows the design of the objects to be more encapsulated. A better name that enforces better rules and prevents spaghetti code.
Before we fullt dive in – let’s take a look at a simple example. Let’s image that you have a Loader class. The name sounds reasonable doesn’t it? It loads stuff for you. The problem here is that it’s scope is too broad. Is it a Photo Loader? a Stream Loader? Maybe instead a name such as LoadStream or LoadPhoto could have been used. Our goal as programmers is to create objects that describe what they are, and then bind behavior to them. If we find ourselves focusing on what they do and then try to decide what data they’ll need, we will soon end up with a very ugly pile of soup to deal with.
Let’s look at a few more examples:
Managers – Every time I see a manager… I cringe. Literally. This is one of the easier naming conventions to use too. PhotoManager, LinkManager, etc… However a manager is not an object. A manager is a process. If it’s a history of logs call it logHistory, not logManager.
Controllers – This is similar to a manager. I see them all the time. Have you ever worked on an MVC based implementation? Ever single class that represented the “controlling” portion of an MVC application ended with the name Controller. It was redundant and reduced programmers flexibility.
Organizers – Again the focus here is on what it does versus what it is. OOP encourages us to describe what objects are, then we can bind appropriate behavior to them within an appropriate scope.
Reader/Writer – The main problem I have with these types of objects is that it only describes a small portion of the interaction that an object can have. A PhotoWriter is not an object, rather a Photo as an object has functionality binded to it so that it can be read or written.
Now – it’s important to point out that this is a best practice guideline. This is not meant to have you go off on a major refactor that will consume hundreds of man hours. In some instances trying to change these naming conventions once already in place may cause more trouble then it fixes. However these are great guidelines to use when naming your objects when you start on that next project of yours.