Style choice
[Warning] I have currently engaged in embedded development, and the views in the article are strongly influenced by my shallow development experience. Please look at the idea of criticism. In addition, this paper is actually developed as a measure of standards, please do not evaluate the views of this article in accordance with ideal criteria existing in theory.
[Master Quotations]
Herb SUTTER (1998): ... In our company's development, a large number of packages, inclusive, access control, ADT, no inheritance and polymorphism. We often use STL, Template ... as for exception, I usually use new (nothrow) classname! ;-) ...
Douglas Lea (1995): Perhaps the best view to C is to see it as a series of smaller, simple languages. Includes: an interface definition language, a data abstract language, a static type of object-oriented language, a procedural language (that is, C). Each aspect of it has some defects ... so that these models and features interact with each other will lead to serious complexity. Typically, the best means to deal with this complexity is to always adhere to a small number of design and programming techniques (that is, today's so-called mode - translator), which combines these technologies to become more common and effective technologies. (Designed and developed) A primary goal is to be as far as possible away from the dark corners of this language.
【text】
Bjarne Stroustrup said that C has four parts: Better C, ADT, OO, and GP. Although there are now some new styles proved to be used in C , such as functional, generative, meta programming, etc., but in actual engineering, the mainstream style is these four. We usually use the OO style to develop software, but strictly, the so-called OO style in C is a typical mixture.
Is it possible to think that C is actually a few different styles of language collection. That is, you can see it as a variety of languages, you can use only one of the languages for complete software development. If one or more style is used at the same time, the complexity will greatly increase. I personally think this is a major reason why C is difficult to control in practice. The mixing uses different styles, as if mixed in a source file using a variety of different languages, complex and inconsistency inevitable exposure. Of course, C unique charm is in the powerful power of mixed style programming. This is exactly a double-edged sword, although there is potential powerful power, but it is often an important reason for the chaos of the project.
I think actually developed the following principles will be able to avoid risks to some extent:
1). In any single time point, only one programming style is used.
2). In a style, it is used to organize the development of the overall module.
3). In a typical scene that is particularly suitable for another, you can package this scene with a sub-module, then use this style in the submodule, but remember to follow the requirements 1 to avoid a mixed style. In addition, the module must be packaged by the package to meet the requirements of the main style. For example, the main style is Better C, which is used in a submodule, which should make this sub-module from the whole view like a normal C process.
4). In individual occasions, the mixed style has a great advantage. However, this situation is relatively rare. Generally, successful practices have been summed up into patterns, so in practice, it can be forced to specify, only if you meet a Patterns, you can use a mixed style, strictly forbidden Create a new mixture without authorization. Now discuss how you should divide C style. Stroustrup's classification of C style is based on the perspective of language developers. If we are classified in the principles of the following, I think it will draw different results:
1) Each style must form a complete sub-language, complete, can use this sub-language to develop any software system, have a successful experience of historical verification.
2) The principle of each style must be relatively simple, consistent, simple, and recognized and verified.
3) Each sub-language must be able to find the corresponding other languages in the real world.
According to the above principles, I divide C into three semi-subscriptions:
1) BETTER C, only adds simple features such as function overload, reference type, default parameters, etc. C subregs. Corresponding to ANSI C language.
2) ADT C , ie C with Class, the entire program consists of a concrete class object, no inheritance, no polymorphism. Corresponding to the ADA 83 language.
3) IDL C , I call INTERFACE-Oriented, typical examples are COM component models.
3.5) GP C , using template technology to form a library and component implementation language. This is not a complete sub-language, on the one hand, because it can be regarded as an extension of ADT C , on the other hand, it must work with other styles.
Obviously, I have left one of the most important styles, which is what we usually say "traditional-oriented" style, displayed by languages such as SmallTalk, Java, by the MFC and other class libraries have passed many years of practical demonstration : Relying on a huge inheritance tree abstraction and organizing various data types, relying on inheritance and combination implementation code multiplexing. Why is this style not mentioned by me?
Because I think this style is actually a mixed style! It can be considered to be attempted to fuse the above 2nd, 3 and 3.5 style. In the above three principles, it severely violates the second. Due to the static nature of C , because C lacks a natural class library and garbage collection mechanism, it is very difficult to program the SmallTalk style in C , so that in order to overcome these difficulties, C actually develops a set of different smaltalk, A unique "object-oriented" programming style of Java style. This style has been practiced in nearly 15 years. It should be said that there is a failure, although a lot of work is published, there is no simple, consistent, and can guide style. In a sense, so many C object-oriented programming guidance books are often inadequate, and the level of difficulty in this style and difficult effect is explained. I personally, I am no longer guided by this style. I will never construct inherited trees again, think which functions should be virtual functions.
You can think that "inheritance for multiplexing" is a sign of this style. Note that ADT C allows a combination, and for inheritance, we should try to avoid it. The typical representative of IDL C does not support this inheritance at all, which supports only the multiplexing of the interface.
Of course, this is not to negate the achievements of C 's development in more than ten years. However, if you start planning a complete project from scratch, then I think if you choose this hybrid style, it is not wise. But this style also has two typical use scenarios: 1) has a complete framework support. For example, MFC. Although this style itself has many technical difficulties, the framework of MFC has helped you overcome a part, and create a relatively comfortable environment like SmallTalk, this style can be used. However, it is usually recognized that such frameworks have introduced some new problems while overcoming many technical difficulties, sometimes it is more difficult to deal with, so they are wise and ready to prepare.
2) in line with classic models. If you encounter a typical "object-oriented" scene, you have a mature, excellent, ready-made, documentated design solution, you can choose, cautiously. I refer to the main GOF and other design patterns. The so-called "classic mode" is absolutely not too much, but it is a large amount, repeatedly appears in the design, and often occurs. Such conditions are very suitable in solving the verified design. I personally have some practices here, I feel that I should pay attention to a few questions. The first is to be cautious, I have encountered a lot of situation, it seems that it is very suitable to solve it with a model, but it is really used to find that it is not such a thing. In the uncomfortable place to make a mistake, it will make things a mess; the second is to top the design plan, pack it, can't see what model you use from outside. The third is to pay attention to memory problems. The biggest obstacle to use the OO style is actually a memory problem.
In fact, this mouth is open, and there will still be a lot of "traditional OO" style in the final design, because the classic model is too common. Therefore, the main problem is to control and packaging, because the pattern of flooding is actually equal to returning to the mixed style.
It is worth noting that in most classic patterns, there is no "inheritance for multiplexing code". We can think that any reasonable object-oriented, inevitably has the characteristics of interface inheritance, inevitably abstract classes, which is likely to have polymorphic inclusion.
In personally, due to the development of embedded applications and high-level system software, I am more preferred for the extreme attention of the embedded system.
1) as ADT C as the main style.
2) Good ADT with GP auxiliary design. Realize code multiplexing in GP and combination.
3) Pack the possible OO in a planar class.
4) It is forbidden to use an exception. This will have a dedicated reflection.
For the development of PC and large projects, I think that the style of IDL C should be more appropriate. I haven't practiced this in this regard. But I hope to have some attempts as soon as possible.
Conclusion: Some people may question my attention to "reuse". Because of a large foothold of traditional OO. I don't deny this. I think that many programmers are not insufficient to renewal problems, but consider excessive. Especially the application programmer, spend too much energy to make your components meet the possible changes in future possible demand, which is likely to waste time. I also have some ideas for "reuse" this topic.
Idealistic topic:
1. Prohibit abnormal - survive in C without abnormalities
2. Reappear - think twice
3. The misunderstandings of "Standard Components"
