Seven major object-oriented design principles and seven major design principles

Seven major object-oriented design principles (Transition) and seven major design principles

I. Single responsibility principle:

Full name: "Single-Responsibility Principle"

Object-Oriented Design

Note: For a class, you should focus only on one thing and only one cause of its changes. The so-called responsibility, we can understand it as a function, that is, this class function should have only one, not two or more. It can also be understood as the reason for referencing changes. When you find that two changes require us to modify this class, you should consider removing this class. Because responsibility is an axis of change, when the demand changes, this change will reflect the changes in class responsibilities.

Note the following when using SRP:

1. A reasonable class should have only one reason for its change, that is, a single responsibility;

2. It is unwise to apply the SRP or other principles without any signs of change;

3. the SRP principle should be applied to reconstruct the code when the actual requirement changes;

4. Using test-driven development forces us to separate unreasonable code before the design smells bad;

5. If the test cannot force separation of duties, and the odor of rigidity and vulnerability will become very strong, We Should refactor the code in Facade or Proxy mode; SRP advantages: eliminate coupling, reduce code Rigidity caused by demand changes.

Ii. Li's replacement principle

Full name: "Liskov Substitution Principle"

Note: child types must be able to replace their base types. If a software entity uses a base class, the program behavior will not change if the base class is replaced with a subclass that inherits the base class. The software entity does not notice the difference between a base class object and a subclass object.

Advantage: it is easy to implement the interchange of sub-classes under the same parent class, and the client can not notice it.

Iii. Dependency inversion principle

Full name: "Dependence Inversion Principle"

Note: It depends on abstraction rather than specifics. The client depends on abstract coupling.

Abstraction should not depend on details; details should depend on abstraction;

Programming for interfaces is not implemented.

Advantage: The dependency relationships created by traditional procedural programming are dependent on details, which is poor because the policies are affected by changes in details. The dependency inversion principle makes the details and policies depend on abstraction. The stability of abstraction determines the stability of the system.

How can we put the dependency upside down?

Coupling in an abstract way is the key to the dependency reversal principle. Abstract Coupling Relationships always involve the inheritance of a specific class from an abstract class, and must be ensured that the class can be changed to its subclass in any reference to the base class. Therefore, the Li's replacement principle is the basis of the reversal principle.

Coupling at the abstract level is flexible, but it also brings additional complexity. If a specific class is less likely to change, the benefits of abstract coupling are very limited, in this case, coupling is better.

Hierarchical: all well-structured object-oriented architectures have clear hierarchical definitions, and each layer provides services in a group through a well-defined and controlled interface.

Dependent on Abstraction: We recommend that you do not rely on specific classes, that is, all dependencies in the program should end with abstract classes or interfaces. Try:

1. No variable should hold a pointer or reference pointing to a specific class.

2. No class should be derived from a specific class.

3. No method should overwrite the implemented methods in any of its base classes.

Iv. Interface isolation principles

Full name: "Interface Segregation Principle"

Note: interfaces with multiple specific functions are always better than interfaces with one function. From the perspective of a customer class: the dependence of a class on another class should be based on the minimum interface. Interfaces that are too bloated are contaminated and should not be forced to rely on methods they do not need.

Advantage: When a software system is extended, the modification pressure will not be transferred to other objects.

How to Implement the interface isolation principle

Users should not be forced to rely on methods they do not need.

1. Use the delegate isolation interface.

2. Use the multi-inheritance isolation interface.

V. dumit principles

Full name: "Law of Demeter"

Note: objects and objects should be associated using as few methods as possible to avoid link relationships.

How to Implement the dimit rule?

The primary purpose of the dummit rule is to control information overload. When applying it to system design, pay attention to the following points:

1) The division of classes should create classes with weak coupling. The weaker the coupling between classes, the more conducive it is to reuse.

2) In the structure design of classes, each class should minimize the access permissions of members. A class should not have its own public attributes. Instead, it should provide a method of value and value assignment to allow the outside world to indirectly access its own attributes.

3) in the design of classes, a class should be designed as a constant class as long as possible.

4) When referencing other objects, the reference of a class to other objects should be minimized.

Vi. Opening-closing Principle

Full name: "Open-Closed Principle"

Note: It is open to extensions and closed to modifications.

Advantages: the system designed according to the OCP principle reduces the coupling between various parts of the program, and has good adaptability, flexibility, and stability. When new functions need to be added to an existing software system, you do not need to modify the abstraction layer as the system base, you only need to add a new module on the original basis to implement the required functions. The new module has no influence on the original module or has little impact, so you do not need to re-test the original module.

How to implement the "open-close" principle?

In object-oriented design, the abstraction layer of the system is not allowed to be changed, but the Implementation Layer of the system is allowed to be extended. In other words, define an abstract design layer once and for all to allow as many actions as possible to be implemented at the implementation layer.

The key to solving the problem lies in abstraction. abstraction is the first core essence of object-oriented design.

Abstract A thing is, in essence, a summary of its essence. Abstract Let us grasp the most important thing and think from a higher layer. This reduces the complexity of thinking. We don't need to consider so many things at the same time. In other words, we encapsulate the essence of things and cannot see any details.

In object-oriented programming, abstract classes and interfaces are used to specify the features of a specific class as the abstract layer. This layer is relatively stable and does not need to be changed, so as to "Disable modification "; the specific class exported from the abstract class can change the behavior of the system to meet the requirement of "open to extension ".

You do not need to modify the source code or binary code of the software when you expand an object. The key lies in abstraction.

VII. Principles of synthetic recovery:

Full name: (Composite Reuse Principle, CRP)

Try to use object combinations instead of inheritance for reuse purposes.

Composite/Aggregate Reuse Principle CARP ). combination and aggregation are one of the associations in object modeling. aggregation indicates the relationship between the whole and the part, indicating "containing". The whole is composed of parts, and parts can be separated from the whole as an independent individual. A combination is a stronger aggregation, which consists of parts and is inseparable. parts cannot exist independently from the whole. In a compositing relationship, similar to the overall life cycle, new objects in a combination completely control their components, including their creation and destruction. A splitting object in a compositing relationship cannot be shared with another compositing relationship.

Combination, aggregation, and inheritance are two basic ways to achieve reuse. The principle of merging reuse refers to the use of synthesis/aggregation as much as possible, rather than inheritance.

The inheritance relationship should be used only when all of the following conditions are met.

1. A subclass Is A special category of A superclass, rather than A role of A superclass, that Is, to distinguish between "Has-A" and "Is-". only the "Is-A" link conforms to the inherited link. The "Has-A" link should be described by aggregation.

2. There will never be a situation where you need to replace a subclass with another subclass. If you are not sure whether it will become another subclass in the future, do not use inheritance.

3. subclass has the responsibility to expand the superclass, rather than replacing or canceling the superclass. If a subclass needs to replace a large number of superclasses, this class should not be a subclass of this superclass.

A common cause of incorrect inheritance rather than merging/aggregation Is that "Has-A" Is incorrectly treated as "Is-". "Is-A" indicates that A class Is another class, while "Has-A" indicates that A class Is A role of another class, it is not a special type of another class.