Overview of Design Patterns

The concept of design patterns was first proposed by an architect. He tried to use a structured, reusable approach to the drawings to get the basic elements of the building so that he could put a lot of other energy into the design of detailed buildings and towns. Gradually, such ideas became popular in the field of software and developed.

Design pattern is a set of reusable, most known, categorized purposes, code design experience Summary. Design patterns are used in order to reuse code, make code easier to understand, and ensure code reliability.

Design pattern is a relatively abstract content in the field of computer software. Design patterns bring us out of the complex, disturbing code that makes software systems more stable, easier to scale, and easier to maintain.

Why design patterns are needed

The application of design patterns. No matter to the individual, the enterprise, or the society has the hundred profit. First of all. It improves individual programming, thinking and design capabilities. greatly improve work efficiency. Let the individual get a greater space for development. Secondly. For the enterprise, the application design mode can make the SOFTWARE product quality is guaranteed, the system stability is greatly improved, for the enterprise to create a lot of other profit rising space; Finally, individuals and businesses are constantly growing, nature will create a lot of other social value. Make a lot of other contributions to society. Therefore, we need the design pattern, the enterprise needs the design pattern, the society also needs the design pattern. Design patterns or will become a change of a person's career destiny, a business success or failure of the key, and even a socio-economic development of an important factor.

Basic principles of software design follow

1. Single Duty principle (Responsibility Principle, abbreviation SRP)
Single responsibility principle. In the case of a class. There should be only one cause for it to change. Assuming that a class takes on too much responsibility, it is tantamount to coupling these responsibilities, and a change in one's responsibilities may weaken or inhibit the ability of the class to complete other duties. This coupling can lead to fragile designs. When the change occurs, the design suffers unexpected damage.

and software design is really a lot of things to do. is to find responsibility and to separate these responsibilities from each other.

2. Open-closed principle (the open-closed Principle, OCP)
Openness--the principle of closure. Is that software entities (classes, modules, functions, and so on) should be extensible. But can not change. That is, for the extension to be open, the change is closed. We can not do foresight, in the design when possible to make a class good enough, the design is not to change, not completely closed, when the change, we create an abstraction to isolate the future of similar changes.

3. Dependence reversal principle (dependence inversion Principle)
Dependency reversal principle. The high-level module should not rely on the lower layer module, two should be dependent on the abstraction, the abstraction should not rely on the details, the details should rely on abstraction. To be blunt is to program for the interface, not to implement programming. Take a sample: computer hardware. Assuming the memory is bad, then just need to change a memory bar can be, and do not need to change a motherboard, where memory is an interface class, just to meet his specifications, whether it is the root.

4. The principle of substitution on the Richter scale (Liskov Substitution Principle, hereinafter referred to as LSP)
On the Richter scale substitution principle, subtypes must be able to replace their parent type. In the software, replace the parent class with its subclasses. The behavior of the program does not change.

It is because of the substitution of subtypes that the modules that use the parent type can be extended without modification.

5. Dimitri rule (Law of Demeter)
The Dimitri rule, assuming that two classes do not have to communicate directly with each other, then these two classes should not have a direct interaction. It is assumed that when a class needs to invoke a method of another class, it can forward the call through a third party. The weaker the coupling between classes, the more beneficial it is to reuse. A class that is in a weak coupling is changed and does not affect the related classes. The main emphasis is on loose coupling between classes.

6, synthesis/polymerization multiplexing principle (composition/aggregation Principle]. Abbreviation carp)
Synthetic polymerization multiplexing principle. Use composition/aggregation as much as possible, and do not use class inheritance as much as possible.

The synthetic aggregation is the "has a" relationship, and the inheritance is the "is a" relationship. Because inheritance is a strongly coupled structure, the parent class changes. Subclasses must be changed. So not "is a" relationship, we generally do not use inheritance.

Preferential use of the synthetic aggregation multiplexing principle helps to preserve the encapsulation of each class. Reduce the hierarchy of inheritance.

Classification of design Patterns

According to the scope of the points. Design patterns can be categorized into class patterns and object patterns.

Class patterns are used to handle relationships between classes and subclasses. These relationships are built by several, are static, and are determined at compile time;

The object pattern is the relationship between objects, which can be changed and more dynamic when executed.

According to the goal, the design pattern can be divided into the creation mode, the structure pattern and the behavior pattern.

The create pattern is used to process the creation of objects.

Include Factory methods (Factory method)

Abstraction Factory (abstract Factory)

Builders (builder)

Prototypes (Prototype)

Single Case (Singleton)

A structured pattern is used to handle a combination of classes or objects;

Include Adapter (Adapter)

Bridging (Bridge)

Combination (Composite)

Decorator (Decorator)

Appearance (facade)

Enjoy RMB (Flyweight)

Agent (proxy)

Behavioral patterns are used to describe how classes or objects interact and assign responsibilities.

Includes chain of responsibility (Chain of Responsibility)

Order (command)

Interpreter (interpreter)

Iterators (Iterator Pattern)

Mediator (mediator)

Memorandum (Memento)

Viewer (Observer)

Status (state)

Strategy (strategy)

Template method

Visitors (Visitor)

Design pattern is the summary of predecessors ' practical experience. Is the crystallization of thoroughly tempered thought. We learn the design pattern is not the real purpose, our real purpose is to learn such ideas, and in practice in the detailed application. and learn to sum up and summarize, let our thinking active, no longer adhere to the computer coding, but rise to a certain theoretical space. Let the theory guide practice, Practice enrich the theory, so that it will form a virtuous circle. Constantly improve their theoretical and practical ability, so as to achieve the greatest social value of the individual.

Overview of Design Patterns