Summary of common design patterns

The favorite blog posts in the pile of paper are sorted and reproduced for memo.

--------------------------------------------------------------

Summary of common design patterns

It is said that there was a boy in Europe who was fond of mathematics, but he dropped out of poor middle school, but he had been learning by himself. Later, he felt that he suddenly found a major theory, I was excited with the perfection of this theory. One day, when I went to the bookstore to read a book, I found that the theory he found was calculus, and it had been around for more than a hundred years, you can imagine the boy's mood at the time, and finally he committed suicide.

As the number of software applications grows, it becomes more and more important to discover design patterns. Especially when you have racked your brains to create a perfect solution to solve a problem, you feel ecstatic, even beginning to indulge in your own ingenuity, but you suddenly see that your solution is one of the models that our predecessors have already concluded, will you become very upset! I have had this experience. Of course, the model here does not have the historical position of calculus and its contribution to social science. We cannot imitate the boy, but if we take the initiative to learn the design model, we can really take less detours.

Next I will make some simple summary based on my own learning and application.

I. Classic Books

Classic books on design patterns, the first book of course is the design patterns of the four-person gang, and some others, such as the design patterns and the C # design patterns. I personally feel that all the books on design patterns are hard to understand. Don't try to understand them all at once. Especially if you have never touched on design patterns, it is even more difficult if you have no development experience.

Ii. Several principles in coding design

1. OCP principle: open-closed Principle)

A software system should be open to extensions and closed to modifications

Advantage: The description of the principle is its advantage,

1) by extending existing software systems, new behaviors can be provided to meet new demands for software and make the software in change adaptive and flexible.

2) existing software modules, especially the most important abstraction layer modules, cannot be modified, which makes the software system in change somewhatStability and continuity.

The implementation principle is abstract.

2. LSP principle: liskov substitution
Principle)

Separating abstract excuses and Implementations

This is an inherited feature. subtypes must be able to replace their base types.

3. Dip rule: Dependency inversionPrinciples(Dependence
Inversion principle)

Principle Description: Abstraction should not depend on details; details should depend on abstraction; interface programming rather than implementation programming. Specifically, it depends on abstraction and not on specifics.

The implementation principle is to pass parameters or reference classes with high levels as much as possible in composite aggregation relationships.

4. ISP principle: interface segregation
Principle)

Principle: every interface should be a role. There are not many roles that should not be done, and everything should be done. This is similar to the minimum permission rule in the encoding principle.

5. Carp principle: Composite/Aggregate
Reuse Principle)

It is also called the CRP rule: compositereuse Principle)

Principle: Use synthesis/aggregation as much as possible, and do not use inheritance as much as possible. This is a question of sum.

6. Law of Demeter)

Also known as the LKP rule: leastknowledge Principle)

That is to say, an object should have as little knowledge as possible about other objects. Other statements: This is actually the requirement for designing high cohesion and low coupling. Some people call it "do not talk to strangers"

Iii. Classification of design patterns

The Gang of Four has two classification modes:PurposeIt can be divided into creation type, structure type, and behavior type.RangeCan be divided into class mode and object mode.

Creation Mode: Related to the creation of class objects.

Structured row Mode: Mainly deals with the combination of classes and objects.

Behavior mode: Describes how classes or objects interact and how responsibilities are assigned.

Class Mode: Mainly deals with the relationship between classes and sub-classes. These relationships are established through inheritance and are static. They are determined at the Compilation Time.

Object Mode: Mainly deals with the relationship between objects. The runtime is variable and more dynamic. Most of the modes are object modes.

CATEGORY common

Analysis on factory mode as class mode and abstract factory mode as object mode:

First, both are the creation mode. The main difference between the creation mode and the object mode is that the class mode uses the inheritance relationship to subclass the creation delay of the object, object Mode delays object creation to another object.

The purpose of the factory mode is to create an object. However, when creating this object, you need to create different objects in different environments, this environment is determined by the subclass of the factory class. Therefore, the Creation Method of the base class is an abstract method, and the subclass class instantiates this method, the subclass object and the base class of the created object are determined by the inheritance relationship. Therefore, the class mode should be used. Let's take a look at the process of creating the abstract factory model. First, the object you want to create may belong to multiple series, for example, it may be controls of different operating systems or game roles with different difficulty, etc, in this case, the factory required for the object you create is implemented by the subclass of the abstract factory (which is similar to the factory mode), but this subclass corresponds to different subclass objects according to different environments, this is determined by the runtime, so it should be the object-type creation mode. Of course, if only one product series is generated here, it will degrade to the factory mode and become the class mode, if the factory model requires the addition of factory subclasses, and these different subclasses create the same product (such as buttons and different styles), then the factory model will rise to the abstract factory model, it becomes the object mode. Therefore, my understanding is the difference between the creation class mode and the object mode. The key is to see if the factory class Object of the product is dynamically different.

4. My most common design patterns

Based on my experience, I will summarize the frequently used design patterns here. Based on my experience, they are sorted as follows: 1) single-piece mode, 2) abstract Factory mode and factory mode; 3) Adapter mode; 4) Decoration mode; 5) Observer mode; 6) Appearance mode; other modes are rarely used at present.

1. Single-piece Mode

This is the most widely used mode. Every formal software should use it. Global configuration, unique resources, and one is that all factories are designed as single-piece models, therefore, its usage is greater than the sum of the factory mode and the abstract factory mode.

2. Factory mode and abstract factory Mode

In order to avoid the emergence of a large number of new products in the program code, the software code I have written has basically used the factory in the past two or three years. Due to the impact of Wang yongwu Xia on taking small fish in the bear's paw, therefore, I often choose the factory mode and feel that the abstract factory mode is used only when there is a need for expansion. In fact, the factory mode is a special case of the abstract factory, and it is very easy to expand to the abstract factory.

See "one of the C ++ design patterns-factory models (simple factories, factories, and abstract factories)".

3. Adapter Mode

There are two types of adapters and object adapters in the adapter mode. The Object Adapter has more. The advantages of the Object Adapter have been discussed n times in many of the works of hero, I also use one of the many reasons. I switched from C ++ to C #. Since C # does not support multiple inheritance, I am not too lazy and have fewer interface definitions, therefore, you can only use the Object Adapter mode when using C # in most cases. In fact, there is a great similarity between the adapter and the decoration mode, which will be discussed in the following decoration mode.

4. decoration Mode

Also calledPainter ModeThe decoration mode is similar to the adapter mode, which is used to adjust the existing code to meet new requirements. In fact, one of the purposes of using the design mode is reuse. These two models are exactly the embodiment of reuse. When you use these two modes, you add new features to your existing software. Generally, if you want to add new functions to your software, you usually need to use the decoration mode. If you want to add function support for the software, you 'd better select the adapter mode. If you want to add operations for your class, you should use the decoration mode, if you want to introduce off-the-shelf code from other sources, you use the adapter mode.

5. Observer Mode

One more reason I use this mode is that it can implement the event function. Of course, the event can be directly used in C, however, in C ++, the model can be used to give full play to its full potential. An online question (the cat shouted, and the host woke up and ran away ), it is the best application to use this mode.

6. Appearance Mode

Development is to reuse where it can be reused to save resources and improve efficiency. The appearance mode is also a solution that provides reuse of other ready-made code. You need to implement a function, this function may be available in the ready-made code, but the ready-made code may be much more than what you need. In this case, You encapsulate these functions and re-provide the interface you need, this is the essence of this model.

 

Refer:

Big talk Design Model

In-depth introduction to design patterns

Agile Software development principles, models and practices

Design Pattern-Basis for reusable Object-Oriented Software

Design Patterns-Analysis of 23 gof design patterns with C ++ source code

Object-Oriented Design Model (C ++)-tiger consultation Studio

 

Java and Mode

C # design mode mini speed query manual