Lecture
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.
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
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
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.
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
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
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
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.
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.
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.
Comments
To leave a comment
Object oriented programming
Terms: Object oriented programming