Discussion on software development from design principles (IV)

The last time I talked about LSP (Li's replacement principle), I was a little anxious. A lot of things have not been written. This time, I will first add it.

This is actually an example. This is an example in Java and patterns. It indicates whether a square can inherit from a rectangle. I believe that almost anyone who has been in elementary school will not think about it without thinking (including me). Square is a special rectangle, and of course it can be inherited. But the opposite is true. The reason is as follows: there should be such a method in the rectangle, which is to change the length and width of the rectangle. In this case, assume that one method is void change (double length, double width ), however, this method should be void change (double side) in the square. That is to say, at this time, the rectangle as the parent class of the square cannot replace the subclass, so it does not conform to the LSP. In fact, I think this reason is too far-fetched. In this case, I also changed the convenience in the square to void change (double side, double side. However, through this example, we should realize that the LSP will produce different results under different circumstances. Or is the Penguin the last time it was reported a bird. If the bird class has a fly () method, the penguin is not a bird, but if the bird class does not need the fly () behavior of the bird, but it only requires methods like eat (), so it is impossible for penguins to inherit birds.

In short, the purpose of the design pattern is to be scalable and maintained. Therefore, encapsulation change encapsulation is actually a change point. In different systems, the change points must be different. For example, in the student management system, one school has four student numbers. As the school grows, the four digits are definitely not enough, so the number of digits of this student ID is likely to become a change point. However, if the student ID of a school is 24, we don't need to take this as a change point.

Next, let's talk about Dip (dependency inversion principle). The content of DIP should depend on interfaces rather than programming. This is the most typical phenomenon in the design pattern. Almost every design pattern typically meets this principle. Here, let's take a look at the most typical facade (appearance mode ).

The intent of the appearance mode is to provide a unified interface for a subsystem or sub-module, and then let the high-level module call this interface without knowing the implementation details in the subsystem.

The structure is as follows :( reference from http://terrylee.cnblogs.com/archive/2006/03/17/352349.html ):

There are many design patterns in the gardenArticleIf you have any questions about these articles, let's take a look at these articles. Let me talk about his application.

If you have worked as an intern, you must have had this experience. Many interns have no experience, and programming products are poor. When you allocate a module to him, he makes a mess. I wrote a lot of classes, a lot of methods, no annotations, and no naming rules. And then give it to you. At this time, you need to analyze his class and his method a little bit. The final result is longer than writing a module by yourself. So you can use this method. Specify Several Interfaces for him, then let him implement these interfaces, and then encapsulate the classes it writes to oneProgramIn this way, you do not need to know the internal implementation details, just reference his DLL, and then call its external interface.

In fact, this model has applications in many places. If you have software development experience, you are most familiar with three-tier architecture or N-tier architecture, isn't the interaction between each layer actually completed through an interface! This is a typical application of the appearance model.

To sum up my understanding of the appearance mode:

1. provides a unified interface for sub-modules or subsystems to facilitate calls by other modules.

2. added the system independence of sub-modules to facilitate calls of other classes. For example, clienta, clientb, and clientc.

3. Easy to modify. All I need is your external interface. If your interface is not changed, I don't need to worry about your internal implementation logic. Each person maintains his/her own module and does not interfere with each other during upgrade.

Back to the topic, dip, or an example of a three-tier architecture. Dip also has a saying that the top layer depends on the bottom layer, and the bottom layer cannot depend on the top module in turn. Either way, let's explain it. Or the classic three-tier architecture. The data access layer is nothing more than the underlying module of the entire system. This module provides a series of interfaces for its previous business logic layer to call, the business logic layer only needs to know the external interface of the data access layer, and the data access layer does not know the existence of the business logic layer. The business logic layer has the same relationship with the user interface layer. This is actually the system independence of the module.

After writing this series today, the last design principle is ISP (interface Independence Principle). The purpose of this principle is that if you do not need a function, do not force the user to implement this function.

In fact, I think this is similar to the SRP method, that is, segmentation. In SRP, we separate a class so that a class has only one reason for its change. In ISP, we separate an interface, so that he will not be forced by a user, which is also the art of the separation interface I mentioned earlier. There are too many methods in the interface, and the method must be forcibly implemented in this interface. If there are too few methods in the interface, many broken interfaces will be generated, affecting the program running efficiency. Interfaces are essentially a class, so I really don't think there is any difference between ISP and SRP. So here we will not repeat some nonsense.

This series is over. Let me make a summary. First of all, I should declare that I am only a student and have no big project experience. Therefore, many of them are just emotional discussions. If you have any ideas, I hope you can give me more advice.

In fact, when I first looked at the design pattern, I felt very esoteric. I couldn't carry the 23 patterns, and then I began to read them over and over again, forcing myself to apply them when doing things. When I saw the fifth and sixth times, I began to find that almost all the design patterns were similar, so I began to look at the design principles in turn. Then we found that, in fact, different models are only application design patterns. We can use different encapsulation modes to encapsulate different change points. Then I began to read the design principles repeatedly, understand the design principles a little bit, and then start to look at the design pattern, and I felt much easier. The design pattern can also be easily applied in the software.

This series is over. Thank you for your attention. Whether it's unintentional or click to watch. Seeing the increase in browser views is the greatest motivation for my learning and writing. As I wrote on my homepage, I want to learn software so that I can make a contribution to it in China. I will work harder and hope that I can improve my skills like those MVPs and truly contribute my own strength to it in China.

References:

Terrylee: http://www.cnblogs.com/Terrylee/archive/2006/07/17/334911.html

Big talk Design Model

All you need to know. net

Head first design model