Object-oriented design defects
In this section, we will analyze which oo principles are violated by iostream design.
We know that the public inheritance in the object-oriented model must meet the liskov replacement principle. (See article 32 of Objective C ++ 3rd: Make sure that your public inherits the is-a relationship. Article 37 of the C ++ programming specification: Public inheritance means replacement.Inheritance is not reusable, but reusable..)
Where ostream is needed in the Program (for example, operator <), I pass in ofstream or ostringstream should be able to work as expected, which is the "alternative" emphasized by oo inheritance ", the object of the derived class can replace the base class object and be reused by operator.
The Inheritance System of iostream has repeatedly violated the liskov principle. The purpose of these inheritance systems is to reuse the code of the base class. In this system, I marked the illegal inheritance relationship with a red line.
In the existing inheritance system, there are:
- IfstreamIs-Istream
- IstringstreamIs-Istream
- OfstreamIs-Ostream
- OstringstreamIs-Ostream
- FstreamIs-Iostream
- StringstreamIs-Iostream
I think it is not reasonable:
- IOS inherits ios_base. Is there any scenario in which the program code expects the ios_base object, but can the user input an iOS object instead? If not, is the use of public inheritance in violation of the OO principle?
- Istream inherits from IOs. Is there any situation in which the program code expects IOS objects, but can the user input an istream object instead? If not, is the use of public inheritance in violation of the OO principle?
- Ostream inherits from IOs. Is there any situation in which the program code expects IOS objects, but can customers input an ostream object instead? If not, is the use of public inheritance in violation of the OO principle?
- Iostream multi-inheritance istream and ostream. Why does iostream inherit two non-interface classes at the same time? Is this interface inheritance or implementation inheritance? Can it be replaced by composition? (See article 38 of Objective C ++ 3rd: molded by CombinationHas-Or "implement with something ". C ++ programming specification Clause 34: replace inheritance with combinations as much as possible .)
Replace the inherited system with a combination:
Note that in the new design, only the realIs-The link uses public inheritance, and all others are replaced by a combination. The combination is represented by a red line. New designs do not use virtual inheritance or multi-inheritance.
The new real value of iostream is worth mentioning. The code structure is as follows:
class istream; class ostream; class iostream { public: istream& get_istream(); ostream& get_ostream(); virtual ~iostream(); };
In this way, when the iostream object needs to behave like istream, call the get_istream () function to return an istream reference. When the iostream object needs to behave like ostream, call get_ostream () the function returns an ostream reference. Functions are not affected, and the code is clearer. (Although I doubt the real value of iostream, it is both readable and writable. It indicates that it is a sophisticated Io object. Why is it still encapsulated with such a thick OO ?)
Based on the above analysis, we can summarize the limitations of iostream:
- In terms of input, istream is not suitable for inputting formatted data because the "error correction" capability is not strong. For further analysis, see a negative case of contract thinking written by Meng Yan. meng Yan said, "complicated design will inevitably bring about complicated rules for use. In the face of complicated rules for use, users can vote, that is, you do your work, and I don't need it!" It can be described as a spur. If you want to use istream, we recommend that you use Getline () to read a row of data, use a regular expression to determine whether the content is correct, and then group the data, then type conversion is performed using functions such as strtodd/strtol. This makes it easier to write robust programs.
- In terms of output, ostream's formatted output is very cumbersome, and it is not as flexible as stdio's small language. We recommend that you use it only for simple format-free output.
- Log, because ostream cannot guarantee the integrity of a row of output in a multi-threaded program, it is recommended not to use it directly to write logs. If it is a simple single-threaded program, you can use it if the output data volume is small. Of course, the product code should use a mature logging library instead of other things.
- In-memory formatting, because ostringstream dynamically allocates memory, it is not suitable for scenarios with high performance requirements.
- For file IOOrOutput, (I | O) fstream has the disadvantages described above. If it is used as binary data input and output, it seems easier to encapsulate a file class, you do not have to pay the cost for unused features (see the following example ). Ifstream is used to read a simple text configuration file when the program starts. If the configuration file is in another text format (XML or JSON), the corresponding library will be used for reading, and ifstream will not be used.
- In terms of performance, iostream has not fulfilled its promise of "high efficiency. Iostream is faster than stdio in some cases and slower than stdio in some cases. For scenarios with high performance requirements, we should implement String Conversion by ourselves (see the code and test below ). Iostream performance considerations: on the online ACM/ICPC question recognition website, if a simple question has a timeout error, replace the input and output of iostream with stdio, and sometimes pass the test.
Since there are so many limitations, the application of iostream in actual projects is greatly limited, and it is not worthwhile to invest too much energy in it. To be honest, I have never seen any c ++ product code using iostream as an input/output facility. Http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Streams
For more memory, see:
Http://blog.csdn.net/solstice/article/details/6612179
