Preliminary understanding of the design model

Recently I have been thinking about the design model. Here I am talking about the object-oriented model. I have looked at some materials and just bought the classic one yesterday: design Pattern-the basis for reusable object-oriented software. I just learned a lot from the introduction. Here I will record some of what I can understand, which is my own review, I also hope to provide you with some help. I hope you can exchange and learn more. I am very grateful to you! Which of the following are meaningful to you. Today is just a simple opening. Go!

The basis for reusable object-oriented software design !! From the question, we can see that it is about software design and is involved in the field of object-oriented software design. One of the purposes of the design is to ensure the reusability of software methods, of course, what we talk about here is only the basis of software design, focusing on thinking and cultivating software design ideas.

Talking about design patterns may have become an old topic, thinking about how to solve the implementation problem of a software system and writing reusable and scalable modules all day long, without these special characteristics of software, especially considering software variability from the perspective of time, this determines that the software must face and solve an unavoidable problem, without these special characteristics, it may not be so important (design patterns), and the application design patterns also have a certain price. For example, more classes will be designed, the relationship between classes also needs to be understood. It may be difficult for beginners of software development (of course I am also ^-^) to learn this aspect, because of the lack of experience, because the idea of software design is not better trained and so on, of course, this is also the reason for learning. The design model is not just the 23 types mentioned in the book, but there are many others, however, I feel that it is not easy to master these models. Haha.

In your own understanding, the design model is not justAlgorithmIt is also an ideology that can solve repeated problems. It is an effective method that can be used to solve specific software problems in some specific scenarios, maybe it is not a good solution in other environments, maybe it will also bring a burden to the software, so it cannot use the design pattern in disorder, it should be "counterpart ", therefore, the principle of implementing the design pattern is to use refactoring to implement the pattern. Of course, there are also experienced design masters or some obvious problems with the application pattern.

Each pattern describes repeated problems in software development and the core of the solution to the problem. This pattern can be used with experience in future development. Therefore, each pattern has a general pattern name for the entire process. Now let's look at the 23 design patterns. These names are really good !! Each mode has four elements: Mode name, problem, solution, and effect. In other words, the correct use mode will bring absolute scalability and flexibility to the software system. If the application is not good, the effect can be imagined.

To learn the design model, the most important thing I have to mention here is the object-oriented concept. The abstract, encapsulation, inheritance, and polymorphism are all mentioned in my head! However, it is important to understand these concepts and "three-dimensional ".

If the design pattern is abstract enough, some design principles are embodied in the pattern. We may all know that here is a simple list:

1. Interface Programming rather than implementation programming. We say that inheritance is the basic mechanism of reusable extensions, and inheritance can be implemented well.CodeEffective separation with customers, enabling customersProgramYou don't have to know the specific implementation, but the implementation is just about its own business, when there is a problem with variability, I only need to expand or make a few changes to respond to the changes in software requirements (of course, this is when the design model applies properly .), This separates duties and uses a lot of interfaces in these design patterns (we can say that inheritance is divided into class inheritance and interface inheritance, and we all know it, huh, huh ).

2. Object combination is preferred, rather than class inheritance. The interface above is really good. Inheritance achieves reusability and scalability between interfaces and classes, but with profound consideration, this inheritance actually secretly leads to the coupling relationship between interfaces and implementations. We also call it white box multiplexing, that is, the inherited classes and classes are mutually understood, so here, if the interface layer needs to be changed, all these relationships must undergo a complex change. Of course, this can be solved. This is also the significance of this principle, using Object combination, we say that this relationship is a loosely coupled implementation method between classes. We call it Black Box multiplexing to achieve good scalability, this idea is embodied in the subsequent Structural Model in very seconds!

Here, we need to be certain that inheritance and combination are indispensable. We have no reason to say who is good or who is bad. All applications are determined based on the characteristics of the software.

3. Use refactoring to get the mode. I have seen this article from the handout by Mr. Li Jianzhong. It makes sense that all models are constantly evolved and reconstructed. What problems may be encountered during the development process, therefore, the blind application mode is actually an incorrect use of the mode, but it will not bring benefits to software development.

More specific principles are listed below for your reference:

1. Single responsibility principle. This principle shows that a class has only one reason to make it change, and the class design responsibilities are complicated and dizzy !!!

2. Open encapsulation principle. The class we mentioned here is unchangeable and extensible. Although this is the case, it can be changed when I encounter it .. Ah...

3. liskov replacement principle. Child classes must be able to replace their parent classes.

4. Dependency inversion principle. Specific description: The upper-layer module should not be tied to the lower-layer module, and both should be tied to abstraction. Abstraction should not depend on implementation details, but on abstraction. It's absolutely important !!

5. Interface isolation principle. This principle tells us that the interface design should not be very complex. We can only define the abstraction of our own functions, and subclass should not implement the abstraction that we don't need.

There are some other principles. If we say that the design model is an amazing skill, then these principles are just a matter of mind! Haha !!

Suddenly, the book introduces a very classic combination mode application around us. The implementation of the form container realizes one-to-many relationships into one-to-one relationships to solve the problem, form containers can load container controls or leaf controls, while internal container controls can nest more child and leaf controls!

That's all. If you have time, write more details. Please advise me if there are any unreasonable reasons! Over.