Six Principles of design pattern

1. What is design mode?

Design pattern is not a tool, it is the philosophy of software development, it can guide you how to deal with a good architecture, write a robust code, solve a complex demand;

I. Single principle of responsibility

2. Definition:

"There should neverbe more than one reason for a class-to-change."

--there should be and only one cause for class changes.

A responsibility map an interface, multiple interfaces constitute an implementation class, complete a complete functional process;

3. The principle of single responsibility puts forward a standard for writing a program, which uses "responsibility" or "reason for change" to measure whether an interface or class is well designed, but "responsibility" and "reason for change" are not measurable, and vary according to the project, depending on the environment;

4. for the interface, the design is to achieve a single, but for the implementation of the class, it is necessary to consider a single principle of responsibility, but also consider the complexity of the system, forcing a class to split into two classes, and then using aggregation or combination of the way coupled together is undesirable, will increase the complexity of the system;

5. The principle of single responsibility applies to classes, interfaces and methods, and the methods and interfaces must be single, and the design of the class should be as single as possible;

Second, the principle of the Richter replacement

6. Definition:

"Functions that usepointers or references to base classes must is able to use objects of derivedclasses without knowing it . ”

--all references to the base class must be able to use the object of its subclass transparently;

As long as the parent class can appear, subclasses can appear, and the substitution of subclasses will not produce any errors or exceptions, the user does not need to know whether the parent class or subclass, in turn, the subclass of the occurrence of the local parent may not be suitable;

7. if the subclass does not implement the method of the parent class completely, or if some methods of the parent class have already "deformed" in the subclass, it is suggested to break the parent-child inheritance relationship and replace the inheritance with dependency, aggregation, composition and other relationships.

8. subclasses override (override) or overload (overload) parent class methods; When overridden, requires the same type range; overloading requires that the subclass type range should be wider than the parent class type range, that is, subclasses should enlarge the parent class's precondition;

9. Preconditions and post conditions: The former is what you want me to do, and I have to satisfy my condition; the latter is what I need feedback and what the standard is.

Iii. the principle of dependency inversion

Ten , definition:

"modulesshould not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend uponabstractions ";

High-level modules should not rely on the underlying modules, both should be dependent on their abstraction. Abstractions should not be dependent on detail, and detail should be dependent on abstraction.

--(materialized) dependencies between modules occur through abstractions, which do not have a direct dependency between classes, and their dependencies are generated through interfaces or abstractions. An interface or an abstraction is not dependent on an implementation class, whereas an implementation class relies on an interface or abstract class;

--(Essence) through abstraction (interface or abstract class) to make each implementation class or module implementation independent of each other, do not affect each other, to achieve the implementation of class or module loose coupling;

--using the relationship between the abstract to replace the real connection between things in people's mind, namely "interface-oriented or abstract programming";

The underlying module: refers to an indivisible atomic logic, and every logical realization is made up of many atomic logics;

High-level module: refers to the product of the re-assembly of atomic logic;

Abstract: Refers to an interface or abstract class, followed by the next year can not be instantiated;

Detail: Refers to the class that implements the class, implements the interface or inherits the abstract class, it can be instantiated;

One , a method of proving a theorem: Shun-push proof and counter-proof;

A , its advantages: reduce the coupling between the implementation classes, improve the stability of the system, reduce the risk caused by concurrent development, improve the readability and maintainability of the code;

- , five-point rule:

(1) Each class has as much as possible an interface or abstract class, or both;

(2) The surface type of the variable is as far as the interface or abstract class;

(3) How the class should not derive from a specific class;

(4) Try not to overwrite the method of the base class;

(5) The use of the Richter replacement principle;

Popular rules: Interfaces define public properties and methods, and declare dependencies on other variables; the abstract class is responsible for the implementation of the common construction part, the realization class realizes the business logic accurately, and the parent class is refined at the appropriate time;

Iv. Principle of interface Isolation

- , definition:

"The dependency of one class to another one should depend on Thesmallest possible interface."

--The dependencies between classes should be based on the smallest interfaces;

--the interface is as small as possible, and the interface tends to specialize;

the , there are two types of interfaces: instance interface (class is an interface) and class interface (interface)

- , the principle of interface isolation is to standardize the interface:

(1) The interface as small as possible, but "small" is limited, first of all can not violate the principle of single responsibility;

(2) The interface to high cohesion, that is, to improve the interface, class, module processing capacity, reduce external interaction;

(3) customized services, for different objects, as far as possible to design a dedicated service interface;

V. Dimitri Law (also known as: least knowledge principle)

- , definition:

"Your Immediate Friends"

-communicate only with direct friends, i.e. reduce coupling, improve robustness, decoupling and weak coupling;

--An object should have a minimal understanding of other objects, that a class should know the least of the classes it needs to multiply or call, as long as it knows how many public methods it provides;

- , the relationship between the fishes is based on the inter-class, not in the method, and a method tries not to refer to a method that does not exist in a class;

+ , Dimitri Law requires class "shy" point, try not to publish too many public methods and static variables, as far as possible, the use of private, package-private, protected and other access rights;

- , the question of where a method is placed: If a method is placed in this class, it does not increase the relationship between the classes and does not have a negative impact on the class, it is placed in this class;

Vi. principle of opening and closing

+ , definition:

"Software entities like classes, Modulesand functions should is open for extension but closed for modifications."

--a software entity such as classes, modules, and functions should be open to extensions and closed for modification;

--a software entity should be extended to achieve change, rather than modifying existing code to achieve change; it is a principle that constrains the existing open design for future events of the software entity;

A , the basic path of a project: Develop, reconstruct (modify the original design and code), test, put into production, operation and maintenance (minimize the modification of the original code, maintain the purity of the historical code, improve the stability of the system);

at , three types of change:

(1) Logical change

(2) Sub-module changes

(3) Visible view changes

This article is from the "book Notes" blog, please be sure to keep this source http://xiexiao.blog.51cto.com/10173801/1641122

Six Principles of design pattern