23

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.

Improve this question
3
  • 1
    See this SO answer for info stackoverflow.com/questions/610458/… Commented Oct 25, 2011 at 2:21
  • When I read code and there is a call to a method, to me it's highly relevant to be able to tell right away that that call cannot read nor modify the state of the object it belongs to. With MyClassName.myStaticMethod(); there isn't even the need to wonder about it for a second. With myVar.myStaticMethod(); you need to see the method's code, and you will always be in this doubt for all calls. Of course different IDEs might make this information easy to retrieve (Javadoc tooltips, syntax highlighting etc.) but I wouldn't rely on that to decide how to write the code. Commented Feb 1, 2018 at 9:48
  • SantiBailors: I'm not sure why you would need to know that. The whole point of encapsulation is that you don't know what it does to internal state, and you shouldn't - the class will do the right thing because it knows what to do. Commented Sep 1, 2022 at 0:28

4 Answers 4

Reset to default
44

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.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

23

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.

Improve this answer

Comments

6

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.

Improve this answer

Comments

4

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.

Improve this answer

1 Comment

If that "super confusing" was a pun, I'm going to have to come over and slap you around a bit :-)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.