Six principles of design pattern-Single duty principle, open closure principle, reliance reversal principle, Richter substitution principle, Dimitri rule, synthesis/aggregation reuse principle _ Extension

Principle, so the name incredible is the essence meaning. The so-called grasp the thief first, study design pattern nature must first understand the design principle, all models are on the basis of these principles developed, some focus on one, there are a number of many are involved. After reading the design pattern, I feel that each pattern has the shadow of these principles, but also permeate the three attributes of object-oriented, also feel that these principles have similarities, it is with them to let us from the code workers to artists. Next, I would like to comment on the six principles, I hope you take the brick:

1. Principle of sole responsibility (single responsibility principle, referred to as SRP)
The principle of single responsibility, in the case of a class, should have only one cause for its change. If a class undertakes too many responsibilities, it is tantamount to coupling these responsibilities together, and a change in responsibility may weaken or the ability of the class to perform other duties. This coupling can lead to fragile design, and when the change occurs, the design will suffer unexpected damage. And many of the things that software design really needs to do is to identify responsibilities and separate them from each other.

Remark: Cohesion well-structured classes poly low coupling of the perfect embodiment, do not mess up relations, is very good.

2, open-closed principle (the open-closed principle, referred to as OCP)
The open-closed principle is that software entities (classes, modules, functions, and so on) should be extensible, but not modified. That is, for the extension to be open, for the change to be closed. We can not be a prophet, in the design of the time as far as possible to make a class good enough, the design is not to be modified, not completely closed in the case, when the change, we create an abstraction to isolate the same kind of changes that occur.

Remark: Open expansion, closed change, opening and closing is an art.

The Open closure principle (Ocp,open Closed principle) is the core of all object-oriented principles. The goal of software design itself is to encapsulate change and reduce coupling, and the open closure principle is the most direct embodiment of this goal. 　　Other design principles, often in order to achieve this goal, such as the Liskov substitution principle to achieve the best and right level of inheritance, can guarantee that the open closure principle will not be violated. On the principle of open closure, the core idea is that the software entity should be extensible and not modifiable. 　　In other words, the extension is open, and the modification is closed. 　　Therefore, the principle of open closure is mainly embodied in two aspects: open to expansion, means that there are new requirements or changes, the existing code can be extended to adapt to the new situation. 　　Closing a modification means that once the class has been designed, it can complete its work independently, without any modification to the class. "Demand is always changing", "no software in the world is unchanged", these comments are the most classic of the software requirements of the confession. One of the key points of transmission is that for software designers, flexible system extensions must be implemented without the need for modifications to the original system. 　　And how can this be done. Only depends on the abstraction. The core idea of realizing open closure is to abstract programming, but not to specific programming, because abstract is relatively stable. Let class rely on fixed abstraction, so it is closed to modification, and through object-oriented inheritance and polymorphism mechanism, we can inherit the abstract body, rewrite its method to change the intrinsic behavior, realize new extension method, so it is open for extension. This is the basic idea of implementing the open closure principle, and this mechanism is based on two basic design principles, that is, the Liskov substitution principle and the synthesis/aggregation reuse principle. Regarding these two principles, we have the corresponding elaboration in the other part of this book, in the application reconsidering part will have the thorough discussion.

For classes that violate this principle, refactoring must be done to improve, and the design patterns commonly used for implementation are mainly template method and strategy. And encapsulation change is an important means to achieve this principle, and will often change the state of packaging into a class.

3. The principle of reliance reversal (dependence inversion principle)
Relying on the inverted principle, the high-level module should not rely on low-level modules, two should rely on abstraction, abstraction should not rely on details, the details should rely on abstraction. The plain thing is to program for the interface, not to implement programming. For example: computer hardware, if the memory is broken, then only need to change a memory bar on it, and do not need to change a motherboard, where memory is an interface class, as long as the requirements of his specifications on the line, regardless of that one.

Remark: When building a construction to be a designer, not a brick and mortar, abstract blueprint to rely on a little bit of concrete material to achieve.

Abstractions should not be dependent on detail, and details should depend on abstraction. 　　Programming for interfaces, not for implementation. 　　Pass parameters, or, in a combinatorial aggregation relationship, refer to a hierarchy of classes as much as possible. 　　Mainly in the construction of objects can dynamically create a variety of concrete objects, of course, if some specific classes more stable, you do not have to get an abstract class to do its parent, so there is the feeling of superfluous. 　　Advantages: Flexible system expansion. Disadvantage: A large number of classes are required.

4, the Richter substitution principle (Liskov substitution principle, referred to as LSP)
The Richter substitution principle, the subtype must be able to replace their parent type. In software, the behavior of the program is not changed by replacing the parent class with its subclass. It is because of the interchangeability of subtypes that the modules that use the parent type can be extended without modification.

Remark: The elders gave you the right to inherit must do the maintenance obligation, the responsibility of the elders to bear up.

The principle of the Richter substitution (Liskov substitution principle LSP) is one of the basic principles of object-oriented design. The Richter substitution principle says that where any base class can appear, subclasses must be present. LSP is the cornerstone of inheritance reuse, only if the derived class can replace the base class, the function of the Software unit is not affected, the base class can be truly reused, and the derived class can add new behavior on the base class. The principle of the Richter substitution is a supplement to the "open-closed" principle. The key step in implementing the "open-closed" principle is abstraction. And the inheritance relation of the base class and subclass is the concrete realization of abstraction, so the principle of the Richter substitution is the specification of the concrete steps to realize abstraction.

To illustrate, let's first look at an example with the first method, and the second approach in another principle. Let's look at the famous example of rectangles and squares. For a rectangular class, if its long width is equal, then it is a square, so there are some square objects in the object of the rectangular class. 　　For a square class, its method has a setside and a getside, it is not a subclass of rectangles, and rectangles do not conform to LSP. 　　Eg: Rectangular class: public class rectangle{... setwidth (int width) {this.width=width; setheight (int height) {this.height=height}} Square Class: public class square{... setwidth (int width) {This 　　. width=width; This. 　　Height=width; 　　} setheight (int height) {this.setwidth (height); 　　The function that changes the edge length in the example: public void resize (Rectangle r) {while (R.getheight () <=r.getwidth) {r.setheight (r.getwidth+1); So, what happens if you make a square as a subclass of rectangles? We let the square inherit from the rectangle, and then set the width equal to the height in its interior, so that if the width or height is assigned, then the width and height are assigned at the same time, so that the square class Width and height are always equal. Now we assume that there is a customer class, which has a method, the rule is this, test the width of the incoming rectangle is greater than the height, if the satisfaction is stopped, otherwise increase the width of the value. Now, let's see, if we're passing in a base-class rectangle, this works fine. 　　According to LSP, we replace the base class with its subclass, the result should be the same, but because the width and height of the square class are assigned at the same time, the method does not end, the condition is always unsatisfied, that is, after the subclass is replaced, the behavior of the program changes, it does not satisfy the LSP. So we refactor with the first scheme, we construct an abstract quadrilateral class, the behavior of rectangles and squares in the quadrilateral, so that the rectangles and squaresis its subclass, the problem is OK. For rectangles and squares, the width and height are the common behaviors, but the width and height are assigned a different behavior, so this abstract quadrilateral class has only a value method, no assignment method. The above example will only apply to different subclasses, and LSP will not be corrupted.

5. Dimitri (Law of Demeter)
Dimitri Law, if two classes do not have to communicate with each other directly, then these two classes should not have direct interaction. If one of the classes needs to call a method of another class, the call can be forwarded by a third party. The weaker the coupling between classes, the more useful it is for reuse, and a class that is weakly coupled is modified to not affect the class that is related. The main emphasis is on loose coupling between classes.

Remark: Do not talk to strangers, if the two countries fighting to avoid confrontation as far as possible, many envoys to negotiate scheduling.

6, synthesis/polymerization reuse principle (composition/aggregation principle], referred to as carp)
Synthetic polymerization reuse principle, use synthesis/aggregation as far as possible, do not use class inheritance as far as possible. Synthetic aggregation is the relation of "has a", while inheritance is the relation of "is a". Because inheritance is a strong coupling structure, the parent class is changed, and the subclass must change. So it is not "is a" relationship, we generally do not use inheritance. The use of the synthetic aggregation reuse principle will help to preserve the encapsulation of each class and reduce the level of inheritance.

Remark: Eugenics, do not blindly multiply.

Transferred from http://blog.csdn.net/jesse621/article/details/7216331