Let's see:
- Not "have to have", you just can have it. All patterns don't dictate anything mandatory. This is just a recommended pattern suitable for a class of typical similar problems. Yes, the factory method creates some object.
- Yes, you will, but in what sense do you "have" it? You need to see the difference between compile-time type and runtime type, which is a part of the heart of OOP. When you call a factory method, you always get an instance of some non-abstract class or structure (yes, structure, too, if the method return type is some interface, because structures can implement interfaces, too). After all, there are no instances of interfaces or abstract classes. But the compile-time type (which is appear in the declaration of the factory method) is abstract. Or, strictly-speaking, it can be pseudo-abstract (non-abstract type which is primarily used for exact same purpose as the abstract class, as a base class for some set of derived classes, but is formally non-abstract and can be instantiated).
- Nothing is "further sub-classed". See the previous item. The method, as always, returns instance of the class, not class. An instance cannot be sub-classes, "further" or not. Again, there is a base class or interface which is used as a return type of the factory method. Implementation of the factory class can have one or more type based on this interface or a base class, implementing the interface or inheriting the base class. The call returns the instance of one of those derived types. The interface of the type implementing the factory method does not specify what runtime type will be returned; this is decided by its implementation. In other words, the caller "does not know" the concrete runtime type returned; and this knowledge is not needed. This is the essence of OOP: the runtime type "knows what to do", not its user.
- Yes, it is of course possible. This way, you can have double hierarchy of the types: the hierarchy of the types returned by the factory method, and the hierarchy of the factories.
However, this is not the essence of the pattern and not mandatory. Moreover, should you try to create parallel hierarchy, you would defeat the purpose of the factory. Say, if you plan to use ConcreteCreatorA
for creation of instances of type A
, and ConcreteCreatorB
for creation of instances of type B
, it would totally defeat the purpose of the pattern, because its would be nothing better then creating instances of A
and B
directly.
Unfortunately, none of these questions helps to understand the essence and the use of the pattern, they all miss the goal. The whole approach to getting some help through such question is not very productive (but perhaps not completely useless): you are trying to guess something which you don't really understand and ask for confirmation. This is like using
adjustment fire with the gun which is already well adjusted (documentation is available, like already adjusted
iron sights, you just need to understand it / view through it).
The essence of the patten is well explained.
The essence of this pattern is to "Define an interface for creating an object, but let the classes that implement the interface decide which class to instantiate. The Factory method lets a class defer instantiation to subclasses."
That's why the picture (first on on the page references above) shows just two members of the
Creator
hierarchy. The concrete implementation type
ConcreteCreator
creates instances of the
Product
type for all of the concrete types derived from
Product
. It allows the user of the
Creator
to remain
agnostic of the concrete runtime types of the returned objects.
—SA