Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com

Mr. Happy Object teaches static methods

When to choose static methods over instance methods

By Tony Sintes, JavaWorld.com, 11/21/01

  • Print
  • Feedback
.

Page 2 of 3

When you declare a method as static, you define that method as being a class method. A class method applies to the class as opposed to any particular instance. The behavior instigated by a class method does not rely on the state of a particular instance. In fact, a static method cannot rely on an instance's state since static methods lack access to this reference. Instead, the behavior of a class method either depends on a state that all objects share at the class level, or is independent of any state at all.

Let's add the following definitions to the original MrHappyObject: 

private static int _instantiations;
public MrHappyObject() {
    _instantiations++;
}
public static int instances() { 
    return _instantiations;
}


instances() is a static method. The instances() method returns the number of MrHappyObjects that have been created. The number of instantiations is independent of any particular MrHappyObject. Instead, MrHappyObject tracks the number of instantiations at the class level.

Again, this example is a bit contrived but it demonstrates an important lesson: Class methods instigate behavior that is independent of instance state. instances() returns the number of instances regardless of whether obj1 is happy and obj2 is annoyed. The instance state is simply irrelevant. Any method that is independent of instance state is a candidate for being declared as static.

Note that I say "candidate for being declared as static." Even in the previous example nothing forces you to declare instances() as static. Declaring it as static just makes it more convenient to call since you do not need an instance to call the method. Sometimes you will have methods that don't seem to rely on instance state. You might not want to make these methods static. In fact you'll probably only want to declare them as static if you need to access them without an instance.

Moreover, even though you can declare such a method as static, you might not want to because of the inheritance issues that it interjects into your design. Take a look at "Effective Object-Oriented Design" to see some of the issues that you will face.

Anyway, simply counting the number of instantiations is a fairly useless example -- it's probably not something you will do in your day-to-day coding. However, sometimes you will want to use statics.

Static methods prove useful for creating utility classes and factory methods. (See "Factory Methods" for more information.)

A utility class simply contains static methods and no public constructor. Utility classes are not meant to be instantiated. As Joshua Bloch points out in Effective Java Programming Language Guide, utility classes have earned a bad reputation because they are easily abused and can lead to procedural programming.

However, utility classes do have valid uses. Take a look at java.lang.Math, java.util.Arrays, and java.util.Collections; each is a utility class. These utilities group related methods on primitive values, arrays, and interfaces. These related methods are placed in these utility classes since they cannot go anywhere else (you can't place methods into a primitive, array, or interface after all!).

  • Print
  • Feedback

Resources