Six principles of design pattern: single responsibility principle

There are six principles in design mode: Interface isolation

Six principles of design pattern: dependency inversion principle

Six principles of design pattern: Richter’s substitution principle

There are six principles of design patterns: Demeter’s Law

Six principles of design pattern: open and close principle

Open Close Principle:

Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.

Software objects (classes, modules, methods, and so on) should be open for extension and closed for modification. For example: a network module, originally only server function, but now to add the client function, then without modifying the server function code, the client function can be added to the implementation code, which requires that at the beginning of the design, the client and the server should be separated. The common part is abstracted out.

Origin of the problem:

During the software life cycle, when the original code of the software needs to be modified due to changes, upgrades and maintenance, errors may be introduced into the old code, and the whole function may have to be reconstructed, and the original code needs to be re-tested.

Solutions:

When software needs to change, try to do so by extending the behavior of software entities rather than by modifying existing code.

Open and close principle is the most basic design principle in object-oriented design, it guides us how to establish stable and flexible system. The open and closed principle is probably the most ill-defined of the six principles of design pattern. It only tells us to open for extension and close for modification, but it doesn’t tell us exactly how to open for extension and close for modification. In the past, if someone told me, “You have to follow the open and closed principle when you design,” I would think he didn’t say anything, but he kind of said everything. Because the open close principle is really too weak.

In fact, I think that the open closed principle is nothing more than to express such a layer of meaning: use abstraction to build the framework, use implementation to expand the details. Because abstraction has good flexibility and wide adaptability, as long as abstraction is reasonable, it can basically maintain the stability of software architecture. And the changeable details in the software, we use the implementation class derived from the abstract to carry on the extension, when the software needs to change, we only need to derive an implementation class to expand according to the requirements. The premise, of course, is that our abstractions should be reasonable, forward-looking and predictive of changes in requirements.

Building the framework with abstractions and extending the details with implementations is just a matter of note:

  • The single responsibility principle tells us to implement a class with a single responsibility;

  • Richter’s substitution tells us not to break the inheritance system;

  • The dependency inversion principle tells us to program for interfaces;

  • The principle of interface isolation tells us to keep interfaces simple and simple when designing them.

  • Demeter’s rule tells us to reduce coupling.

  • The open closed principle is the general principle, he told us to be open to expansion, closed to modification.

Why use the open close principle?

1, as long as it is object-oriented programming, in the development process will emphasize the open and closed principle

2, is the most basic design principles, the other five design principles are the specific form of the open and closed principle

3. Improve code reuse

4, can improve the maintainability of the code

How to use the open close principle?

1. Abstract constraints

An abstract general description of a set of things without a concrete implementation means that it can have a wide range of possibilities and can change as needs change. Thus, an interface or abstract class can constrain a set of behaviors that can change, and it can be open to extension.

2, metadata control module behavior

3. Formulate the project charter

4. Packaging changes

Encapsulate the same change in an interface or abstract class, and encapsulate different changes in different interfaces or abstract classes. There should not be two different changes in the same interface or abstract class.

example

Front end: Encapsulates a common component that is not modified but can be extended when used in different scenarios. The common component receives the children from the parent component, and then uses different children in different scenarios. However, the common component does not need to be changed. The receiver is an extension of the parent component.

The example might not be the right one but that’s the point.

Source: www.cnblogs.com/az4215/p/11…