Paid per line programming code? – Why I love refactoring

Earlier this month I’ve started to read a new book called “Effective Java“. Jesse Gallagher mentioned this book as a “must read”. After my positive journey with reading “Design Pattern” (The head first edition) was it no question that I definitely read the sample of “Effective Java”. And yes, after reading the sample, I bought it. (To my colleges at WebGate: Yes be afraid – I have now a new book – Ho Ho Ho).

But reading a book without bring the new knowledge into the daily work is only the half of fun. So where to start? One of the first thing that has attracted me while reading “Effective Java” was the initialization of a Singleton.

A Singleton is an object, which exist only one time in specific context like a jvm, plugin or a XPages Application. The “normal” code to initialize a singleton is the following construct:

public class DocumentProcessor {
private static DocumentProcessor m_Processor;
private DocumentProcessor() {
}

public static DocumentProcessor getInstance() {
if (m_Processor == null) {
m_Processor = new DocumentProcessor();
}
return m_Processor;
}
}

One of the disadvantage of this code is, that this code is not “safe” if you try to create an instance of DocumentProcessor with Java Reflection and modifying the constructor. The other thing that I’m not loving is the amount of code, that I always have to write. But Joshua Bloch explains a simple way with enums to have a singleton look at this code:

public enum DocumentProcessor {
INSTANCE;
}

How smart is this! And not much code. I’m not paid per line of code I write, so it’s not touching my income :). Now you can access with DocumentProcessor.INSTANCE the singleton. It’s very cool, but what, if I have already a lots of Singleton? How can I make that my code will not break the code of other clients (classes which calls my API).

Remember all client classes call the current code (before refactoring) with WordProcessor.getInstance(). I can easy change this in my classes, but external clients which calls my WordProcessor will fail, when the do not have the WordProcessor.getInstance().

The following code is a “defensive” approach which makes this safe to all the other clients:

public enum DocumentProcessor {
INSTANCE;

/**
* gets the Instance of the DocumentProcessor.
*
* @deprecated -> Use DocumentProcessor.INSTANCE instead
*
* @return Instance of the DocumentProcessor
*/
@Deprecated
public static DocumentProcessor getInstance() {
return DocumentProcessor.INSTANCE;
}

This code is not only safe, it gives the other developer also an instruction, how to adapt the new API.

Will I now go to all my code (and it’s a lot of code I wrote each year) and change this all? And what about all the other cools stuff that I will learn while reading the book?

No, that’s not my approach. But I will challenge my code, myself and later the WebGate Development Team with the knowledge. Each code that I’ve to touch will also be reviewed with my new knowledge.

Have fun

Christian