Pattern Abstract Factory

Definition and motivation Abstract factory is a pattern, generating objects, which provide an interface for creating a collection of logically related or dependent objects without specifying concrete classes. The system should not depend on how to create, assemble and submit the incoming objects. The objects built in certain way are simply served at the entrance. Objects of one collection should be used together. Specific variant of the desired behavior of the system are given by not separate objects, but by the collection of related objects. For the functioning of the systems you need one of such collection of related objects. The system input is only the whole collection of such objects. You want to provide a library of objects, revealing only their interfaces, but not the implementation.

Advantages The implementation of concrete classes are hidden. The factory isolates the client from the implementation details of classes. It encapsulates the responsibility for creating classes. The client only know interfaces, abstract classes through which it can perform its business logic further. Free replacement of product collection. The application can change the configuration of objects, simply substituting a new concrete factory. Warranty use of only one type of objects. If certain collection of objects designed for the joint purposes, it is important that the application in each moment can work with only a single collection of objects. Class AbstractFactory allows you to maintain this limit easily. Simplified testing. When testing it is easy to replace a whole collection of objects with another set of classes.

Class diagram

Participants AbstractFactory is the abstract factory. Announces a common interface for creation of abstract objects. Further the concrete objects of some collection will be produced in the application instead of the abstract objects. ConcreteFactory[N] is the concrete factory. Ii implements the operations that create all objects of the same specific collection. AbstractProduct[A-Z] is the abstract object. It defines a common interface for the object. A-Z are many of such objects, components of an abstract collection. ConcreteProduct[A-Z][N] is a specific object. It defines the specific object of a type [A-Z] created a particular factory [N]. Client is the other software module, obtaining a specific collection of products, using only known interfaces of classes AbstractFactory and AbstractProduct.

Example 1 Consider the production of cars and engines. We define the entities “car”, “engine” and factories, creating these entities.

Example 1 Implementation of the entity of the car “Ford” and the corresponding engine:

Example 1 The factory, which is responsible for creation of automobiles and engines “Ford”:

Example 1 Implementation of the entity of the car “Toyota” and corresponding engine:

Example 1 The factory, which is responsible for creation of automobiles and engines “Toyota”:

Example 1 Consider the example of the use of factories:

Example 2 Consider the example of using “Abstract factory” pattern to support addresses and phone numbers of different countries. Each country has its own telephone code and standard of address record. The interface of a factory, creating the objects of addresses and telephone numbers, is the following:

Example 2 Below the base class address is specified:

Example 2 The base class of the phone number:

Example 2 A concrete class that represents US addresses:

Example 2 A class representing the US telephone numbers: The factory, which instantiates the instances of the US address and phone number:

Example 2 A concrete class that represents France addresses:

Example 2 A class representing the France phone numbers: The factory, which instantiates the instances of the France address and phone number:

Example 3 Suppose we are writing a game in which the player will meet with a variety of enemies: soldiers, monsters and supermonsters. All enemies, who will meet the player, must correspond to the level of complexity that is selected in the beginning of the game. The factory for creating enemies could be the following:

Example 3 The factory which creates enemies with for low complexity:

Example 3 The factory which creates enemies with for high complexity:

Example 3 This approach has the following disadvantages: Duplication. When implementing factories, we have to repeat the same code. Inability of generalization. It is impossible to write next general code: We need to call concrete factory methods.

Example 3 We can get rid of these disadvantages if the class of abstract factory is given a list of parameters in the form of types that it should create: Then the function of creating objects could be called from general code:

Lists of types For realization of these factories there is the concept of list of types in the Loki library. This list of types is defined so: To determine the list of types of random length the recursion is used. For example, a list of the types of three elements looks like this:

Example 3 In addition, the library contains a set of macros for simplified definition of the list of types: These macros are used thus:

Example 3 Loki library contains a mechanism for creating abstract factories. The class “AbstractFactory” is used. It takes a list of types as a parameter:

Example 3 To identify concrete factories the class “ConcreteFactory” must be used:

Example 3 As a result it is possible to use the factory in the following generalized functions: The code that uses this function might be: