Discussion on software development from design principles (1)

I have been studying some design patterns for a few days. As a beginner, I think many people may feel this way, that is, many design patterns seem similar. That's because we don't have much project experience, so we can't imagine where to apply the design pattern.

I have seen many people on the internet that they do not want to learn design patterns, especially students. In fact, I do not agree with this statement, because I have always believed that the theory and practice should make common progress. Maybe my opinion is not very authoritative. But one thing is certain. We do not understand the design mode, but we must be familiar with the design principles. With this idea, I Want To systematically introduce several design principles of the design pattern from the perspective of beginners.

First, we need to first understand why we need to apply the design pattern. There is a saying that you will never be able to understand without learning the design model, or even simply cannot understand what is object-oriented and why it is object-oriented. I would like to use this sentence to sum up the advantages of object-oriented. The fundamental purpose of design patterns (or object-oriented) is to reuse and respond to changes. Here, the examples of movable character printing in the big talk Design Pattern explain the advantages of object-oriented very classic. Let me give a rough summary of this example:

Cao makes a poem: drinking and singing, and life is really good. As a result, the recorder carved the words for one night and recorded the eight words. The next day, Cao changed his attention and changed his poems to singing to wine. His life was so nice. As a result, the record recorder had to destroy all these eight words, and then re-engraved the eight words... at last, Cao repeatedly changed the words to "Wine" and "life. During this period, the record recorder can only destroy it constantly, and redo it... the labor consumption is huge. We can imagine it. However, we imagine that the record recorder can engrave every word. Even if it is modified, the record recorder only needs to combine a few new words with the original words (to cope with changes ), in addition, replace words can be applied (reusable) in the future ).

This is an example in reality. Let's look at it again.Program. I believe that every programmer should have heard of such a concept as component. Every company has its component library. A company that wants to develop must have a huge and robust component library. The most common example is the data access component. We writeCodeWhen developing a website, we can find that many of the code we write is repetitive code. To put it bluntly, we are constantly dealing with databases, adds, deletes, modifies, and queries. As a result, many companies have extracted this part and made it a special data access component. Then programmers only need to access this data access component, in general, it is to input an SQL statement or a storage structure name to the method of the data access component, and then to the nearest possible input of a LINQ statement, and then the data access component interacts with the database, this saves a lot of manpower and material resources. In fact, this is what we usually call layering. The purpose of this component is simply to reuse and respond to changes in the future. Therefore, all design patterns and design principles should be carried out in response to these two points.

Therefore, there are two extremes in the application design model. The first is that there will be no design patterns. There are a lot of people here. I just don't know how to use the design pattern. To build a project is to accumulate code. To use Asp.net for example, all the code is written. aspx. in CS, this kind of defect is very difficult to modify, and the code written by him has very poor reusability. The second approach is to apply the design pattern excessively. Maybe everyone thinks that the more applications the design pattern has, isn't such a project the better? In fact, this is not the case. I just mentioned that the purpose of the design is to reuse and respond to changes. If the part you design does not change at all, and there is no reusability at all, this design will not only make the entire project huge, but also affect the efficiency of the program.

This is also the reason why some opinions on the Internet say that students are not suitable for learning the design model. As a student, there is no practical project experience in the enterprise and it is impossible to find out the change points and reuse points, therefore, it is easy to cause excessive design or the appropriate mode is not used in the design. However, design principles should be observed wherever they are.

For time reasons, we will only introduce the first one in the design principles: single responsibility principle (SRP ).

The approximate meaning is displayed from the name. That is to say, each class has only one responsibility. Here, we need to understand it as the cause of the change. The combination of these two statements is the gof statement: each class should have only one reason for his change.

We still analyze the objective of a single responsibility principle from two object-oriented perspectives. The first is reuse. We should be able to think that the more functions a class has, the worse the reusability of this class. For example, a machine that makes a cake, for example, if we put the dough, shape, heat, and cooling in the same machine, then this machine can only make one kind of cake. However, if we divide these functions into different machines, some machines and faces, and some machine stereotypes, we can think of them. For example, a new cake can be made when the surface is first joined, heated, finalized, and cooled. You can even make a variety of things that are not cakes. Then we want to cope with the changes. We want to add the function of adding eggs to this new machine. If it is a machine with complete functions, we can only remove the machine and reconstruct it. The cost can be imagined. If the functions are separated, I will not say more .....

The same is true for software. Some may question my response to changes. The cake machine can only be removed and redone, but only some code is required for a class! Let's leave this question for a moment. The next time we talk about OCP, we will understand it.

From SRP, I will simply extend a design pattern. In fact, the design mode is to use various models to achieve the purpose of design principles. I want to talk about the iterator mode.

Regarding iteration, I believe that everyone who has learned advanced languages will not be unfamiliar, whether it is Java or. NET. In Java, for (:) and foreach (in) in. NET are both an encapsulation embodiment of the iterator mode.

Today, I just want to give a brief explanation. I will give it a closer look and cite the explanation of gof. The iterator mode provides a way to access each element of an aggregate object sequentially without exposing the internal representation of the object.

Let's take a look at the structure of the iterator mode:

 

 

I will not talk about the specific English explanation here. I will briefly explain the functions of the two interfaces:

1.IlistIs a collection class interface. I only wrote one method in it, that is, to obtainIterator.

2.IiteratorIt defines some necessary methods of the iterator.

 

Here, the separation of iterator and list is a reflection of a single responsibility principle. List is just a container. What operations should be performed on this container should not belong to the content under the jurisdiction of this class. Therefore, we split this function into a new iterator class to complete the iteration. For example, we now use this list class for sequential iteration. But one day, I suddenly wanted to iterate the list in reverse order, so we only need to add a class of reverse iterator. This is easy to change with a single responsibility principle. In addition, for example, I have already written a class for sequential iteration. Tomorrow, I will write a container class for arraylist, which also requires sequential iteration, then we can completely repeat the class of the application sequence iterator, which is the reusability of the single responsibility principle.

Speaking of this, coming to an end, let's take a look at the interfaces I have previously written. The interface design must follow the single responsibility principle. As I said before, the interface cannot be too large or too small. Let's use this sentence to summarize the single responsibility principle. A single responsibility is not to say that we share our responsibilities as detailed as possible. Instead, we should keep in mind the purpose of our application design model. Specifically, the purpose of classification cannot be classification for classification. The classification of classes is encapsulation, and the foundation of classification is abstraction. The responsibilities here refer to not just a few functions, but several reasons that can lead to class changes.

Well, I will write this article today. I hope you can give me more advice. Thank you.