What is a "design pattern"?

Article directory

1. foreword

2. What are design patterns?

3. Six principles of design patterns

4. High cohesion, low coupling?

    

1

foreword

Many people should have heard of design patterns, and have seen or used design patterns to a greater or lesser extent, but when they are actually used in the development process, there is always a feeling of being overwhelmed. It must be a slight deviation or insufficient understanding of the design pattern. Without talking about a specific pattern, let's take a look at what is a design pattern?

 

Analysis from the introduction combined with the actual scene

 

2

What are design patterns?

A design pattern is a set of code design " experiences ". The " reasonable " use of design patterns in a project can " smartly solve many problems ".

 

Summary of experience: With the mentality of "code abuses me thousands of times, I treat code like my first love", and finally came up with a "routine".

 

Reasonable: Use it after you have a certain understanding of the usage scenarios of the design pattern, "don't abuse it". For example: to output a sentence "hello world", it is necessary to force various modes to be added.
Question: "Why", Answer: "It always feels like there is no pattern!".

 

Cleverly solves a lot of problems: the reason for being widely used.

 

Why advocate "Design Pattern? The fundamental reason is to reuse code and increase maintainability. So how can we achieve code reuse?

 

3

Six principles of design patterns

Open Close Principle

In 1988, Bertrand Meyer proposed the open-closed principle in his book "Object Oriented Software Construction", the original text of which is this: "Software entities should be open for extension ,but closed for modification".

Software modules should be open for extension and closed for modification.

 

For example: when the program needs to add new functions, the original code cannot be modified, but the new code is added to achieve a hot-plugging effect (hot-plugging: flexible removal or addition of functions without affecting the original function).

 

Purpose: In order to make the program expandable, easy to maintain and upgrade.

 

Liskov Substitution Principle

The Liskov substitution principle is the cornerstone of inheritance and reuse. Only when the derived class can replace the base class and the function of the software unit is not affected, the base class can be truly reused, and the derived class can also be based on the base class. Add new behavior.

 

For example: Ball, originally a sporting goods, its derivatives include basketball, football, volleyball, badminton, etc. If the derivative replaces the original method of the base class, such as changing the sporting goods into edibles (then the software The function of the unit is affected), it does not meet the Liskov substitution principle.

 

Purpose: Specification of concrete steps to achieve abstraction.

 

Dependence Inversion Principle

Program for the interface, not for the implementation.

 

For example: take a computer system as an example, no matter the motherboard, CPU, memory, and hardware are designed for the interface, if it is designed for the implementation, the memory must correspond to the motherboard for a certain brand, then there will be a need to replace the motherboard when changing the memory. Also embarrassing to replace.

 

Purpose: To reduce the coupling between modules.

 

Interface Segregation Principle

Using multiple isolated interfaces is better than using a single interface.

 

For example: For example: login and registration belong to two interfaces of the user module, which is better than writing one interface.

 

Purpose: To improve program design flexibility.

 

Demeter Principle (Least Knowing Principle) (Demeter Principle)

In the fall of 1987, it was proposed by Ian Holland of Northeastern University in the United States, and was popularized by one of the founders of UML [Booch]. Later, he became widely known for his work in the classic book "The Pragmatic Programmer".

 

An entity should interact with other entities as little as possible, so that the functional modules of the system are relatively independent.

 

For example: the more public properties or methods a class exposes, the larger the surface involved in the modification, and the greater the risk diffusion caused by the change.

 

Purpose: Reduce the coupling between classes and reduce dependencies on other classes.

 

Single responsibility principle

This principle is given in the book Agile Software Development: Principles, Patterns, and Practices by Robert C. Martin. Martin says the principle is based on the principle of cohesion in the work of Tom DeMarco and Meilir Page-Jones.

 

A class is only responsible for the corresponding responsibilities in one functional area, or can be defined as: For a class, there should be only one reason for it to change.

 

Example: The meaning of this principle is so simple that no example is needed!

 

Purpose: Reduced class complexity, improved readability, and improved maintainability.

 

 

When you first entered the industry, what kind of code is good code? I saw that many predecessors said that good code should conform to "high cohesion, low coupling", but I heard such an explanation, it is like this

And now I have a certain degree of learning about design patterns, and I feel that I understand a little bit. Have you learned it, my friends?

 

4

High cohesion, low coupling?

Cohesion is the measurement of connections within modules from a functional perspective, and a good cohesive module should do exactly one thing. It describes the functional connections within the module;

 

Coupling is a measure of the interconnection between modules in a software structure. The strength of coupling depends on the complexity of the interface between modules, the point of entry or access to a module, and the data passing through the interface.