Maybe the static typing - harder to change, so you try to get it right.

Not sure if it's only that - the static typing is more or less cared for by the IDEs and their refactoring tools.

I would like some Java developer to chime in on this.

I think it comes from a too-literal understanding of design patterns. E.g., for the factory pattern the common practice (outside of some well designed APIs e.g., google collections) the common practice is:

  public class Image {
    public Image(byte[] data) {
      // create the image from byte array 
    }
  }
 
  public class ImageFactory {
    public Image createImage(File file) throws IOException {
      // read data then create an image
    }
  }

vs.

  public Image {
    // the same constructor, but then ...
    public static Image open(File file) throws IOException {
      // Do the same thing as factory would do
    }
  }

What's the advantage of the first approach, provided there's no per-instance state (and thus reason not to just use a static factory method) within the ImageFactory class?

At runtime you can provide a different implementation of ImageFactory. For example, a unit test can define MockImageFactory which ignores the filesystem and just returns a canned Image object. If code everywhere calls the static Image.open method, there is no way to redefine it short of editing the source or the bytecode.

To which the counter-argument is YAGNI (the different implementations). There are other ways to do the equivalent of mocking, though the interface / factory approach is popular at the cost of doubling the number of identifiers in play and probably having a geometric effect on complexity.

Good answer. That actually makes sense with the Image example, but OTOH there's still cases where a separate factory class is used where a static method would work.

I think that's one of the reasons.

It's so nice to be able to provide a different GadgetFactory during tests or at different moments that some developers decide it would be cool to have the possibility to provide different factory implementations for every class, just in case they need it afterwards.

Sir, I find your dismissal of my comment rather cavalier. I am some java developer.

My experience is that static typing makes things harder to change, and therefore you try to avoid change by getting it right in the first place. Refactoring tools are not magic pixie dust (wish they were).

Though I use vi + homegrown tools, so I guess I'm not the IDE java developer you were looking for.

I am sorry. That's not what I meant.

But you got exactly what I was going for: a typical Java IDE user would be able to add a lot to the discussion.

While I use Python more than any other language, I write some Java, but can't call me typical either - I use emacs for that.