Design pattern
- What is design pattern
- Principles of design pattern
- Pending, updating
If the development of cultivation software is regarded as the cultivation of martial arts, it can be divided into moves and internal skills.
The moves can be divided into:
C + +, java, python, lua, and other programming languages
visual studio, eclipse and other development tools
Qt, JSP, etc,
Then the internal skill is:
Algorithm, design mode, reconstruction, software engineering thinking are internal skills.
Why learn design patterns
Moves can be learned faster through many documents and videos, while internal skill needs to accumulate day and night. Learning and understanding design patterns can greatly increase the internal skill of programmers. Design patterns are not limited to a certain language, but are products of object-oriented development mode
Where design patterns come from
Proposed by Christopher Alexander, Ph.D., architecture
"Each pattern describes an emerging problem in our environment," and then describes the core of the solution to the problem. In this way, we can reuse the existing successful solutions countless times without repeating the same work. "
One sentence summary: "under certain circumstances, use fixed routines to solve problems."
Principles of design patternObject oriented design principles
For the design of object-oriented software system, how to improve the maintainability and reusability of a software system at the same time is one of the core problems to be solved in object-oriented design. In object-oriented design, reusing maintainability is based on design principles. Each principle contains some object-oriented ideas, which can improve the design level of a software structure from different perspectives.
Purpose of the principle: high cohesion and low coupling
Principle of single responsibility
The responsibility of a class is single, and only one function is provided to the outside world. The reason for class changes is that there should be only one
Principle of opening and closing
Class changes are made by adding code, not modifying the source code, because modifying the code may cause the function that has been done to need to be re debugged.
// The opening and closing principle is open to extension, closed to modification, and the added function is realized by adding code instead of modification // Suppose you have a calculator class class Calculator { public: Calculator(int a, int b, string symbol){ this->a = a; this->b = b; this->symbol = symbol; } int getResult() { if (symbol.compare("+") == 0) { return this->a + this->b; } if (symbol.compare("-") == 0) { return this->a - this->b; } if (symbol.compare("*") == 0) { return this->a * this->b; } if (symbol.compare("/") == 0) { return this->a / this->b; } return 0; } private: int a; int b; string symbol; }; //This class can add, subtract, multiply, divide, etcgetResult()Modify the code in the function, //This violates the principle of closing down changes. In this way, there is also the possibility of error. When adding new functions, we should not affect other completed functions, //This is to close the modification. // So we can define its structure like this // Define an abstract calculator class first // Suppose you have a calculator class class AbstractCalculator { public: virtual int getResult() = 0; }; class AdditionCalculator : public AbstractCalculator { public: AdditionCalculator(int a, int b) { this->a = a; this->b = b; } virtual int getResult() { return a + b; } private: int a; int b; }; // Implement subtraction calculator class SubtractionCalculator : public AbstractCalculator { public: SubtractionCalculator(int a, int b) { this->a = a; this->b = b; } virtual int getResult() { return a - b; } private: int a; int b; }; // At this time, if you need to add a new modular operation // Just add a new class class ModuloCalculator : public AbstractCalculator { public: ModuloCalculator(int a, int b) { this->a = a; this->b = b; } virtual int getResult() { return a % b; } private: int a; int b; }; int main() { // In this way, when we use it, we only need to make use of the polymorphic feature, point to the subclass through the abstract class object pointer, and then we can call the function corresponding to the subclass AbstractCalculator* Calculator = new SubtractionCalculator(10, 12); cout << Calculator->getResult() << endl; system("pause"); return 0; } //In this way, the extensibility of the code is enhanced, and the principle of dependency inversion is followed, which depends on abstraction(Interface)，Don't rely on specific implementation(class)，Programming for interfaces
Richter's principle of substitution
Any place where an abstract class appears can be replaced by its implementation class. In fact, it is a virtual mechanism. The language level implements object-oriented functions (that is, polymorphism)
Dependence Inversion Principle
Rely on abstraction (Interface), not on concrete implementation (class), i.e. programming for interface
Interface isolation principle
Users' programs should not be forced to rely on interface methods they do not need. An interface should only provide one external function, and should not encapsulate all operations into one interface.
Principle of composite reuse
If inheritance is used, any change of the parent class may affect the behavior of the child class. If object composition is used, this dependency will be reduced. For inheritance and combination, leisure use combination
Dimiter's law
(also called the minimum knowledge principle)
An object should know as little about other objects as possible, so as to reduce the coupling between objects and improve the maintainability of the system. For example, in a program, when each module calls each other, it usually provides a unified interface to realize, so that other modules do not need to know the internal implementation details of another module, which will not affect the use of other modules when the internal implementation of one module changes. (black box principle)