Is calling static methods via an object “bad form”

Question

In a recent question, someone asked about static methods and one of the answers stated that you generally call them with something like:

MyClassName.myStaticMethod();

The comments on that also stated that you could also call it via an object with:

MyClassName myVar;
myVar.myStaticMethod();

but that it was considered bad form.

Now it seems to me that doing this can actually make my life easier so I don't have to worry about what's static or not ^(a).

Is there some problem with calling static functions via an object? Obviously you wouldn't want to create a brand new object just to call it:

Integer xyzzy;
int plugh = xyzzy.parseInt ("42", 10);

But, if you already have an object of the desired type, is there a problem in using it?

---

^(a) Obviously, I can't call a non-static method with:

MyClassName.myNonStaticMethod();

but that's not the issue I'm asking about here.

Answer 1

The bad form comment comes from the Coding Conventions for Java

See http://www.oracle.com/technetwork/java/codeconventions-137265.html#587

The reason for it, if you think about it, is that the method, being static, does not belong to any particular object. Because it belongs to the class, why would you want to elevate a particular object to such a special status that it appears to own a method?

In your particular example, you can use an existing integer through which to call parseInt (that is, it is legal in Java) but that puts the reader's focus on that particular integer object. It can be confusing to readers, and therefore the guidance is to avoid this style.

Regarding this making life easier for you the programmer, turn it around and ask what makes life easier on the reader? There are two kinds of methods: instance and static. When you see a the expression C.m and you know C is a class, you know m must be a static method. When you see x.m (where x is an instance) you can't tell, but it looks like an instance method and so most everyone reserves this syntax for instance methods only.

Answer 2

In my opinion, the real use case that makes this so unreadable is something like this. What does the code below print?

//in a main method somewhere
Super instance = new Sub();
instance.method();

//...
public class Super {
    public static void method() {
        System.out.println("Super");
    }
}

public class Sub extends Super {
    public static void method() {
        System.out.println("Sub");
    }
}

The answer is that it prints "Super", because static methods are not virtual. Even though instance is-a Sub, the compiler can only go on the type of the variable which is Super. However, by calling the method via instance rather than Super, you are subtly implying that it will be virtual.

In fact, a developer reading the instance.method() would have to look at the declaration of the method (its signature) to know which method it actually being called. You mention

it seems to me that doing this can actually make my life easier so I don't have to worry about what's static or not

But in the case above context is actually very important!

I can fairly confidently say it was a mistake for the language designers to allow this in the first place. Stay away.

Answer 3

It might get super confusing when you have an object that inherits from another object, overriding its static method. Especially if you're referring to the object as a type of its ancestor class. It wouldn't be obvious as to which method you're running.

Answer 4

It's a matter of communication. Calling a method on an instance implies you're acting on/with that particular instance, not on/with the instance's class.