Static class that generates instance of itself

Question

What's the downside of instantiating an instance of itself in a static method and then working with this object instead of doing everything statically?

Say I have a class like this:

public class MyClass {
    private String foo;
    private String bar;

    private MyClass(String foo, String bar) {
        this.foo = foo;
        this.bar = bar;
    }

    public static String concat(String foo, String bar) {
        MyClass myClass = new MyClass(foo, bar);
        return myClass.concatStrings();
    }

    private String concatStrings() {
        return foo + bar;
    }
}

The benefit of this pattern is that I don't have to pass around the input parameters to various private methods. The only bad thing I can think of, is that it might be a performance issue to create an object that I don't really need. But with this very simple example I only notice a real difference (in a quick junit test) with a LOT of iterations (i.e. >=10^8) compared to a simple static class like this:

public class MyStaticClass {
    public static String concat(String foo, String bar) {
        return foo + bar;
    }
}

Are there any other arguments for or against this pattern?

If your static utility method needs to be refactored into a class then do it, no downsides. Depending on context it might make more sense to do it in a separate class or in the same class. — Oleg, Nov 29 '17 at 10:33
@Oleg say this is a brand new utility class, not some refactoring. The benefit is, I don't have to pass around the arguments internally. — MonsieurBon, Nov 29 '17 at 10:40
You should not use the singelton pattern in the first place: http://blog.code-cop.org/2012/01/why-singletons-are-evil.html , And No, there is no rule that "service methods" must (nor should) be `static`... — Timothy Truckle, Nov 29 '17 at 10:43
@TimothyTruckle It's not a singleton. Every call to concat() instantiates a new instance of the class. — MonsieurBon, Nov 29 '17 at 10:47
from the callers side it does not matter. Avoid `static` access unless you have a really good reason... — Timothy Truckle, Nov 29 '17 at 10:56
You're passing the arguments into the constructor instead of directly into the private method so I'm not really sure where you are seeing the advantage. — matt helliwell, Nov 29 '17 at 10:58
Try adding more methods that require extra or unrelated parameters. Would you like to pass them all at once in constructor every time in every static method ? It soon becomes a mess. — S.D., Nov 29 '17 at 11:21

score 1 · Accepted Answer · answered Nov 29 '17 at 10:49

I think the problem here is the use of static by itself (is procedural, have some disavantages and it's harder to test). Most of the times this utility with static methods could be replaced by something else using OOP. So, my suggestion:

public class MyClass {
    private String foo;
    private String bar;

    MyClass(String foo, String bar) {
        this.foo = foo;
        this.bar = bar;
    }

    public String concatFooBar() {
        return new Concat(foo, bar).getResult();
    }

}

And the utility class:

public final class Concat {
    private String foo;
    private String bar;

    Concat(String foo, String bar) {
        this.foo = foo;
        this.bar = bar;
    }

    String getResult() {
        return foo + bar;
    }

}

Static class that generates instance of itself

1 Answers1