63: Design Patterns: Abstract Factory.

The abstract factory creational pattern allows you to organize different sets of classes that work together so they get created together. This lets you change from one group of classes to another by configuring a different abstract factory. You first need to create an interface that’ll be common for each type of factory. This interface will have create methods for each object that you want created by a factory. These individual create methods are factory methods and are implemented by the concrete factory instance. What makes this pattern different from just the factory pattern is this interface that brings together many different types that all need to work together. By switching to a new factory, other code can start creating different instance types that are designed to work well together as this new factory determines. Each create method will need to return an interface or base class because the actual type that’s returned will depend on what concrete type the factory decides to create. Since there are many different factories each trying to return different types for the same create method, we need a common interface for each of these. The episode also describes some problems you might encounter with this pattern and some suggestions for modifying the basic pattern to fit your needs. Listen to the full episode or read the full transcript below. Transcript The basic description says that this pattern provides an interface that’s used to create families of classes without specifying the exact classes. I put this pattern after the other creational patterns because it sometimes uses the other patterns. It’s called an abstract factory not because the concept is abstract but because the factory itself uses an abstract base class or an interface. The simple and most direct way that this pattern works is from an interface. And I’ll normally just refer to this as an interface because that’s shorter than constantly saying abstract base class or an interface. But they’re the same thing really. You define an interface with methods that create and return instances of other classes. Each of these methods works like the factory pattern. In fact, you can sort of think of this pattern as a factory that’s been extended to work with many classes. Each method returns a concrete class but as a base class. Let me give you an example to make this clear. We’ll use the adventure game. We need to create lots of object in the game including buildings, trees, and even clouds in the sky. You start out by creating an interface to define basic characteristics of all buildings. And the same thing with trees, clouds, and anything else that you want to participate in this pattern. This will include anything that needs to work together. But wait, what do I mean by working together? How can a tree work together with a cloud? They don’t need to have any direct interaction. But since trees are outside, it’s reasonable to assume that there will be clouds outside as well. If you’re creating trees, then you’ll likely want to create some clouds to go along with the whole scene. That’s what I mean by them working together. Why is this important? Why do we need to put all these things behind an abstract factory? Let’s say that all these things work well until you have to implement the ability for the hero to walk around in a dream. Now, you’re going to want dream houses, dream trees, and even dream clouds. Maybe they all look a bit different. Maybe the hero can just walk right through the walls of a dream house. You don’t want to mix these. It would be very bad to sometimes spot a purple dream cloud in an otherwise normal sky. Since we don’t want to mix these concepts, your game can switch modes. It’s either in regular mode or in dream mode. Or maybe even some other mode. You can get into a particular mode and stay there by switching factories. You see