How to Write Constructors Your Colleagues Will Hate Refactoring
A three-step process to code smell hell.
You are about to quit your job and want to leave a lasting impression? The following rules will demonstrate just how much you care about what you do (or did). It’s this subtle way of signing pieces of source code that keeps people talking about you.
Just have a look at this piece of code. It just screams, “refactor me”.
Rule #1: Delete All Secondary Constructors
Secondary constructors, or convenience constructors (as the Swift folks call them), provide alternative ways to obtain new objects. They provide default values for parameters that are not part of their parameter list when calling either:
- the designated constructor
- another convenience constructor
Here is an inconvenient truth (pun intended): nobody cares about your good intentions, so go ahead and delete those ugly ducklings. This way, the sucker who creates the object has to take care of all parameters and potential type conversions.
Rule #2: Have More Than One Primary Constructor
Primary constructors, or designated constructors (in Swift), initialize all fields of a given class. All other constructors redirect to the primary constructor to eliminate the need for code duplication. Unlike Kotlin, Java doesn’t give a rat’s ass about how many primary constructors you have — and neither should you!
A class in Kotlin can have a primary constructor and one or more secondary constructors.
Rule #3: Include As Many Side Effects As You Can
About a month ago, I was refactoring some legacy code and guess what I’ve found: a new Thread(this) statement inside a constructor. Why haven’t I thought of that? That’s like going to your favorite Italian restaurant and getting a pizza — without even ordering it. Never let the user decide when to call a method — call it for them.
So having code with side effects in your constructor is a gift that keeps on giving:
- Objects always execute the code so consumers cannot defer execution
- Consumers need to change their implementation if the behavior of the constructor changes. So keep them busy.
- Code in the constructor runs on the calling thread
- And my favorite one: constructors can throw exceptions to terminate object creation. That can even cause security issues, called finalizer attacks (see Java Secure Coding Guidelines, Section 7–3 / OBJECT-3). How cool is that?
Conclusion
If you don’t care about your colleagues and profession, follow the rules above. I guarantee a lasting impression.
Now, if you’ll excuse me: I have a desk to clean.
Other Programming Articles you may like
10 Things Java Programmer Should Learn in 2019
10 Programming languages You can Learn in 2019
10 Tools Every Java Developer Should Know
10 Reasons to Learn Java Programming languages
10 Frameworks Java and Web Developer should learn in 2019
10 Tips to become a better Java Developer in 2019
Top 5 Java Frameworks to Learn in 2019
10 Reasons to Learn Python in 2019
10 Testing Libraries Every Java Developer Should Know
