Design principle of design pattern

Personal Understanding:

The principles of design patterns indicate the aspects that we need to consider when designing a type. In real-world applications, it is difficult to meet all of the design principles of implementation. Programmers need to decide which principles to apply and which principles to discard based on their actual needs.

Learning design patterns require a certain understanding of object-oriented, and it is better to be able to understand UML class diagrams.

As for object-oriented, university teachers have said that objects are abstractions of real things, and they also provide a set of theories for extracting objects (nouns), attributes (nouns), and methods (verbs) from the requirements description. This understanding has given me a lot of trouble over a long period of time-many of the classes in the project should be merged into one class because they map to the same real thing. Until you read the explanation in the AS Program world: Object-oriented is simply a function of data reuse on a process-oriented basis (the latter provides the function of algorithm multiplexing). From what the Japanese say, design patterns seem to be easier to understand. here if there is a warrior can understand the object-oriented advice one or two, under the gratitude!

With regard to UML, the class diagrams in most articles/books are not strictly follow the UML specification, but are provided, so we can basically understand the UML representations of the four relationships: inheritance, implementation, composition (basic does not distinguish between composition and aggregation), dependency. Individuals also feel that the actual UML is not necessarily too strict, because the idea of generating code through UML has been proved to be less ideal, and in the agile thinking of UML is only as a temporary tool to communicate on the Whiteboard (Agile does not advocate design documents).

There are six design principles, which can be recorded as: solid principle (there are two L), as follows--

1. Single Responsibility Principle (sole responsibility principle)

It literally means that a class/interface should only be responsible for one thing. Personal feeling in the "Zen of Design Pattern", the argument is that there is only one reason why a class change should be caused.

2. Open/closed Principle (opening and closing principle)

This should be the highest heart, and the vast majority of design patterns can be mapped to this principle.

All software modules (modules, classes, methods) should be open to extensions and closed for modifications. That is, adding a new feature should not modify the original code, but instead, it is implemented by a new class/method. The benefit is that the new functionality is added without any impact on the original system, because nothing is modified (and of course, where new features are used, there is no need to change them). 0 Modification is the ideal state, in practice should make the changes as small as possible.

3. Liskov Substitution Principle (Richter replacement principle)

All occurrences of the parent class object should be replaced with the subclass object.

This principle points out the things to be aware of when implementing subclasses:

A. Subclasses must fully implement the parent class method;

B. The name of the subclass method parameter scope should be larger than the parent class method parameter scope, the return value is smaller than the parent class method return value range-so the substitution is still the parent class method is called.

Note:a: B (a inherits B), the range of a is larger than B

4. Law of Demeter (Dimitri), also known as least knowledge Principle (least knowledge principle)

One object should have as little knowledge of another object as possible. There should be no unnecessary communication between the objects.

These words are similar to what this principle wants to say: low coupling, encapsulation. For example, if I ask you to borrow an eraser, you hand the pencil box to me, then I may be in your case without your knowledge of the use of other things in your stationery, such as school if you help others pass a small note, then think you were not a lot of Yu?

5. Interface Segregation Principle (interface isolation principle)

The interface should be as small as possible (there is only one method for many interfaces). The client (the consumer of the interface) should not rely on an interface (method) that it does not need.

The benefit is that each interface can be individually extended. In practice, there is no need to consider this principle if there is no possibility of this interface changing from a business perspective.

For example, if a Web service contains two methods, two clients use two methods respectively, and if the declaration of a method is changed, the two client needs to be updated, and if a Web service contains only one method, Then you just need to update the referenced client.

6. Dependency Inversion Principle (dependency inversion principle)

Abstractions (abstract classes, interfaces) should not depend on concrete (implementation classes); High-level modules should not be dependent on the underlying modules, both of which should be dependent on abstraction.

Because the abstraction has no implementation details, it is less likely to change and more stable. The dependence on abstraction reduces the coupling between modules, making the frame more stable. In practice we should try to keep the abstraction stable, because abstract changes mean that modules that rely on abstraction need to be changed.

Design principle of design pattern