What's a good example of a static factory method returning instances of subclasses?

Question

One benefit of having a class provide a static factory method rather than public constructors is the method can return an instance of a subclass.

For example, if the class Rectangle had a subclass Square, there could be a static method Rectangle.newInstance(int width, int length) that sometimes returned a Rectangle and sometimes a Square.

What is a compelling example of the benefit of this approach? Students could easily ask in this case why the client didn't call the Square constructor if the width and length are equal. (I can give them an answer to that question, but it would be better to have an example good enough that they wouldn't even ask.)

Edits

For those of you who answered that I shouldn't have a static factory method return an instance of a subclass, I follow the guidance of the great Josh Bloch, who considers that a positive use of static factory methods (Effective Java, Item 1).

For those who told me that a good use of static factory methods is that the programmer can choose their name, which is not the case with constructors, I already know and teach that.

Answer 1

My go-to for programming patterns these days are games, because it is easy to create compelling examples.

It has never occurred to me before to have a factory return its own subclass, so I apologise if I turn out to be off the mark here!

However, the use I immediately thought of was an enemy factory that only provides instances of its subclasses, randomly (or by some rule) choosing which enemy to generate. This still fulfills the purpose of the factory, should be simple to understand, and allows you to keep some sort of List<Enemy>.

Answer 2

I don't have a good answer to this. However here are my thoughts.

Named constructors

A good use for static factory, is to implement named constructors: Java, C#, C++, et al do not have named constructors. However named constructors can be useful, as they allow you to document different ways of constructing an object. Therefore use a static factory, to create the object. The static factory will use private un-named constructors.

Problems with the pattern

However other uses of static factory seem to be an anti-pattern.

You now have a super-class depend on the sub-class. The sub-class already depends on the super-class.

The static constructor can also easily break the single responsibility principle: the class is a thing and a factory for a thing.

Answer 3

I would first ask what that hierarchy buys you overall in an application and, more important, in the student understanding.

In general, I find concrete subclassing to be problematic and easily abused, as well as confusing.

If you are satisfied that it is essential in some way, then an example could involve the characteristics of some figures coming from a file, or other input, in which the programmer doesn't make the decision about which constructor, but the program has to make the decision on the fly.

But even that suggestion implies that maybe you are thinking "too concretely" about things.

---

I hope I'm not too harsh here with your particular hierarchy, which is fine. But there are people out there who would make Rectangle a subclass of Square since "all you have to do is add another dimension.". Likewise for them a Point has Circle as a subclass, which in turn has Cylinder as a subclass and so on down the rabbit hole. This sort of confused thinking has been around since Turbo Pascal and still appears in some text books.

---

For novices you can also turn this sort of thing into a good lesson on what is "known" at compile time vs what can only be known at runtime. The latter is under control of the program itself and only indirectly by the programmer. This knowledge will serve them well if they ever need to write a compiler, for example.