Monday, November 24, 2008


In the previous post I had said that it may not be a good idea to have static attributes in your class. The Singleton design pattern also uses a static attribute to hold the Singleton instance. Even though there are valid uses of Singletons, lately this pattern has come under considerable attack. Here is another page on the Portland Pattern Repository Wiki, that outlines a practical problem someone faced while using Singletons.

Google has an open source tool to detect Singletons. They call it the Google Singleton Detector. They have identified 4 types of Singletons, namely: Singletons, Hingletons, Mingletons, and Fingletons. You can find definitions for all the funny _ingletons on their wiki, but for those of you too lazy to visit the wiki, I will quote them here:

A class for which there should only be one instance in the entire system at any given time. This program detects singletons which enforce their own singularity, which means they keep one static instance of themselves and pass it around through a static getter method.

Derived from “helper singleton,” a Hingleton is a class which turns another class into a singleton by enforcing that class's singularity. The offending class is the Hingleton, which "hingles" the other class.

Derived from "method singleton,” a Mingleton is a class which has any static method that returns some state without taking any parameters. Many will consider these edge cases and not want to report on them.

Derived from "field singleton,” a Fingleton is a class which contains static fields. Many will consider these edge cases and not want to report on them. The idea is to use this tool to identify and remove all the _ingletons from the code.

Here is a very good blog post by Misko Hevery explaining why Singletons should be avoided.

And here is a video by Misko Hevery on Global State and Singletons,

Wednesday, November 05, 2008

Using static attributes in Java

As you will probably know, the 'static' keyword in Java is used to denote fields, methods, and inner classes that do not belong to any instance of a class. They belong to the class itself and can be accessed when the class is loaded. In this post we will focus on static fields and very briefly discuss pitfalls of their usage.

Static fields are used for a variety of reasons:
  • To define constants
  • In the Singleton design pattern
  • As global stores for application wide settings
  • For mapping default objects (like formats) with Strings
  • Several other reasons depending on the requirements
A few days back I was reviewing some code, and I realized that mutable static fields were being used in way too many places. This can make the code very brittle.

When an object has a mutable static field, for all practical purposes this becomes a global variable, and thus has all the pitfalls of global variables. Some object might change the value, and another object that was depending on the old value will behave inconsistently.

An overuse of static fields is a code smell. If you use FindBugs for code analysis, it will catch such instances. FindBugs has several categories of bugs for static fields:
A perfectly valid use of static fields are constants, like the one shown below.

However, there are several uses of static fields that border on making your code unstable. In future posts I will discuss various ways in which static fields are used. I will also discuss potential pitfalls of the usage and how to avoid such situations.