A remark on the six principles of design pattern

Principle, so the name Incredibles is the essential meaning. The so-called catch thief first to seize the king, research design patterns naturally need to understand the design principles, all the models are on the basis of these principles developed, some focus on one, there are many are involved. After reading the design pattern, I felt that each model had these principles of shadow, but also permeated the three main object-oriented properties, but also feel that these principles have similarities, it is with them to make us from code workers to artists. I would like to review the six principles, I hope you shoot bricks:

1. Single Duty principle (Responsibility Principle, abbreviation SRP)
Single principle of responsibility, in the case of a class, there should be only one cause for it to change. If a class takes on too much responsibility, it is tantamount to coupling these responsibilities, and a change in one's responsibilities may weaken or have been able to perform other duties in this category. This coupling leads to fragile designs that can be subjected to unexpected damage when the changes occur. And much of what software is designed to do is find responsibility and separate it from each other.

Remark: Cohesion the excellent embodiment of low-coupling, do not pull the relationship, and good.

2. Open-closed principle (the open-closed Principle, OCP)
The open-and-close principle is that software entities (classes, modules, functions, and so on) should be extensible, but cannot be modified. That is, for the extension to be open, the change is closed. We can not do foresight, in the design when possible to make a class good enough, the design is not to modify the situation, not completely closed, when the change, we create an abstraction to isolate the subsequent changes of the same kind.

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

Http://hovertree.com/h/bjaf/7cuf5s2n.htm

3. Dependence reversal principle (dependence inversion Principle)
Dependency reversal principle, refers to the high-level module should not rely on the lower layer module, two should rely on abstraction; abstraction should not rely on detail, and detail should depend on abstraction. To be blunt is to program for the interface, not to implement programming. For example: In the computer hardware, if the memory is broken, then only need to change a memory bar can be, 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, whether it is the root.

Remark: When building to do designers, rather than bricks and mortar, the abstract blueprint to rely on specific materials to achieve a little.

4. The principle of substitution on the Richter scale (Liskov Substitution Principle, hereinafter referred to as LSP)
On the Richter substitution principle, subtypes must be able to replace their parent type. In the software, the parent class is replaced with its subclasses, and the behavior of the program is not changed. It is because of the substitution of subtypes that a module using the parent type can be extended without modification.

Remark: The elder gave you the right to inherit must do maintenance obligations, the responsibilities of the elders to bear up.

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

Remark: Do not talk to strangers, if the two countries should try to avoid a confrontation between the confrontation, multi-messenger to negotiate the dispatch.

6. Synthesis/Aggregation multiplexing principle (composition/aggregation Principle], abbreviation carp)
Synthetic aggregation multiplexing principle, use composition/aggregation as much as possible, and do not use class inheritance as much as possible. The synthetic aggregation is the "has a" relationship, and the inheritance is the "is a" relationship. Since inheritance is a strongly coupled structure, the parent class changes and the subclass changes. So not "is a" relationship, we generally do not use inheritance. Preferential use of the synthetic aggregation multiplexing principle helps to preserve the encapsulation of each class and lower the hierarchy of inheritance.
Remark: Prenatal and postnatal, do not reproduce blindly.

Recommendation: http://www.cnblogs.com/roucheng/p/sheji.html

A remark on the six principles of design pattern