<p>I would first ask what that hierarchy buys you overall in an application and, more important, in the student understanding.</p>
<p>In general, I find concrete subclassing to be problematic and easily abused, as well as confusing.</p>
<p>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 <em>programmer</em> doesn't make the decision about which constructor, but the program has to make the decision on the fly.</p>
<p>But even that suggestion implies that maybe you are thinking &quot;too concretely&quot; about things.</p>
<hr />
<p>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 &quot;all you have to do is add another dimension.&quot;. 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.</p>
<hr />
<p>For novices you can also turn this sort of thing into a good lesson on what is &quot;known&quot; 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.</p>

CC BY-SA 4.0
2020-09-24T17:37:18.787Z
2020-09-24T18:44:24.047Z
2020-09-24T18:44:24.047Z
Buffy
<p>My go-to for programming patterns these days are games, because it is easy to create compelling examples.</p>
<p>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!</p>
<p>However, the use I immediately thought of was an enemy factory that <em>only</em> 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 <code>List&lt;Enemy&gt;</code>.</p>

CC BY-SA 4.0
2020-09-25T04:20:53.577Z
2020-09-25T17:43:32.643Z
2020-09-25T17:43:32.643Z
Ben I.
<p>I don't have a good answer to this. However here are my thoughts.</p>
<h1>Named constructors</h1>
<p>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.</p>
<h1>Problems with the pattern</h1>
<p>However other uses of static factory seem to be an anti-pattern.</p>
<p>You now have a super-class depend on the sub-class. The sub-class already depends on the super-class.</p>
<p>The static constructor can also easily break the single responsibility principle: the class is a thing and a factory for a thing.</p>

CC BY-SA 4.0
2020-09-25T18:01:53.850Z
https://cseducators.meta.stackexchange.com/q/481/283
Ellen Spertus
CC BY-SA 4.0
2020-09-24T21:11:57.157Z
2020-09-25T18:24:58.860Z
2020-09-25T18:24:58.860Z
ctrl-alt-delor
<p>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.</p>
<p>For example, if the class <code>Rectangle</code> had a subclass <code>Square</code>, there could be a static method <code>Rectangle.newInstance(int width, int length)</code> that sometimes returned a <code>Rectangle</code> and sometimes a <code>Square</code>.</p>
<p>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 <code>Square</code> 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.)</p>
<p><strong>Edits</strong></p>
<p>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).</p>
<p>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.</p>

CC BY-SA 4.0
2020-10-02T10:43:06.460Z
I like the question. Although I have never (to my knowledge) created a Factory, I do learn a lot from the edge questions, and it made me think, "Hey, that thing I made the other day in ASP.Net, I bet it was a... Factory! One that creates subclassed... things!" So, I hope you stick around and keep challenging Frames. Just watch out for the glass doors (like in the movie *Spanglish*).
Scott Rowe
CC BY-SA 4.0
2022-08-15T00:30:34.093Z
I don't understand "_static_ factory." I thought a factory was an _instance_ of some class with one or more methods that "manufacture" other instances that implement some interface. To me, the whole point of the factory pattern is... Well... Suppose I write a library that needs to create new threads. Instead of simply creating them behind the scenes, I give my clients greater power to do I-dont-even-need-to-know-what by allowing the client to supply a "thread factory" _object_ that my code calls whenever it needs another thread.
Solomon Slow
CC BY-SA 4.0
2022-11-25T02:18:37.567Z
Be very careful with the square/rectangle problem. It is a highly contested inheritance example.
Flater
<java><object-oriented-paradigm><code-example>
What's a good example of a static factory method returning instances of subclasses?
# What's a good example of a static factory method returning instances of subclasses?

(Asked by: username_0 on 2020-09-24)

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.

**Tags:** java, object-oriented-paradigm, code-example

> **Comments:**
> **username_1**: I like the question. Although I have never (to my knowledge) created a Factory, I do learn a lot from the edge questions, and it made me think, "Hey, that thing I made the other day in ASP.Net, I bet it was a... Factory! One that creates subclassed... things!" So, I hope you stick around and keep challenging Frames. Just watch out for the glass doors (like in the movie *Spanglish*).  
> **username_2**: I don't understand "_static_ factory." I thought a factory was an _instance_ of some class with one or more methods that "manufacture" other instances that implement some interface. To me, the whole point of the factory pattern is... Well... Suppose I write a library that needs to create new threads. Instead of simply creating them behind the scenes, I give my clients greater power to do I-dont-even-need-to-know-what by allowing the client to supply a "thread factory" _object_ that my code calls whenever it needs another thread.  
> **username_3**: Be very careful with the square/rectangle problem. It is a highly contested inheritance example.  

---

## 3 answers

### Answer by username_5 on 2020-09-25. Score: 2 | Accepted answer

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`.


---

### Answer by username_6 on 2020-09-24. Score: 4

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.

> **Comments:**
> **username_0**: https://cseducators.meta.stackexchange.com/q/481/283  

---

### Answer by username_4 on 2020-09-24. Score: 2

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.


---

