General High-Performance High-concurrency TCP-SERVER/client development framework practice series based on C ++
Yijian technologier@126.com
1. Looking back
I have been working for a few years and have nothing to worry about. I am either busy at work or busy at rest. I wrote articles in some technical forums in the first year of my senior and work, but it was just n years ago, in the past, the habit of writing small programs was also interrupted three or four times before. Today, we are already thirty people. Faced with the current situation of blank hands, we will inevitably feel lost and sorry. Passion seems a little far away from me, but as I work longer, I feel that I have many things to express. First, I will make a summary for myself, second, we hope that some experiences can be discussed with you. If you are not correct, pat the bricks to correct them.
2. About the title
The title of this article is very long, but it also represents the purpose of this series of articles: first, to implement a TCP-based server and client framework; second, the framework requirements are common; third, high framework performance is required to meet the needs of a large concurrency environment; third, the implementation of the framework uses C ++; and fourth, pure-face object development is required, not just a class packaging.
3. Object-oriented
I am a fan of object-oriented technology. I usually have little communication with people in this area. I hope to use this opportunity to meet more object-oriented enthusiasts to improve my ability in this area.
I have been dealing with object-oriented objects for several years. Although I am still learning it, I hope I can discuss it with you. Using object-oriented analysis and design can give me a pleasant feeling. In my opinion, object-oriented design is like building block games. It can even be used to compare and manage a company. There are many similarities among them. Through such comparison, better understanding of the idea of object-oriented methods.
4. Design Pattern and object-oriented
The design pattern is closely related to the object-oriented model, and various patterns are inseparable from the object-oriented feature. Many new contacts have a great deal of interest and enthusiasm for the design model. However, they often feel that the design model is hard to digest and even appears to be designed for the model.
Patterns are experience and object-oriented are thoughts and basic concepts. If you do not have sufficient understanding of object-oriented, it is estimated that you will encounter great resistance when learning the design patterns. I personally feel that learning the design mode and the object-oriented method are not as good as starting from the five basic principles of object-oriented, so as to get twice the result with half the effort and achieve the effect of cutting firewood without mistake.
5. Three basic features
Fully understanding the three basic features of object-oriented is the basis for understanding the five basic principles of object-oriented. These three features are:
5.1. Encapsulation
This is the first feature of object-oriented systems. It cannot be said that if a class is used to wrap all the members, it will encapsulate them. Private, protected, and public are very important, that is, we should not only encapsulate them well, in addition, we should try to use a smaller visible range. Many companies share the principle of minimizing authorization, which is the same principle.
5.2. Inheritance
The most important purpose of inheritance is code reuse.
5.3. Polymorphism
In C ++, there are two types of polymorphism: static and dynamic: static refers to the template, which is the polymorphism in the compilation period, and dynamic refers to virtual, which is the polymorphism in the runtime period. Using this feature is of great significance to the structure of improving performance, and it is also the most difficult to grasp and control among the three basic features.
6. five basic principles
6.1. Single Responsibility Principle SRP (single responsibility principle)
It means that a class has a single function and cannot be all-encompassing. Like a person, you cannot allocate too much work. Otherwise, even though you are busy all day long, the efficiency is not high.
6.2. OCP (Open-Close principle)
A module should be open in terms of scalability and closed in terms of modification. For example, if a network module is originally only used for server functions, but now needs to be added to the client functions, the client function implementation code should be added without modifying the server function code, this requires that the server and client should be separated at the beginning of the design, and the public part should be abstracted out.
6.3. replacement principle (the liskov substitution principle LSP)
Subclass should be able to replace the parent class and appear anywhere the parent class can appear. For example, if an annual gala is held in a company and all employees can participate in the lucky draw, the lucky draw should be available for both old employees and new employees, as well as headquarters employees and expatriate employees. Otherwise, the company will not be in harmony.
6.4. The dependency inversion principle dip)
Specific dependency abstraction. The upper layer depends on the lower layer. Assume that B is a lower module than a, but B needs to use the function. At this time, B should not directly use the specific class in:
B should define an abstract interface and a should implement this abstract interface. B only uses this abstract interface:
In this way, the dependency inversion is achieved, and B also removes the dependency on A. In turn, a depends on the abstract interface defined by B.
It is difficult to avoid dependency on lower-layer modules through upper-layer modules. If B is also directly dependent on the Implementation of A, it may cause circular dependency. A common problem is that when compiling module A, it needs to directly include the CPP file of Module B. When compiling module B, it also needs to directly include the CPP file of module.
6.5. The interface segregation principle ISP)
Modules must be isolated through abstract interfaces, rather than strongly coupled by specific classes.
7. Series Structure
This series consists of four parts: The first part is the preface, the second part is the basics, the third part is the server, and the fourth part is the client.
7.1. Preface
This document briefly introduces the system, the starting point and purpose of writing, and the content of the series.
7.2. Basics
The general design of the underlying server and client framework. Since the relationship between these categories is simple, we plan to describe them simply to save time and do not provide instances.
7.3. Server
Focus on the introduction of the server, including more detailed class diagrams and time sequence diagrams, and some pseudo-code, and provide an instance as much as possible. We plan to use an httpserver as an instance, static Page performance requirements are higher than ngix/lighttp/Apache.
7.4. Client
Focus on the introduction of the client, including more detailed class diagrams and sequence diagrams, and some pseudo code, and provide an instance as much as possible.
8. Writing plan
My recent work is the busiest time in my life. I have been working overtime for several Friday nights in a row and it is estimated that it will last until March 13, April. Therefore, we can only steal some time to write it during the week before the Spring Festival.