Abstract Factory

The first pattern presented here is a method to create kits of objects without knowing the concrete types of the objects. Let's continue on with the system presented earlier for ruling a kingdom.

In the kingdom in question, the ruling house changes with some degree of frequency. In all likelihood, there is a degree of battling and fighting during the change of house but we'll ignore that for the moment. Each house will rule the kingdom differently. Some value peace and tranquility, and rule as benevolent leaders, while others rule with an iron fist. The rule of a kingdom is too large for a single individual, so the king defers some of his decisions to a second-in-command known as the hand of the king. The king is also advised on matters by a council, which consists of some of the more savvy lords and ladies of the land.

A diagram of the classes in our description is as follows:

Tip

Unified Modeling Language (UML) is a standardized language developed by the Object Management Group (OMG), which describes computer systems. There is vocabulary in the language to create user interaction diagrams, sequence diagrams, and state machines, among others. For the purposes of this book, we're most interested in class diagrams, which describe the relationship between a set of classes.

The entire UML class diagram vocabulary is extensive and is beyond the scope of this book. However, the Wikipedia article at https://en.wikipedia.org/wiki/Class_diagram acts as a great introduction, as does Derek Banas's excellent video tutorial on class diagrams at https://www.youtube.com/watch?v=3cmzqZzwNDM.

The issue is that with the ruling family, and even the member of the ruling family on the throne changing so frequently, coupling to a concrete family such as Targaryen or Lannister makes our application brittle. Brittle applications do not fare well in an ever-changing world.

An approach to fixing this is to make use of the Abstract Factory pattern. The Abstract Factory pattern declares an interface to create each of the various classes related to the ruling family, as shown in the following diagram:

The Abstract Factory class may have multiple implementations for each of the various ruling families. These are known as concrete factories and each of them will implement the interface provided by the Abstract Factory. The concrete factories, in return, will return concrete implementations of the various ruling classes. These concrete classes are known as products.

Let's start by looking at the code for the interface for the Abstract Factory.

No code? Well, actually that is exactly the case. The lack of classes in JavaScript precludes the need for interfaces to describe classes. Instead of having interfaces, we'll move directly to creating the classes, as shown in the following diagram:

Instead of interfaces, JavaScript trusts that the class you provide implements all the appropriate methods. At runtime, the interpreter will attempt to call the method you request, and call it, if it is found. The interpreter simply assumes that if your class implements the method, then it is that class. This is known as duck typing.

Tip

Duck typing

The name duck typing originates a post made by Alex Martelli in the year 2000 to the news group comp.lang.python, where he wrote:

class Boxer{
  function punch(){}
}
class TicketMachine{
  function punch(){}
}