2

While going through the book 'Head First design patterns ' on Factory Method Pattern chapter , I came across the following question and answer at pp.135 (print publication date of the book : 2004/10/25)

Q: Are the factory method and the Creator always abstract ?

A: No , you can define a default factory method to produce some concrete product. Then you always have a means of creating products even if there are no subclasses of the Creator.

At the same time the book defined factory method pattern as :

The Factory Method Pattern defines an interface for creating an object, but lets subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses. pp.134

So the question is if there are no subclasses of the Creator, then how can the pattern let subclasses decide which class to instantiate ?

EDIT: I see downvotes. Can you explain the reason ?

Improve this question
9
  • The problem I see with this question, as it stands, is that you are asking us to explain what the author(s) of that book had in mind when they wrote it. As we aren't those authors, that's a difficult thing for us to do.
    – David Arno
    Oct 25, 2018 at 12:12
  • @DavidArno, suppose I omit the book name, will it be okay then ?
    – Istiaque Ahmed
    Oct 25, 2018 at 12:13
  • @DavidArno, without mentioning the book how could I represent the Q and A ? The authors of the book had factory method pattern in mind when they wrote it. I did not mention any example that you need to go back to the book for clarification. The question as I think is self-explanatory without taking to any other helping resource. Am I correct ?
    – Istiaque Ahmed
    Oct 25, 2018 at 12:16
  • The factory method pattern is about distinguishing usage of an instance from its creation. The factory itself doesn't have to be abstract. There is a more sophisticated version of this where the factory itself is abstract for when creation becomes complicated. See Factory method pattern and Abstract factory pattern.
    – Neil
    Oct 25, 2018 at 12:25
  • 1
    @DavidArno Per my reading this question is fine: OP is asking about their understanding of the pattern (as based on that book). They are not asking us to infer the author's intention. It might be relevant that this book is just a second-hand account of the pattern and didn't introduce it.
    – amon
    Oct 25, 2018 at 12:30

1 Answer 1

Reset to default
1

Let's define a couple of terms for clarity:

  • A virtual method can be overridden by a subclass.
  • An abstract method has no implementation. It needs to be overridden or implemented in a subclass.

(Language-specific details: In C++, an abstract virtual method is called “pure virtual”. In Java, all methods are virtual unless declared final.)

The factory method pattern requires that the factory method can be overridden or implemented in a subclass, i.e. that this method is virtual. It does not require that the base class declares this method as abstract, i.e. the base class may provide an implementation of that method.

  • If the factory method is abstract in the base class, the subclass must implement it.
  • If the factory method is implemented in a base class, the subclass may optionally override it. The base class provides a default implementation.

In the case where implementing the method is optional, this does not detract from the pattern. The important aspect of the pattern is not that there is a subclass that decides which class to instantiate, but only that it is possible for a subclass to decide.

The Design Patterns book which introduced this pattern mentions the abstract/non-abstract variants explicitly:

The two main variations of the Factory Method pattern are (1) the case when the Creator class is an abstract class and does not provide an implementation for the factory method it declares, and (2) the case when the Creator is a concrete class and provides a default implementation for the factory method. It's also possible to have an abstract class that defines a default implementation, but this is less common.

The first case requires subclasses to define an implementation[.] In the second case, the concrete Creator uses the factory method primarily for flexibility.

Improve this answer
8
  • ' The Design Patterns book which introduced this pattern '- are you talking about thye book by GoF here amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/…?
    – Istiaque Ahmed
    Oct 25, 2018 at 12:48
  • The definition from OP says :' The Factory Method Pattern defines an interface for creating an object, but lets subclasses decide which class to instantiate. ' It could make thing more clear by saying ' but if there are any subclasses then lets subclasses decide which class to instantiate ', right ?
    – Istiaque Ahmed
    Oct 25, 2018 at 12:57
  • @IstiaqueAhmed Yes. The Head First book tries to explain the GoF Design Patterns in a more accessible manner, but doesn't always succeed. (This doesn't mean you should get the GoF book. I found it interesting from a historical perspective and it contains good advice. But it's now 20 years old and shows it age. Some of the patterns are now considered antipatterns, and the code examples are only given in old-school C++ and in Smalltalk (an effectively extinct language).)
    – amon
    Oct 25, 2018 at 13:02
  • recommendation of any book to learn design pattern easily ? Or is such question not a good fit here ?
    – Istiaque Ahmed
    Oct 25, 2018 at 13:06
  • @IstiaqueAhmed I find the original phrasing unambiguous, but your clarified definition is correct. A lot of design patterns are about offering extension points in advance so that a subclass can be implemented in the future.
    – amon
    Oct 25, 2018 at 13:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.