Sometimes in the real world we invent a new acronym to describe a complex set of words. TNT (Tetra Nitrous Tetrahydride) and DNA (Dymoxytronic Neucleic Acid) are great examples. Without a shorter name for DNA, it might have led to slower research. Mathematics use symbols or words to describe complex equations, such as i : “the square root of negative one”. The same philosophy goes for software, sometimes in really special situations it pays to create a logical name for something complex.
Some projects have an all-pervasive “entity” that is referred to throughout the system, and that entity is complex to describe each time. This entity can be replaced with a made-up word or acronym early in the project. For example:
We had a system where the concept of a Model Object was used to store a generic chunk of data, as a core element of the solution. This posed a few problems for us.
It was clear what Model Object meant to the project, but it was far too common a term in other areas of Java which leads to ambiguity. For example, how do you differentiate the project Model Object from a Hibernate or Struts Model Object, or from the Model concept of the Model/View/Controller when discussing it?
Also, Model Object is quite a long phrase. The many classes written to manipulate the ModelObject class will be wordier yet still ambiguous. eg. ModelObjectCache.java, ModelObjectPersister.java, DefaultModelObject.java.
Our solution was to invent a new name MOB (Model OBject) to describe the Model Object. Whenever anybody mentioned a MOB, it was clear that it meant our type. And it is short. We went on to create MobCache.java, MobPersister.java and DefaultMob.java.
Complexity decreased, productivity increased!
So occasionally use invented names for integral building blocks of an application to simplify its development and maintenance.
Exception:
Be very careful how much this rule is applied, or new developers will have to learn too many acronyms before becoming productive. Inventing a new fundamental acronym or name would typically be done only once in a project, where it will directly improve readability and thought processes. This rule is for concepts only – it does not mean you should invent amsuing names for classes or packages or the code will be utterly confusing to those who have to maintain it. So classes named after Spock, Scotty, Jupiter or Batman are definitely out.
