Static vs New Object

Question

public class A
{
    public void doSomething()
    { /*code*/}
}

The doSomething method is in no way referencing the state of object A so by that logic it could be static.

What is the difference between option 1 and 2:

1. new A().doSomething()
2. Assuming doSomething is static; A.doSomething()

I want to say that option 2 is better because the first would be creating a new object everytime it is used.

Answer 1

Option 1 creates a new instance of A in order to call the method doSomething() which according to your question it sounds like it doesn't need to (there is nothing in doSomething() that requires an instance of A). Option 2 skips the unneeded instance creation while producing the same effect, so it would be better (assuming that this is the only design requirement). Now there might be other reasons to not use static, for instance, if A implemented in interface, or if the nature of doSomething could conceivably change at some point in the future where it might need information established outside of it.

Answer 2

You're entering into the "expression" part of programming. What do you want to express?

Three cases are under discussion:

1. your method is an action any A can take, or a message any given A can respond to,
2. your method is an action the class of A's should respond to, and
3. A is a singleton, and your method receives messages for that singleton.

Now ask yourself: what do you intend to express? Is "doSomething" appropriate for the class A? Or is it, rather, just something that every instance of A should be able to do, regardless of its internals? Does "A" represent something which, in the world of your program, should only have 1 instance?

As a practical point, you can't overload static methods, so aside from "expression of intent", you need to be aware of that.

A lot of basic utilities fall in the "static" category, and there's a (small) time penalty for creating a new instance of A, but overall--you're most likely to get it right, and more importantly, the later life of that method will have the least impact on other code, if you can answer the questions above correctly, and thus pick the implementation that matches the intent of the object most closely.

Answer 3

There is a third option.

Create one instance of A, then reuse it for each call.

e.g., in the class or Application that is using A,

A myA = new A();  // you can consider making this static if that makes sense...

... then, as needed later on ...

myA.soSomething();

The advantage is that, in the future, if you do need to change the behavior of doSomething, you could change the first line to

A myA = new SubclassOfAThatDoesSomethingDifferent();

Or, if doSomething() eventually does need to reference the state of A, it can.

Answer 4

You'd have to declare the method as static:

public class A {
    public static void doSomething() {
        // code
    }
}

This allows you to do A.doSomething() and also prevents doSomething() from looking at any instance methods or fields (because how would you know which A instance to use?), which shouldn't be a problem if it doesn't reference them anyway.

See The Java Tutorial's Article on Instance and Class Methods for details.