The six principles of the design pattern and software design of the primary knowledge

Summary: This text is divided into two parts. The first part: basic knowledge of design pattern; Part Two: The six principles in software design, and analyzes the principle of single responsibility in detail. (the timeline reference for this article: \java design mode (time series diagram) for Notes Support folder. VSDX)

Part One: initial knowledge of design patterns

What is design mode? When James gets this argument, it's confusing!

Mode? Isn't it a mold? Pattern Recognition-A classic problem in the computer field?

Design simulation? The design pattern of the software? Don't understand!!!

But in the actual coding, debugging process, James has encountered a very difficult problem: there is too much redundant code in the engineering code-code reusability is not high, once the requirements change, need to change the code logic in many places-code flexibility is not strong ...

Let's look at the concept of design mode first!

Design patterns are a set of experiences that are repeatedly used, known to most people, categorized, and code-designed. The design idea used to write reusable code that makes the code easier for others to understand and to ensure code reliability.

Design patterns allow code to be truly engineered.

The design pattern is the crystallization of the wisdom accumulated in the software industry; it presents a series of standard terms that summarize all the concepts and methodologies applied by experienced practitioners in the relevant industry.

The 23 common design patterns are as follows:

1. single case mode;

2. Factory method mode;

3. Abstract Factory mode;

4. Template method mode;

5. Builder model;

6. Proxy mode;

7. prototype mode;

8. Intermediary mode;

9. Command mode;

10. Responsibility chain mode;

11. Decoration mode;

12. Strategy mode;

13. Adapter mode;

14. Iterator mode;

15. Combination mode;

16. Observer mode;

17. Façade mode;

18. Memo mode;

19. Visitor mode;

20. State mode;

21. Interpreter mode;

22. Enjoy meta mode;

23. Bridge mode;

The origin of design pattern is object-oriented programming thought, is the essence of object-oriented design-abstract , object-oriented through classes and objects to achieve abstraction, the implementation of the object-oriented three important mechanisms: encapsulation, inheritance and polymorphism. and these three kinds of mechanisms derive a variety of design patterns.

In the use of object-oriented ideas for software design, the following principles need to be followed:

1. Principle of single responsibility;

2. The principle of the Richter replacement;

3. Dependency inversion principle;

4. Interface isolation principle;

5. Principles of Dimitri Law;

6. Opening and closing principle;

These 23 design patterns can be organized into five categories according to the design intent: interface mode, responsibility mode, stereotype mode, operation mode and extended mode . The design intent of the model indicates the value of applying a pattern . But some of the 23 design patterns mentioned above do not only support a design intent.

In the software design process, as long as we try to follow the above design principles, the design of the software must be excellent, and strong enough, stable, and have enough flexibility to meet the changes in demand.

That James still doesn't know why, for example: What are the implications of these principles? Why did they appear and what engineering problems were solved? What are the links between these principles and the 23 design patterns described earlier? How to use in our engineering code ...

These questions need to be dealt with by James one by one, but James believes he will be able to overcome these difficulties. (Even if it is living a handshake building, eating instant noodles, crowding the bus, as long as you can survive, there is hope!) What other people can do, why not themselves? To have the confidence to win! ）

Part Two: Starting from the principle of design--single duty principle

Single Responsibility principle: there should be and only one cause for class changes.

Why is there a class here? Is it just for the design of the class?

(Why is this design principle possible?) When 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 the ability of this class to perform other duties. The problem is the coupling!

The real job of software design is to discover responsibilities and separate those responsibilities from each other. A single responsibility reduces the complexity of the class and its implementation is clearly and clearly defined.

That's the problem, James. What does "class change" mean?

(How to practice a single responsibility principle?) Considering how to use code to implement a single responsibility principle (the code is the idea), fortunately there are Baidu and Google. Here's how to use the example on the website, James says: It's easier to explain the problem with this example.

Demand analysis: Cooking, make a fish fragrant eggplant.

 Public Interface Cooking {    //  get the dish name     String getcookingname ()    ; void setcookingname (String cookingname);         // Preparation before cooking: picking dishes, washing vegetables and so on, preparing the appropriate ingredients    void Doprepare (String vegetablename);         // cooking mode: steamed, boiled, fried, fried, etc., and provide the name    of the dish void Dofire (String cookingname, String mode);}

If James wants to cook a fish-fragrant eggplant, the above four methods can be covered, from the name of the dish, the preparation of the ingredients to the specific cooking operation. From the information and behavior point of view, the first two methods are fish fragrant eggplant related information, the latter two are related behavior (cooking specific behavior).

What if you consider the following as a more complete approach?

 Public Interface icookinginfo {    //  get the dish name     String getcookingname ()    ; void setcookingname (String cookingname);}

 Public Interface Icookingfire {    //  preparation before cooking: picking, washing and so on, preparing the corresponding ingredient    void  Doprepare ( Icookinginfo info);     // cooking mode: steamed, boiled, fried, fried, etc., and provide the name    of the dish void Dofire (icookinginfo info, String mode);}

The cooking class consists of two parts , one part of which is the responsibility to get the name of the dish and the relevant information (taste, features ...). ), the other part of the role is specific cooking (of course, need information about the name of the dish).

If icookinginfo changes, it is bound to cause icookingfire changes. Splitting is required for two parts with different responsibilities. In the cooking class, you only need to implement the above two different interfaces, you can realize the function of cooking one dish.

 Public classCookingImplementsIcookinginfo, Icookingfire {@Override PublicString Getcookingname () {return NULL; } @Override Public voidsetcookingname (String cookingname) {} @Override Public voidDoprepare (icookinginfo info) {} @Override Public voidDofire (icookinginfo info, String mode) {}}

After the cooking object is generated, it can be treated as a icookinginfo or Icookingfire interface, and if a menu name or other information needs to be set, it can be used as a Icookinginfo implementation class; As an implementation class for Icookingfire. (It suddenly begs the question: James doesn't seem to understand the relationship between the class and the interface it implements ...) )

In short, in the interface design, if the interface can be subdivided into different "responsibilities", the interface can be further subdivided.

The above is only interpreted from the interface point of view: the single principle of responsibility, in addition to the design of the class, the definition of methods. It boils down to a point: do your own thing yourself, and assume the responsibility accordingly.

Refer to the example analysis:

1. http://blog.csdn.net/zhengzhb/article/details/7278174 from a class perspective;

2. To be Continued ...

Advantages of a single responsibility principle:

1. The complexity of classes is reduced and what responsibilities are defined clearly and clearly;

2. Improved readability;

3. Improved maintainability;

4. Reduced risk of change; if the single function of the interface is done well, an interface modification will only affect the corresponding implementation class, and it has no effect on other interfaces, and it can greatly help the expansibility and maintainability of the system.

The single responsibility principle presents a standard for programming, with "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 from project to environment.

What can be used in a single responsibility principle? The single responsibility principle applies to interfaces, classes, and also to methods (one way to do as many things as possible). Interface must be a single responsibility, the design of the class as far as possible only one cause of change.

But everything has a need to weigh the pros and cons of the place, not because mechanically single responsibility principle, and let the system become cumbersome and huge.

The six principles of the design pattern and software design of the primary knowledge