Article directory
1. Overview of Design Patterns
1. Background of software design patterns
"Design pattern" did not originally appear in software design, but was used in the design of the architectural field.
In 1977, the famous American architect and the director of the Environmental Structure Center of the University of California, Berkeley
克里斯托夫·亚历山大（Christopher Alexander）described some common architectural design problems in his book "Architectural Pattern Language: Towns, Buildings, and Structures", and put forward 253 kinds of problems for towns and neighborhoods. , houses, gardens and rooms, etc. to design the basic pattern.
In 1990, the software engineering community began to discuss the topic of design patterns, and later held many seminars on design patterns. Until 1995, Eric Gamma (Erich Gamma), Richard Helm (Richard Helm), Ralph Johnson (Ralph Johnson, John Vlissides) etc. 4 The author co-published the book "Design Patterns: The Foundation of Reusable Object-Oriented Software", which included 23 design patterns. This is a milestone event in the field of design patterns, leading to a breakthrough in software design patterns. These four authors are also known in the field of software development as their "Gang of Four" (GoF).
2. The concept of software design pattern
Software Design Pattern (Software Design Pattern), also known as design pattern, is a summary of code design experience that has been classified and cataloged and is known to most people. It describes some recurring problems in the software design process, and the solutions to the problems. That is to say, it is a series of routines to solve specific problems, and it is a summary of the code design experience of the predecessors. It has certain universality and can be used repeatedly.
3. The necessity of learning design patterns
The essence of design patterns is the practical application of object-oriented design principles, and a full understanding of the encapsulation, inheritance, and polymorphism of classes, as well as the association and composition relationships of classes.
Proper use of design patterns has the following advantages:
- It can improve the programmer's thinking ability, programming ability and design ability.
- The program design is more standardized, the code compilation is more engineering, the software development efficiency is greatly improved, and the software development cycle is shortened.
- The designed code has high reusability, strong readability, high reliability, good flexibility and strong maintainability.
4. Classification of Design Patterns
(1) Creational mode
It is used to describe "how to create objects", and its main feature is "separation of object creation and use". The GoF (Group of Four) book provides 5 creational patterns, including singleton, prototype, factory method, abstract factory, and builder.
(2) Structural pattern
It is used to describe how to combine classes or objects into a larger structure according to a certain layout. The GoF (Group of Four) book provides 7 structural patterns such as proxy, adapter, bridge, decoration, appearance, flyweight, and combination.
(3) Behavioral model
It is used to describe how classes or objects cooperate with each other to accomplish tasks that a single object cannot accomplish alone, and how to assign responsibilities. The GoF (group of four) book provides 11 behavioral patterns such as template method, strategy, command, chain of responsibility, state, observer, mediator, iterator, visitor, memo, and interpreter.
Two, UML diagram
The Unified Modeling Language (UML) is a visual modeling language for designing software. It is characterized by simplicity, unity, graphics, and the ability to express dynamic and static information in software design.
Starting from different perspectives of the target system, UML defines nine types of diagrams, including use case diagrams, class diagrams, object diagrams, state diagrams, activity diagrams, sequence diagrams, collaboration diagrams, component diagrams, and deployment diagrams.
1. Class Diagram Overview
A class diagram (Class diagram) shows the static structure of the model, especially the classes that exist in the model, the internal structure of the classes, and their relationship with other classes. Class diagrams do not display transient information. Class diagrams are a major component of object-oriented modeling.
2. The role of class diagrams
- In software engineering, a class diagram is a static structural diagram that describes the collection of system classes, the attributes of classes and the relationship between classes, which can simplify people's understanding of the system;
- The class diagram is an important product of the system analysis and design phase, and an important model for system coding and testing.
3. Class Diagram Notation
3.1 Class Representation
In a UML class diagram, a class is represented by a rectangle containing a class name, an attribute (field) and a method (method) with a dividing line. For example, the following figure represents an Employee class, which contains three attributes: name, age and address , and the work() method.
The plus sign and minus sign added before the attribute/method name indicate the visibility of this attribute/method. There are three symbols for visibility in UML class diagrams:
- +: means public
- -: Indicates private
- #: means protected
The full expression of the attribute is: visibility name: type [= default value] The
full expression of the method is: visibility name (parameter list) [: return type]
Note:
1. The contents in square brackets are optional of.
2. There is also the type in front of the variable name, and the return value type in front of the method name.
Take a chestnut:
The Demo class above defines three methods:
- method() method: the modifier is public, there are no parameters, and there is no return value.
- method1() method: the modifier is private, there are no parameters, and the return value type is String.
- method2() method: the modifier is protected, it receives two parameters, the first parameter type is int, the second parameter type is String, and the return value type is int.
3.2 Representation of the relationship between classes
(1) Association relationship
An association relationship is a reference relationship between objects, which is used to represent the connection between one type of object and another type of object, such as teacher and student, master and apprentice, husband and wife, etc. Association relationship is the most commonly used relationship between classes, which can be divided into general association relationship, aggregation relationship and combination relationship. We start with general associations.
Association can be divided into one-way association, two-way association, self-association.
① One-way association
A unidirectional association is represented by a solid line with an arrow in a UML class diagram. The figure above shows that each customer has an address, which is realized by letting the Customer class hold a member variable class of type Address.
② Two-way association
From the above figure, we can easily see that the so-called two-way association means that both parties hold member variables of each other's type.
In a UML class diagram, a bidirectional association is represented by a straight line without an arrow. In the above figure, a List<Product> is maintained in the Customer class, indicating that a customer can purchase multiple products; a member variable of the Customer type is maintained in the Product class to indicate which customer purchased the product.
③ Self-association
A self-association is represented in a UML class diagram by a line with an arrow pointing towards itself. The above picture means that the Node class contains member variables of type Node, that is, "self-contains itself".
(2) Aggregation relationship
An aggregation relationship is a kind of association relationship, a strong association relationship, and a relationship between a whole and a part.
Aggregation is also implemented through member objects, where member objects are part of the overall object, but member objects can exist independently from the overall object. For example, the relationship between the school and the teacher, the school contains the teacher, but if the school is closed, the teacher still exists.
In a UML class diagram, an aggregation relationship can be represented by a solid line with a hollow diamond pointing towards the whole. The following figure shows the relationship between universities and teachers:
(3) Combination relationship
Composition represents a whole-part relationship between classes, but it is a stronger aggregation relationship.
In the composition relationship, the overall object can control the life cycle of the partial object. Once the overall object does not exist, the partial object will also disappear, and the partial object cannot exist without the overall object. For example, the relationship between the head and the mouth, without the head, the mouth would not exist.
In a UML class diagram, a composition relationship is represented by a solid line with a solid diamond pointing toward the whole. The following figure shows the relationship between the head and the mouth:
(4) Dependencies
Dependency relationship is a usage relationship, which is the weakest coupling between objects, and it is a temporary relationship. In the code, a method of a class accesses some methods in another class (dependent class) through local variables, method parameters, or calls to static methods to complete some responsibilities.
In UML class diagrams, dependencies are represented by dashed lines with arrows pointing from consuming classes to dependent classes. The following figure shows the relationship between the driver and the car, and the driver drives the car:
(5) Inheritance relationship
The inheritance relationship is the most coupled relationship between objects, expressing the general and special relationship, the relationship between the parent class and the subclass, and an inheritance relationship.
In a UML class diagram, a generalization relationship is represented by a solid line with a hollow triangular arrow pointing from a child class to a parent class. When implementing the code, use the object-oriented inheritance mechanism to realize the generalization relationship. For example, both the Student class and the Teacher class are subclasses of the Person class, and their class diagrams are shown in the following figure:
(6) Realize the relationship
The implementation relationship is the relationship between the interface and the implementing class. In this relationship, the class implements the interface, and the operations in the class implement all the abstract operations declared in the interface.
In UML class diagrams, the implementation relationship is represented by a dashed line with a hollow triangular arrow pointing from the implementing class to the interface. For example, cars and boats implement vehicles, and their class diagrams are shown in the figure:
