C++ design pattern notes object-oriented design principles

B station 23 design patterns study notes

1. Title object-oriented design, why?

Change is the natural enemy of reuse! The biggest advantage of object-oriented design is: resist change

Second, recognizing object-oriented

1. Understand changes in isolation

From a macro perspective, the object-oriented construction method is more adaptable to software changes and minimizes the impact of changes;

2. Perform their duties
  • From a micro-level perspective, the object-oriented approach emphasizes the "responsibility" of each category;
  • The new types due to changes in demand should not affect the realization of the original types, that is, the so-called responsibility for each;
3. What is the target?
  • From the perspective of language implementation, objects encapsulate code and data;
  • From a specification level, an object is a series of public interfaces that can be used;
  • From a conceptual perspective, the object is an abstraction with responsibility;
Three, object-oriented design principles

Principles are more important than patterns

1. Dependence Leads Principle (DIP)
  • High-level modules (stable) should not depend on low-level modules (changes), both should rely on abstraction (stable);
  • Abstraction (stability) should not depend on implementation details (changes), and implementation details should depend on abstraction (stability);
  • Use virtual virtual function
2. Open and Closed Principle (OCP)
  • Open to expansion, closed to change;
  • The class module should be extensible, but not changeable;
  • (Compile-time dependency -> Run-time dependency)
3. Single Responsibility Principle (SRP)
  • A class should have only one reason for its change;
  • The direction of change implies the responsibility of the class;
4. Liskov Substitution Principle (LSP)
  • Subclasses must be able to replace their base class (IS-A);
  • Inheritance expression type abstraction;
5. Interface Isolation Principle (ISP)
  • Client programs should not be forced to rely on methods they do not use;
  • The interface should be small and complete;
6. Prefer object composition instead of class inheritance
  • Class inheritance is usually "white box reuse", and object composition is usually "black box reuse";
  • Inheritance destroys the encapsulation to a certain extent, and the coupling between subclass and parent class is high;
  • The object combination only requires that the combined object has a well-defined interface, and the degree of coupling is low;
7. Packaging changes
  • Use encapsulation to create a boundary layer between objects, allowing designers to modify on one side of the boundary layer without adversely affecting the other side;
8. Programming for the interface, not for the implementation
  • Do not declare the variable type as a specific concrete class, but as an interface;
  • The client program does not need to know the specific type of the object, only the interface that the object has;
  • Reduce the dependence of each part of the system, so as to realize the "high cohesion, low coupling" type design scheme;

Fourth, upgrade design principles to design experience

1. Design idioms Dseign Idioms
  • Design Idioms describe low-level patterns, techniques, and idioms related to a specific programming language;
2. Design Patterns
  • Design Patterns mainly describe the "combination relationship between classes and mutually communicating objects", including their roles, responsibilities, and collaboration methods;
3. Architectural Patterns
  • Architectural Patterns describe the high-level patterns in the system that are closely related to the basic architecture organization, including the division of subsystems, responsibilities, and the rules for how to organize the relationship between them;

Guess you like

Origin blog.csdn.net/weixin_40437821/article/details/111461542