Six design principles of design pattern

The open-closed principle was mentioned in the previous blog post, not in detail. This time, let's summarize some of the principles of design patterns.

1 Open-closed principle: refers to the software entities (classes, modules, functions, etc.) should be able to expand, but can not be changed.

The principle of understanding: the opening and closing principle is the most idealistic color of a principle, it is the ultimate goal of object-oriented design, the following principles to be introduced in order to meet the opening and closing principle of the efforts and solutions.

For the open and closed principle of popular understanding is. Can not change without change. Can change as little as possible. Zhou is known that the material is movement, the world is changing, want to let a thing immutable is impossible, so it is impossible to make software absolutely conform to the opening and shutting principle.

2 single Responsibility Principle (SRP): For a class, there should be only one cause for it to change.

In layman's terms, it is a class or a module that only does one thing, or that the class or module only plays a role. It just needs to do its job well. No matter what else, never be blind.

For example, when we are doing the software, we define a class that is responsible for connecting to the database, and the data operation after the connection is given to other functions. Don't all come up on your own. It would be troublesome to change the database in the meantime.

3 Dependency reversal principle: A High-level module should not rely on the underlying module.

Two should all rely on abstraction. B abstractions should not be dependent on detail, and detail should be dependent on abstraction.

In layman's terms, it is to program for the interface, not to implement programming. In process-oriented software development. In order to be able to implement code reuse, it is common to use some of the code used to write functions, a large number of functions to form a function library, so when the new project. It is possible to invoke these underlying functions, which are called high-level modules that rely on the underlying module. What we want to achieve is that there is no very strong coupling between the high-rise module and the low-level module. No matter what side can be very easy to be reused, so we have to find a way to design and programming the interface between them, in the reuse of only need to change the interface or abstract class.

4 Richter Substitution principle: subtypes must be able to replace their parent type.

The definition of this principle is very short, and I believe it should not be difficult to understand. To put it bluntly, a software entity assumes that a parent class is used, replacing the parent class with its subclasses. The program can still compile and pass. and normal execution.

To be able to say that the Richter substitution principle is the basis of inheritance multiplexing technology. Give me a sample example. The animal class is the parent class. Cat, dog. Cattle, sheep for its subclasses. When we instantiate an animal class object: The Animal animal= New Cat (). Cats have a way to eat and drink from a parent animal. And when the dog is replaced by the cat, namely: Animal Animal =new Dog (), can still be compiled and executed, no matter what disharmony in the place. This is the embodiment of the principle of substitution on the Richter scale.

5 Dimitri rule: Assume that two classes do not have to communicate directly with each other. Then the two classes should not have a direct interaction. Suppose one of the classes needs to invoke one of the methods of a class. The ability to forward this call through a third party.

The principle of understanding: Dimitri Law has an alias called the least knowledge principle, the core of the idea is to reduce the coupling between classes and classes as much as possible, the white is not to communicate with strangers, just as we want to find someone to work, can help you people. You do not know, then you will find a person you know the same time you know someone to do the middleman, let the middleman to help you convey your meaning, so that you can be very good to finish what you want to do.

6 synthesis/Aggregation multiplexing principle: use composition/aggregation as much as possible, and do not use class inheritance as much as possible.

The so-called aggregation represents a weak ownership relationship. It shows that a object can include a B object. But the B object is not part of the A object, and the composition is a strong owning relationship. Reflects a strict relationship between the part and the whole. Part is the same as the overall life cycle.

Using the composition/aggregation of objects preferentially in programming will help keep each class encapsulated. And is focused on a single task. Such class and class inheritance hierarchies are kept small. And it is unlikely to grow to an uncontrollable behemoth.

We strive to comply with the above principles when designing our software. Strive to write code that is maintainable, reusable, extensible, and flexible.

Six design principles of design pattern