Patterns. Comparison of Abstract Factory, Factory Method and Prototype patterns

Features of generative patterns. Comparison of Abstract Factory, Factory Method and Prototype patterns

1. Features of generative patterns

If the system creates objects of different classes, there are two ways to parameterize this system with the classes of the created objects.

  1. From a class that creates objects, create subclasses. Each subclass directly creates a corresponding concrete object. This method follows the Factory Method pattern. The disadvantage of this pattern is that it requires creating a new subclass just to change the product class. If there are many such changes, then this gives rise to a significant number of subclasses.
  1. Implement the composition of objects. In this approach, an object is defined that contains information about the classes of objects that are to be products. Then this object becomes a system parameter. The Abstract Factory, Builder and Prototype patterns work according to this principle.

For all three of the above patterns, the concept of a “factory object” arises, intended for the manufacture of products. In the Abstract Factory pattern, a “factory object” creates objects of different classes.

When implementing the Builder pattern, a product is created by a “factory object” in accordance with a given sequence (protocol) of steps.

The Prototype pattern is characterized by creating a product by obtaining a copy from a prototype object. Here, in fact, the “factory object” is the product.


2. Implementation of the task using the Prototype, Factory Method and Abstract Factory patterns. Compare patterns using class diagrams

Below is an implementation of a music editor using the Prototype, Factory Method, Abstract Factory patterns.

Let’s say you need to build a music editor that contains a palette of instruments and allows you to add new musical objects to the score.

The music editor is displayed in a graphics editor, represented by the abstract class Graphic. Graphic components can be notes (MusicalNote class) and note states (Staff class) and some abstract class (for example Tool) that defines instruments in the palette. From this abstract class, a GraphicTool subclass can be defined for tools that create graphic objects and add them to a document.

One of the solutions to the music editor problem is offered by the Abstract Method pattern. Figure 1 shows the appropriate class diagram.

The abstract developer (Graphic interface) declares a NewGraphic() method that creates an instance of the product. The Staff and MusicalNote subclasses return a specific product.

The product interface is defined in the abstract Tool class. The subclasses GraphicToolMusicalNote and GraphicToolStaff act as specific products.

Music editor. Implementation using the Factory Method pattern

Figure 1. Music editor. Implementation using the Factory Method pattern

When using the Factory Method pattern, a combinatorial increase in the number of subclasses that perform almost nothing occurs. This is the main disadvantage.

Another solution to the music editor problem is offered by the Abstract Factory pattern (Figure 2). Here two class hierarchies are created. The first hierarchy is the classes that create the product. This hierarchy is defined by the GraphicFactory interface, which returns instances of specific products. Concrete products are derived from the GraphicFactory interface using the Staff and MusicalNote subclasses.

The second class hierarchy defines the resulting product, at the top of which the GraphicTool class is described. To represent a specific product in the hierarchy, two additional subclasses StaffProduct and MusicalNoteProduct are defined. The client receives the product through the GraphicTool interface.

Music editor. Implementation using the Abstract Factory pattern

Figure 2. Music editor. Implementation using the Abstract Factory pattern

The advantage of the Abstract Factory pattern over the Factory Method pattern occurs when the Graphic Factory class hierarchy already exists and does not need to be created.

The disadvantage of this pattern compared to the Prototype pattern is the creation of additional classes, which leads to an increase in the overall class hierarchy.

And, finally, solving the problem using the Prototype pattern (Figure 3). Here, specific notes and note states are cloned (copied) into GraphicTool via the Graphic interface. Figure 3 presents a class diagram for solving a problem using the Prototype pattern.

Music editor. Solution using the Prototype pattern

Figure 3. Music editor. Solution using the Prototype pattern

The advantage of using the Prototype pattern compared to the Factory Method (Figure 1) and Abstract Factory (Figure 2) patterns is that only the Clone() method should be implemented here. This reduces the number of subclasses.