Design Patterns learning notes-Introduction to design patterns

I have only been studying programming for two years and have not done any big applications yet. I joined the C language and made several small games such as Russian. Sophomore contacts win api and DX and understands C ++. At that time, I really felt that C ++ had nothing to do. It was just a high-level C. But later, I gradually discovered the depth of object-oriented design. Write in C ++ Program It is really difficult. Unlike C, it adds functions to implement functions, but considers the maintainability of the program to define various types. The determination of the class is too knowledgeable. It was not until the end of last semester that I first heard about the design model that I learned how to use object-oriented design programs. I have downloaded an electronic version of "Design Patterns" from the Internet. Now I want to start learning. With this blog, you can also supervise my learning.
Section 1.6 most resonates with the introduction of this book. This section shows all the difficulties and questions I have encountered since the object-oriented programming.
(1). Find the appropriate object. In the past, I thought it was okay to write the C program structure, but now I have to consider the functions of the Program on the disk to determine the class, this is a challenge for a person with little development experience. Every time I write half of the program, I often find that the division of the original class is no longer applicable.
(2). determines the object granularity. I have one idea about this problem, that is, when designing a class and its interfaces, the functions of the class are not improved, the finer the better. A well-designed class requires simple and practical interfaces, which is also advocated by a theory called extreme programming. At the beginning of the class design, in order not to expand the class to a point that is difficult to control, it usually only involves relatively simple and applicable interfaces.
(3). Specify the object interface. Polymorphism is the main cause. I think this is one of the main reasons why object-oriented programming has so many design patterns.
(4) describes the implementation of an object. This section mainly describes abstract classes. It proposes a principle: interface programming rather than implementation programming. I still don't quite understand this sentence. I will understand it later. This is the first time I have heard of it.
(5) reuse mechanism. A few comparisons are made here. The first is the comparison between inheritance and combination. The difference between the two is a general understanding, and now it is clear. Inheritance can quickly and conveniently implement interface reuse, but it makes the coupling between the Child class and the parent class too large. When the implementation of an interface of the parent class changes, the Child class also changes, this may make the subclass no longer meet the original requirements. Of course, sometimes this can be solved by inheriting abstract classes. The combination ensures good encapsulation between classes, and its Implementation changes dynamically. Good encapsulation makes programming easier to control by combining methods. The author puts forward the second principle: give priority to object combination instead of class inheritance. In normal programming, I seem to have used inheritance too much.
Then there is about delegation. Now I want to use the delegate when I used to build a socket program. At that time, there were many connections on the server side, but there was only one proxy on the server side. The proxy will be responsible for communication between each connection. At that time, efficiency was also taken into account, but at last we did not come up with a more convenient method.
The last is about the template. I have never been very familiar with Templates. After learning STL, I feel that the templates here are all in disorder. Find a time to supplement STL.
(6) Aggregation and acquaintance. I don't understand either of these two words at all. I can only understand it later.
(7) procedures should support changes. Indeed, Code Rewrite is often because the class structure does not support new requirements. But doing this well requires a lot of experience. At the beginning of the program design, I often tried to make the Code support changes as much as possible, but often did not do well. The reason is that I have insufficient understanding and proficiency in the knowledge, I am not familiar with the basic methods of object-oriented programming. I want to learn the design pattern to make up for my shortcomings in these aspects.
Base This is basically the case. Although the other part is also very important, the most important part in my heart is the 1.6 part. This is the end of the note.