What is the problem with static methods?

Many programmers when concerning about OO design usually say: “Static methods are bad because they encourage procedural paradigm”. In this article, I would argue that static methods are not always bad and they have nothing to do with procedural paradigm.

Static-X was an American industrial-metal band from Los Angeles, California formed in 1994.
Static-X was an American industrial-metal band from Los Angeles, California formed in 1994.

Are static methods really bad?

Since static methods belong to classes, not objects, it’s easy to conclude: “static methods is not OOP”. What a naive conclusion! Class or not class, it’s definitively not the factor to evaluate whether something is OOP. OOP is all about behaviors. Class-based style is just a way to implement OOP in certain languages such as C++, Java. Indeed, there is another style so-called Prototype-based which is adopted by JavaScript.

Essentially, a static method still belongs to an object – a special object. This object is automatically created before the main() method is executed, and is named/identified as the class name. For example:

// Here we have a class named Kata and an implicit object
// named Kata
class Kata {
	public static void foo() {
		// ...
	}
}

Any other object x wants to use the Kata object? Simple! Just call Kata.foo(). Clearly, x now depends on the Kata object, right? But this dependency is hard-coded and thus tight-coupled. Let’s suppose object x is instanced from a class X, then every — yes, every — object instanced from X will immediately depend on the Kata object, forever! There’s no way to alternate Kata by another object, like this:

// Do not use static anymore
class Kata {
	public void foo() {
		// ...
	}
}

// Ah, this is Dependency Injection
class X {
	private Kata k;
	public X(Kata k) {
		this.k = k;
	}
	public void test() {
		k.foo();
	}
}

Now it begs a question: tight coupling is good or bad? Not easy to answer! It depends on our context and requirements. If we are sure that Kata is stable and immutable; then go ahead with static methods, no problem; we will obtain their advantages of convenience and good performance. In other cases, don’t use static methods.

Sometimes, we might forget to evaluate our situation, and hence will fall into using static methods without careful considering. Fortunately, TDD is our savior because it adds more requirements to our design in order to make the code to be testable, therefore static methods can be eliminated in certain cases. Nevertheless, TDD is a long story, I will talk about it in another article.

To summarize, static methods are not always bad, be careful when using them. And their problem is the hard-coded dependency, not related to OO or procedural paradigm.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s