one. The basics of OO (object-oriented) design
Object-oriented (OO): It is based on the object concept, with object-centered, class and inheritance as the construction mechanism, and makes full use of interfaces and polymorphisms to provide flexibility to understand, understand, characterize the objective world, design and build corresponding software systems. Object-oriented features: Although various object-oriented programming languages are different from each other, they can all see their support for object-oriented basic features.
That is, "abstract, encapsulation, inheritance, polymorphism":
– Abstract,No details to consider
– Package,Hide internal implementation
– Inheritance,Reuse existing code
– polymorphism,Rewrite object behavior
Object-oriented design pattern: It is "good object-oriented design". The so-called "good object-oriented design" are those designs that can meet "coping with changes and improving reuse". The object-oriented design pattern describes software design, so it is independent of the programming language, but the final implementation of the object-oriented design pattern is still expressed in an object-oriented programming language. Object-oriented design patterns are not like algorithm techniques, and can be copied and used. They are empirical understanding based on a pure and in-depth understanding of "object-oriented".
Here we can see a big description of the concept and relationship between objects and design patterns below. When we design, we fully understand and use the four basic features of OO to expand the design. Therefore, we must be familiar with and master object-oriented technology before designing. I won’t introduce it in detail here. Design patterns provide us with reference models during design. The prerequisite for mastering object-oriented design patterns is to first master the "object-oriented" technology.
two. OO (Object Oriented) Design Objectives
※Extensibility:With new requirements, new performance can be easily added to the system without affecting existing performance and without causing new defects.
※Modification Flexibility:When a part of the system is modified, the existing structure of the system will not be damaged or affected by other parts.
※Replaceability Pluggability:Some code in the system can be replaced with other classes of the same interface, and will not affect the system.
three. Five principles of OO design and their relationships
3.1 Summary of OO design principles
※The principle of single responsibility:As far as a class is concerned, there should be only one reason for its change. Single is an excellent design for a class. The mixed responsibilities will make the code look particularly awkward and affect the whole body, which will be risky of losing beauty and inevitably leading to ugly system errors.
※The principle of openness and closure:It means that software entities (classes, modules, functions, etc.) should be extended but not modified. The core idea of realizing the principle of openness and closure is to program abstractly, not concretely, because abstraction is relatively stable. Let the class rely on fixed abstractions, so modification is closed; and through object-oriented inheritance and polymorphic mechanisms, inheritance of abstract classes can be realized, and the inherent behavior can be changed by overwriting its methods and implementing new expansion methods, so it is open. "Demand always changes" does not have constant software, so the principle of closed and openness needs to be used to close changes to meet demands, while also maintaining the packaging system within the software stable and not affected by changes in demand.
※The principle of dependency inversion:Rely on abstraction, not on concrete. The stability of abstraction determines the stability of the system, because abstraction is unchanged, and relying on abstraction is the essence of object-oriented design and the core of the principle of reliance on inversion. Relying on abstraction is a general principle, and sometimes relying on details is inevitable. The choice between abstraction and concrete must be weighed, and the method is not unchanged. Relying on abstraction means programming interfaces, not implementations.
※Risch substitution principle:Subtypes must be able to replace their parent type. The Liskov replacement principle mainly focuses on the basis of inheritance of abstraction and polymorphism. Therefore, only by following the Liskov replacement principle can inheritance and reuse be reliable. The implementation method is interface-oriented programming: abstracting the public part into a base class interface or abstract class, and implementing a new way to support the same responsibilities in a subclass by overwriting the parent class method through ExtractAbstractClass. The Liskov replacement principle can ensure that the system has good scalability, and at the same time realize a polymorphic abstraction mechanism, which can reduce code redundancy and avoid type discrimination during the runtime.
※Interface isolation principle:Multiple customer-related interfaces are better than one general interface. There are two main methods of separation: 1. Delegation separation, delegating customer requests by adding a new type, isolating the direct dependence of customers and interfaces, but it will increase system overhead. 2. Multiple inheritance and separation, and multiple inheritances are used to realize customer needs. This method is better.
Below are two principles not mentioned above, and are also important principles to consider during design.
※Dimit's Law:Do not interact directly between classes that do not communicate directly with each other. If two classes do not have to communicate directly with each other, then the two classes should not interact directly. If a class needs to call a method of a class, you can forward the call through a third party. The first premise that Dimit's law emphasizes is that in the design of the class, each class should minimize the access rights of members. Its fundamental idea is to emphasize loose coupling between classes.
※The principle of synthesis/polymerization:Try to use synthesis/aggregation, and try not to use inheritance. Composition and Aggregation are both special types of association. Aggregation represents a weak ownership relationship; synthesis is a strong ownership relationship, reflecting the strict relationship between part and whole, and the life cycle of part and whole is the same. Prioritizing the use of synthesis or aggregation principles will help keep each class encapsulated and focused on a single task. This way, class and class inheritance levels will remain small and are unlikely to grow into uncontrollable behemoths
3.2 The relationship between OO design principles
1. The key step in realizing the "Open-Close" principle (OCP) is abstraction. The inheritance relationship between base class and subclass is the embodiment of abstraction. Therefore, the Richter substitution principle is a norm for the specific steps to achieve abstraction. Violating the Lizhni substitution principle means violating the "open-closing" principle, otherwise it may not be.
2. The "open-close" principle and the dependency reversal principle (DIP) are the relationship between goals and means. If the principle of opening and closing is the goal, the principle of reliance on the inversion is the means to reach the principle of "open and closing". If you want to achieve the best "opening and closing" principle, you must try to abide by the principle of reliance inversion, which is the best standard for "abstract".
3. The Lisch substitution principle (LSP) is the basis of the principle of dependence inversion, and the principle of dependence inversion is an important supplement to the Lisch substitution principle.
4. The Interface Separation Principle (ISP) is also an important means to ensure the "open-closed" principle.
5. Regarding the Single Responsibility Principle (SRP), I personally think it is better to do it as much as possible. The more single the responsibilities, the easier it is to achieve "open-closed" and Richter substitution.
Four. The relationship between OO design principles and goals
1. Extensibility:Allowing a new class with the same interface to replace the old class is a multiplexation of abstract interfaces. The client relies on an abstract interface, rather than a concrete implementation class, so that this concrete class can be replaced by other concrete classes without affecting the client. The following principles achieve scalability.
※Open/close principle
※Risch replacement principle
※The principle of reliance
※The principle of synthesis/polymerization
2. Modification Flexibility:The modules are relatively independent and communicate as little as possible. This way, when one module is modified, the impact on other modules is very small.
The following principles achieve modifiability.
※Open/close principle
※Dimit's Law
※Interface isolation principle
3. Replaceability Pluggability:When a part no longer meets the needs, the old part can be pulled out and the new part can be inserted.
The following principles achieve interchangeability.
※Open/close principle
※Risch substitution principle
※The principle of reliance
※The principle of synthesis/polymerization
five. OO (Object Oriented) Design Process
1. Analyze the style and perform functional classification.
2. Abstraction of classes according to functions.
※Abstract of classes - In this step, we can perform concrete abstraction of classes based on the "single responsibility principle". Try to make the class's functions single and clear.
※ Encapsulation change point – 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, thereby achieving loose coupling between levels.
3. Design abstract base classes and interface classes.
※ When performing basic base class abstraction and interface definition, the interface abstraction must be followed in accordance with the "interface separation principle".
※ When designing interfaces and base classes, don’t always pay attention to details. Remember to program for interfaces, not for implementations.
※ The requirement of "Rischer's replacement principle" should be met between abstract base classes and derived classes.
4. Determine the coupling relationship between classes.
4.1 What is the basis for determining the degree of coupling?
※ Simply put, the degree of coupling is determined based on the stability of demand.
※For high stability requirements and unfavorable changes, we can design all kinds of products into tight coupling, because this can improve efficiency, and we can also use some better technologies to improve efficiency or simplify code.
※ If the requirements are very likely to change, we need to fully consider the coupling problem between classes. We can come up with various ways to reduce the degree of coupling, but in summary, it is nothing more than adding abstract levels to isolate different classes. This abstract level can be an abstract class, a concrete class, an interface, or a group of classes. We can summarize the idea of reducing coupling in one sentence: "Programming for interfaces, not implementations."
※ When deciding on the coupling relationship of a class, try to consider the "Dimit rule" and the "synthesis/aggregation and multiplexing principle".
4.2 How to reverse dependency?
※ Coupling in an abstract way is the key to relying on the principle of inversion. Abstract coupling relationships always involve the inheritance of concrete classes from abstract classes, and it is necessary to ensure that they can be replaced with their subclasses anywhere referenced to the base class. Therefore, the Richter substitution principle is the basis of the principle of dependence inversion.
※ Depend on abstraction: It is recommended not to rely on concrete classes, that is, all dependencies in the program should terminate in abstract classes or interfaces. Try to do:
(1) No variable should hold a pointer or reference to a specific class.
(2) No class should be derived from concrete classes.
(3) No method should override any implemented methods in any base class.
5. Use the five principles of OO design to further optimize the design
※For the abstraction and function of the class, does it satisfy the "single responsibility principle"?
※For inheritance relationships and reference base classes, do we meet the "Risch substitution principle" and "dependence inversion principle"?
※For interfaces and base classes, is it "interface isolation principle"
※ In general, whether the "open-closing principle" is met
Generally speaking, when object-oriented design, the five major principles of design should be fully considered, but they are not forced. The blind pursuit of meeting the principle may also lead to the consumption of the designed system in performance and resources. It can be analyzed and designed in detail according to the specific situation.
The above article briefly discusses the concept and design principles of OO in Java (must read) is all the content I share with you. I hope you can give you a reference and I hope you can support me more.