Using static to create an immutable object

Question

I was reading on this software engineering page about the use of static methods. However, I'm confused, and maybe it's about the context in which it talks about static. The idea is, that static is really bad for testing and shouldn't be used.

When creating immutable class, sometimes the constructor is private and a static factory is used to create the object. Even Java's own documentation supports the use of a factory when creating immutable objects.

A more sophisticated approach is to make the constructor private and construct instances in factory methods

Answer 1

If you are making an immutable DTO, where you simply bundle up a bunch of properties and that's it, such as your example, then just use a public constructor.

Factories are for situations where object construction is complicated, expensive, where you return different types based on the input values, or other "logic intensive" situations. Simply storing a handful of values is not one of those situations.

Answer 2

The idea is, that static is really bad for testing and shouldn't be used.

Yes static code makes unit testing harder (sometime impossible). But I would not go as far as saying static should not be used. There are some cases where static methods are fine to use.

Here is why it makes testing harder. Consider this code you have in your question:

public static Weapon Sword(String name, damage){
    return new Weapon(name, damages);
}

Wherever that code is written is permanently coupled to Weapon. Without the Weapon class, no one can compile the above code. No one can substitute a mock object instead of Weapon to test the class where this code appears.

The easiest rule to remember is that as soon as you you use new keyword to instantiate an object of class X, you have made your class coupled to X and unit testing will be not be possible unless you were to change the code in class X (but that would be a very odd unit test because you would need to change the code in class X back to the real code before sending it to production). Please read more here about unit testing static code.

Answer 3

The idea that static instances (or static functions that have some state associated with them) are bad comes from the argument that says that having those is the same as having global variables (global state - see this for more info on why that's bad).

A constructor is just a special kind of function - it's not something that manipulates global state in this sense. You don't need to have a reference to an instance to call it (even in prototype-based languages), so in a way, you can think of it as being static, or behaving as if it's static. From that point of view, having a static factory method is no different. So the global state argument doesn't apply here.