2.2 Generating patterns

Generating patterns - patterns designed to create objects. These patterns are important when the system depends more on the composition of objects than on the inheritance of classes. It turns out that the main focus is not on hard coding a fixed set of behaviors, but on defining a small set of fundamental behaviors that can be used to produce any number of more complex ones.

For generating patterns, two topics are relevant. First, these patterns encapsulate knowledge about specific classes that are applied in the system. Secondly, hide the details of how these classes are created and joined. The only information about objects known to the system is their interfaces, defined using abstract classes. Therefore, generating patterns provide greater flexibility in deciding what is being created, then it creates how and when. It is possible to assemble a system from “ready-made” objects with the most diverse structure and functionality statically (at the compilation stage) or dynamically (at runtime). Sometimes it is permissible to choose between one or another generating pattern. For example, there are cases in which both a prototype and an abstract factory can be used for business purposes. In other situations, the spawning patterns complement each other.

2.2.1 Singleton Pattern

Title

Singleton (singleton).

Task

For some classes, it is important that there is only one instance. Although there may be many printers in the system, only one spooler is possible. There should be only one file system and a single window manager. In some cases, the accounting system should serve only one company.

How to ensure that a class has a single instance and that this instance is easily accessible? A global variable gives access to an object, but it is forbidden to create several objects of a class. A better solution is that the class itself controls that it has only one instance, can prohibit the creation of additional instances, intercepting requests to create new objects, and it is also able to provide access to its own instance. This is the purpose of the loner pattern.

From the above, we can formulate the task of the pattern Singleton. Singleton ensures that a class has only one instance, and provides it with a global access point.

Structure

Figure 2.1 Singleton Pattern Structure

Relations

Clients access the Singleton instance only through Singelton :: getInstance ()

results

• Ensures that there is only one instance in the system for a certain class.
• Due to the fact that in programming languages ​​such behavior is realized through static methods, polymorphism cannot be used.

2.2.2 Prototype Pattern

Title

Prototype (prototype).

Purpose

Specifies the types of objects to be created using the prototype instance and creates new objects by copying this prototype.

Task

The Prototype pattern allows you to create a copy of an object without specifying a specific class on the client side. Use the Prototype pattern when there is a need to create copies of objects without knowing their specific types, but only knowing the basic abstract type.

Structure

Figure 2.2 Prototype Pattern Structure

• Prototype -Prototype: - announces an interface for cloning itself;
• СonсretePrototype - a specific prototype: - implements the cloning operation itself;
• Client - client: - creates a new object, referring to the prototype with a request to clone itself.

results

The advantages of using the prototype are as follows: first, the prototype allows you to get new objects without specifying their specific classes; secondly, we can add new classes to the system for frequent, without changing the client; thirdly, we hide the names of specific classes from the client (the client knows only about the Prototype class), thereby reducing the degree of client connectivity (that is, reducing the number of elements known to it)

Among the shortcomings we can mention the need to add the clone () method implementation to each specific class, which may not always be convenient.

2.2.3 Factory method

Title

Factory method (factory method), Virtual constructor (virtual constructor).

Purpose

Defines an interface for creating an object, but leaves the subclasses deciding which class to create.

Motivation

Frameworks use abstract classes to define and maintain relationships between objects. In addition, the framework is often responsible for creating the objects themselves.

Consider the framework for applications that can provide the user with multiple documents. The two main abstractions in such a framework are the Application and Document classes. Both classes are abstract, so clients must spawn subclasses from them to create application-specific implementations. For example, to create a drawing application, we define the DrawingApplication and DrawingDocument classes. The Application class is responsible for managing documents and creates them as needed, for example, when a user selects Open or New from the menu.

Figure 2.3 Factory Method Pattern Structure (example)

Since the decision about which subclass of the Document class to create depends on the application, the Application cannot “predict” what it will need. This class is known only when it is necessary to create a new document, and not which document to create. A dilemma arises: the framework must create instances of classes, but it knows only about abstract classes, instances of which cannot be created.

The solution suggests the factory method pattern. It encapsulates information about which subclass of the Document class to create, and this knowledge is brought out of the framework.

Subclasses of the Application class override the CreateDocument abstract operation so that it returns a suitable subclass of the Document class. Once the Application subclass is created, it can create application-specific documents without knowing anything about their classes. We call the operation CreateDocument a factory method, since it is responsible for the “fabrication” of an object.

Applicability

The class does not know in advance what objects of classes it needs to create; the class is designed so that the objects it creates are specified by subclasses; the class delegates its responsibilities to one of several subsidiary subclasses, and you plan to localize knowledge of which class takes on these responsibilities.

Structure and participants

The structure of the pattern is shown in fig. 2.4

• Product (Document) - Product - defines the interface of objects created by the factory method;
• ConcreteProduct (MyDocument) - a specific product: - implements the Product interface;
• Creator (Application) - creator - declares a factory method that returns an object of type Product. Creator can also define the default implementation of the factory method.
• ConcreteCreator (MyApplication) —the specific creator — replaces the factory method that returns the Concrete Product object.

Relations

The creator "relies" on his subclasses in defining a factory method that will return an instance of a suitable, specific product.

results

Fabric methods eliminate the need for the designer to embed application-dependent classes into the code. The code only deals with the interface of the Product class, so it can work with any user-defined classes of specific products. A potential drawback to the factory method is that customers may have to create a subclass of the Creator class to create only one ConcreteProduct object. The generation of subclasses is justified if the client somehow has to create subclasses of Creator, otherwise the client will have to deal with an additional level of subclasses.

Figure 2.4 Factory Method Pattern Structure

2.2.4 Reflection Pattern

Title

Reflection

Purpose

Provide the ability to create objects by class name for programming languages ​​that do not explicitly support reflection.

Structure and participants

Figure 2.5 Reflection Pattern Structure

• Object. The base class for all classes of the system for which it is necessary to create objects by name. In the simplest case, declares an interface with a single abstract method createInstance ().
• ConcreteClass1. A specific subclass of Object. Implements the createInstance () method. The most obvious implementation of this method in specific subclasses of Object is the creation of itself.
• ObjectFactory. Factory of objects. It is implemented in accordance with the template Singleton. This class provides an interface for registering classes (registerClass ()) and for creating objects (createObjectByName ())
• Library. Provides an abstract interface for system modules. Specific Library subclasses can be classes that encapsulate loading dynamic libraries, such as Dynamic LoadLibrary (DLL) in Win32 systems or Shared Library in Unix systems. The task of this class is to register the classes contained in them at ObjectFactory (Fig. 2.6)
• Client. Describes the classes whose objects are clients relative to ObjectFactory. Clients use ObjectFactory to create objects by calling the last createObjectByName () (Fig. 2.7)

Interaction

Figure 2.6 Class Registration

Figure 2.7 Creating an object

results

The main result of this pattern is the ability to create class objects by name, which, in turn, increases the flexibility of the software solution. On the other hand, the pattern implies the organization of the program as a set of dynamically loaded libraries, which may be in some cases unacceptable.

2.2.5 Creator Pattern

Title

Creator

Purpose

Determines who should be responsible for creating objects.

Decision

Assign class B to create instances of class A if one of the following conditions is met.

• Class B aggregates objects A.
• Class B uses A. objects closely.
• Class B has initialization data that will be passed to objects A when they are created.

results

The Low Coupling pattern is supported, helping to reduce maintenance costs and providing the ability to re-use the created components in the future.