So, this is my last planned post on antipatterns, but it was this antipattern that sparked me into writing the mini-series in the first place.
It all started with Ryan and I doing some work on Idea Group Rules a few weeks back. We dived in a little, and suddenly my fury was enflamed. I noticed that this functionality was filled to the brim with my second least-favorite “type” of class, the “Helper” class. (My least favorite are “Manager” classes.)
Nearly every time that I have come across one of these “Helper” classes, the class just doesn’t mean anything.
Our Helpers are just a lump of code.
Unnecessary and redundant navigation paths in the course of development, highly transient associations of a particular class with another one, presence of stateless classes, occurrence of temporary and short duration objects/classes or classes that exist only to invoke other classes through temporary association
That explanation is bit wordy, but I think that the key words in there are “highly transient”, “stateless”, and “only exist to invoke other classes”. They are just little bits of code that flit in and out of existence, push some objects around mysteriously, and make little sense in terms of the rest of world around it.
I will be the first to admit that Object Oriented Design is hard to do and takes some time. I will also readily admit that we are often pushed to get things done, or feel pressured to just add that one line of code and not think about that yucky legacy code. By adding (or enhancing) these Helpers we are just increasing our code debt, and making it even harder for the next person to figure out what is going on…
For those of you who remember the last antipatterns post may wonder what is the difference between Managers and Poltergeists. Well, there is no difference really. Our Managers are just Poltergeists that are seriously out of control.
Manager and Helpers are symptoms of the same problem: a need to focus on what our TIM/HIP/IDS objects mean and how they interact with each other.
It is hard to do, but let me see if I can start with one tip to get us all moving in the right direction.
Jason’s Object-oriented design (OOD) Tip #1: Get the name right.
Think long and hard on what you are creating and make sure the concept fits into the domain of the rest of the objects. Ask somebody if the name makes sense to them. Remember that I am always there to help you if you need some to talk through it when you get stuck.
Now, I do NOT mean get the name right the first time. You may not, and that is okay. Get it right the next time.
Also, do not be so naive to think that the name will never need changing. All of our codebase is growing, and what is called an Idea today, might be a Basket tomorrow…
Naming applies to classes, methods, fields, and really anything in the code. If you see something that has gotten out of sync with the current naming standards, fix it. There are so many tools in Eclipse to make renaming trivial.
Let us try to get the names right first, and see if that starts to push through the right structures and relationships for better code.