1.2 Abstract factory design pattern

One of the nice things about abstraction is that it lets you take care of the bigger picture and worry about the details later. Wouldn't it be great if we could do that when creating objects? It sure would be handy to be able to rely upon some other class to fill in the details for you. With the help of the Abstract Factory Pattern , we can.

The great advantage of this is that we don't have to worry about what kind of car we're building. Let's say that you are making various types of car, and each car has different types of components you need to worry about. For example, say that you have the ability to build a Cadillac Dreadnaught, a Citroën BX-TRD, and a Fiat Avanti. Each type of vehicle has the same overall structure that all cars share in common: i.e. an engine, wheels, steering, brakes, etc. For the sake of simplicity, let's say that a car consists of three components: Engine, Chassis, and Steering. Naturally, you can't have the same types of Engine, Chassis or Steering in each car, because then the cars would all be the same. It won't do to mix-and-match components, either. You need all Cadillac parts to go with the Cadillac, and all Citroën parts to go with the Citroën, etc. The different parts of the cars don't need to do the same thing, either: they need merely conform to an interface. Let's encapsulate the decision making process for assigning the parts when you build a car.

Should the main car building program care what kind of car is being built? No, it shouldn't. It should just expect the car to behave as all cars should, and not care about the specifics. All of the knowledge about the specific cars we're building is not contained in the main class of the program, but can be updated and changed easily, since the information is only in one place. This gives us great flexibility, since we are not limited in our choices at all, and can make many different types of car. Let's say that we have a simulated car-building plant. It can produce one type of car at a time, but can produce any type of car, so long as the workers have the proper directions. Each set of plans will dictate how each component of a particular car is built. So, in order to change the type of car we're producing, we only need to switch the directions. All of the factory workers will follow the new directions, producing a new car, based upon the directions.

That's nice, you say, but won't it get confusing with all kinds of different directions running around? Which set do we follow? The solution is pretty simple. We have one main set of directions which everyone refers to, and we can change what that set of directions looks like. We expect each set of directions to provide certain information about how to build a car. It should comply to an abstract set of directions that we have in mind. Each real set of directions should have the same structure as the abstract directions. Let's call the sets of directions Factories. A Factory will build a certain type of car, depending upon the type of factory. The specification for what directions should contain would be called an Abstract Factory.

A good analogy for this is a pasta maker. A pasta maker will produce different types of pasta, depending what kind of disk is loaded into the machine. All disks should have certain properties in common, so that they will work with the pasta maker. This specification for the disks is the Abstract Factory, and each specific disk is a Factory. You will never see an Abstract Factory, because one can never exist, but all Factories (pasta maker disks) inherit their properties from the abstract Factory. In this way, all disks will work in the pasta maker, since they all comply with the same specifications. The pasta maker doesn't care what the disk is doing, nor should it. You turn the handle on the pasta maker, and the disk makes a specific shape of pasta come out. Each individual disk contains the information of how to create the pasta, and the pasta maker does not.