What is abstract about the Abstract Factory?

Question

I've been always wondering why the Abstract Factory Pattern is actually called abstract? I don't understand what is abstract about it?

It somehow does not fit in the image of abstract classes that I think about when I hear the word abstract so I was looking for it in many articles but guess what... there wasn't anything abstract!

This is the most confusing design-pattern (name) I can think of and I'm still not sure I get it right so correct me please if I'm wrong.

There isn't anything abstract, right? It's just a very misleading name of a very real non-abstract class that simply creates other objects?

Answer 1

Regarding the naming of the abstract factory pattern: The design pattern movement and particularly the Design Patterns book was centered around Smalltalk and C++, and predates the popularity of Java. Neither Smalltalk nor C++ have interfaces. Smalltalk as a Python-like dynamic language doesn't need explicit interfaces, and C++ simply didn't feature a concept with that name.

Instead, C++ uses abstract classes that only contain pure virtual methods, i.e. methods that have no implementation and must be overridden in child classes. Note also that C++ has multiple inheritance, so it is possible to inherit from multiple abstract base classes, unlike e.g. Java.

Therefore, the terminology of Abstract versus Concrete makes a lot of sense in the context of these design patterns. The introduction of the Design Patterns book explicitly discusses the difference:

An abstract class is one whose main purpose is to define a common interface for its subclasses. An abstract class will defer some or all of its implementation to operations defined in subclasses; hence an abstract class cannot be instantiated. The operations that an abstract class declares but doesn't implement are called abstract operations. Classes that aren't abstract are called concrete classes.

From a language history perspective, interfaces as a separate concept from classes are only necessary in statically typed single-inheritance OOP languages such as Java. There is an understandable desire to avoid the complexity of multiple inheritance, but multiple interface inheritance is absolutely necessary in order to implement nontrivial OOP designs. Curiously, newer languages like Go and Rust get rid of classes entirely and only keep interface/trait inheritance – arguably a purer form of OOP.

Answer 2

Well, it's probably worthwhile to mention that there are two patterns here: Factory method pattern and Abstract factory pattern.

Factory method pattern is what you describe. One real class is responsible for creating any and all instances. There is nothing abstract about this. The advantage is that the creation of instances is separate from their usage.

But what happens when the creation of each instance becomes wildly different one to the next and/or your class is becoming cluttered with gigantic if-else chains?

The abstract factory pattern is the next step which addresses this problem. It makes even the creation of each object entirely flexible and potentially in its own class. For example, rather than connect to a database, each with its own parameters and connect string, all concatenated into a single complex factory class, you're creating implementations of an abstract factory, each implementation focused on a single database.

The advantage ultimately remains the same, however you're able to do so without having a overly complicated real factory class. Obviously, if you can do with only the factory method class, use this. No need to implement an abstract factory pattern when the factory method pattern will do fine.

So to answer your question, the reason you'd call the abstract factory pattern abstract is because each factory itself derives from an abstract factory.