The principles of design patterns are drawn to understand

"See" http://www.cnblogs.com/jiangzhengjun/p/4260969.html

Single responsibility principle (SRP)--the definition of cohesion

The definition of a single responsibility principle: For a class page, there should be only one reason for it to vary (there should never be more than one reason for a class to change).

A single responsibility principle requires that an interface or class have only one cause to change, that is, an interface or class has only one responsibility, and it is responsible for something.

Cohesion: The functional correlation between the constituent elements of a module.

　　a single function of the class: attribute and behavior of a class separation. The attribute referred to here refers to the set/get associated with the attribute. This breaks it down into business objects (BO) and business logic (BL).

　　A single function of a method: A class may have several functions, but it is not necessarily necessary to put all the functions in the same class, to be placed in different interfaces, to implement interface separation, and to combine them again when needed. "Go". So in the use of the time, will all the functions of the classification, see the application changes to those features will have an impact, those not.

Open-closed "principle ( OCP)-- abstract response to all changes

open-closed Principle : software entities should is open for extension, but Closed for modification. (a software entity should be open to extensions and closed for modifications.) )

The modules designed according to the opening and shutting principle have two main characteristics. They are:

1, "is open to expansion." This means that the behavior of the module can be extended, and when the requirements of the application change, we can extend the module to a new behavior that satisfies those changes. In other words, we can change the energy of the module.

2, "For the change is closed." When you extend the behavior of a module, you do not have to change the source code or the binaries of the schema. Binary executable version of the module, whether it is a linked library, DLL, or Java. Jar files, no changes are required.

Open/Closed principle improves maintainability of the system (scalability - increase, flexibility / modifiable - repair, pluggable - testability) and reusability.

The Richter substitution principle (LSP)

From the "open-closed" principle, it can be seen that the key to object-oriented design is abstraction, which requires the use of inheritance, from abstraction to materialization, and whether the inheritance relationship needs to be validated by using the Richter substitution principle (Liskov substation principle).

Defined

Subclasses can appear where all base classes (which refer to interfaces and abstract classes, as well as concrete classes) appear.

Strict expression is: if for each type of T1 object O1, there is a type of T2 object O2, so that all the program in T1 defined p in all objects O1 replaced by 02 o'clock, the behavior of the program P does not change, then type T2 is a subtype of type T1. In other words, if a software entity is using a base class, then it must apply to subclasses, and it simply cannot detect the difference between a base class object and a subclass object.

Just like a rectangle cannot be a parent of a square:

Otherwise

Public   class Smarttest {//test

Public   void Resize (Rectangle R ) {

while ( R. getheight () <= R . GetWidth ()) {//square will be problematic

R. SetWidth ( R . GetWidth () + 1);

}

}

It's going to go wrong.

Dependency reversal principle (DIP) definition

Dependency Inversion principle:

1, high-level modules should not rely on the underlying modules, both should be dependent on the abstraction layer.

2. Abstractions (interfaces or abstract classes) should not be dependent on details (implementations).

3. (Implementation) Details should be dependent on abstractions (interfaces or abstract classes).

"The most streamlined definition is: programming for interfaces, not programming for implementations." 】

Use interfaces and abstract classes for variable type declarations, parameter type declarations, method return type declarations, and data type conversions;

Not to implement programming means that you should not use specific classes for variable type declarations, parameter type declarations, method return type declarations, and data type conversions.

To ensure this, a concrete class should implement only the methods declared in the interface and the abstract class, and should not give redundant methods.

What is "upside down"?

What is "inverted", to understand it, let's look at the right place. Relying on the positive is the dependency between classes is a real implementation of the dependency between classes, that is, to implement programming, which is the normal way of thinking , I want to drive Mercedes-Benz rely on Mercedes, to use the Apple notebook to use the Apple notebook. and the program needs to be the real world of things to abstract, the abstract result is an abstract class and interface, such as BMW and Mercedes-Benz abstract into a car, Apple notebooks and IBM notebooks abstracted into notebooks, and then our program relies on these abstractions, which replace the traditional thinking of the specific things between the dependence, " The reverse "is generated from here."

In other words, both the high-level module and the underlying module have no direct dependencies, but both are dependent on the interface or abstract class.

For example, a driver who drives a car is not dependent on a particular brand of car, but instead relies on the type of automobile (abstract)

Combination/Aggregation multiplexing principle (CARP)

The combination/aggregation multiplexing principle (composition/aggregation reuse Principle) is often called the synthetic multiplexing principle (composition reuse Principle or CRP). In a new object, an existing object is used to make it part of the new object, and the new object is reused for the purpose of the existing function by delegating to those objects.

Another short statement of the principle: use combination/aggregation as much as possible, and do not use inheritance.

Combination/Aggregation Differences

Aggregation represents a weak "owning" relationship, which shows that a object can contain a B object, but the B object is not part of a object;

Synthesis is a strong "own" relationship, reflecting the strict relationship between the part and the whole, part and the whole life cycle, the general one synthesis of the multiplicity can not exceed 1, in other words, a synthetic relationship of the composition of the object can not be shared with another synthetic relationship. A constituent object can belong to only one synthetic relationship at a time.

The difference between combination/aggregation multiplexing and inheritance multiplexing

There are two ways to reuse: combination/aggregation multiplexing or inheritance multiplexing.

The combination/aggregation multiplexing method can be changed dynamically during the operating period, and has good flexibility.

Inheritance occurs at compile time, so it cannot be changed at runtime and is not flexible enough.

Because the subclass inherits all the non-private things of the parent class (like loving her to accept everything), if the inherited implementation is not suitable for solving the new problem, the subclass must be rewritten so that the reuse is eventually restricted.

Inheritance destroys the encapsulation attribute because inheritance exposes the implementation details of the superclass to subclasses.

If the implementation of the superclass changes, then the implementation of the subclass will change as well.

Difference from the principle of the Richter substitution

"Is-a" is a strict taxonomic definition, meaning that a class is a "kind" of another class. and "Has-a" is different, it means that a role has a certain responsibility.

The principle of substitution of the Richter scale expresses the relation of "is-a", while the combination/aggregation multiplexing expresses "has-a".

Dimitri Law (LOD)

The Dimitri rule (law of Demeter) is also called the least knowledge principle (Least knowledge principle,lkp), which means that an object should have a minimal understanding of the object's other objects.

A variety of different expressions:

1, only communicate with direct friends.

2. Don't talk to "strangers".

3, each software unit to other units have only the least knowledge, and limited to those with the unit is closely related to the software units.

4. My knowledge (Implementation details) the less you know, the better.

The Dimitri rule of the narrow sense

The narrow Dimitri requires an object to interact only with its friends.

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, it can be converted by a third party.

Definition of a friend class

1. The current object itself (this)

2. Class in input and output parameters of the method

3. Direct reference object of member variable

4. Element classes in a collection member

5. Objects created by the current object

Interface isolation principle (ISP)

The principle of interface isolation is that it is better to use multiple specialized interfaces than to use a single overall interface. In other words, from a customer class perspective, a class's dependency on another class should be built on the smallest interface.

Defined

Interface Segregation principle: The client should be provided with a single interface as small as possible, rather than providing a large total interface, that is, providing a single interface of responsibility.

1. Clients should not be forced to rely on interfaces they do not need.

2, the dependencies between classes should be based on the smallest interface.

The 1th is that the client needs what interface we provide what interface, to eliminate the need for the interface, it needs to refine the interface, to ensure its purity. The 2nd, in fact, is the same as the main thrust of the 1th expression, but two different descriptions of a thing.

Different from the principle of single responsibility

The above two points can be summed up as a sentence: the establishment of a dedicated interface, do not build a bloated interface, or further: interface as far as possible, the interface in the method as little as possible. Is this not the same as the single principle of responsibility? Wrong, the interface isolation principle and the single responsibility principle examines the angle is not identical, the single duty request is the class and the interface responsibility single, namely the function is single, the attention is "the function", it is from the function division, but the interface separation principle is from "the service" angle, it Requests is "the service" the specificity, is broken down from the perspective of service.

Interface separation refers to thinning a bloated interface, rather than creating a useless interface or arbitrarily establishing an interface.

Principles of design patterns draw to understand