Guru of the Week 条款04: 类的构造技巧

GotW #04 Class Mechanics

著者：Herb Sutter     

翻译：kingofark

[声明]：本文内容取自www.gotw.ca网站上的Guru of the Week栏目，其著作权归原著者本人所有。译者kingofark在未经原著者本人同意的情况下翻译本文。本翻译内容仅供自学和参考用，请所有阅读过本文的人不要擅自转载、传播本翻译内容；下载本翻译内容的人请在阅读浏览后，立即删除其备份。译者kingofark对违反上述两条原则的人不负任何责任。特此声明。

Revision 1.0

Guru of the Week 条款04: 类的构造技巧

难度：7.5 / 10

（你在实现类的细节方面到底有多行？本条款不仅要讲述一些可怕的错误，还要更多的涉及专业的编码风格方面的内容。）

[问题]

    你正在考查另一个程序员编写的一个类（见下），这个类的编码风格很差劲，而且还有一些严重的错误。你能找到多少个，又怎么进行修改呢？ 

    class Complex {
  
  

    public:

        Complex( double real, double imaginary = 0 )

          : _real(real), _imaginary(imaginary) {};

         void operator+ ( Complex other ) {
  
  

            _real = _real + other._real;

            _imaginary = _imaginary + other._imaginary;

        }

         void operator<<( ostream os ) {
  
  

            os << "(" << _real << "," << _imaginary << ")";

        }

         Complex operator++() {
  
  

            ++_real;

            return *this;

        }

         Complex operator++( int ) {
  
  

            Complex temp = *this;

            ++_real;

            return temp;

        }

     private:

        double _real, _imaginary;

    };

[解答]

 [前言]：实际上，这个类所包含的错误比我们下面要讲述的还要多。但出这道难题的意图，与其说是要指出其设计得很差劲的接口，还不如说主要是为了体现类的构造技巧（比如，“典型的operator<<是如何实现的？”，“应该把operator+视为一个成员吗？”，等等）。不管怎么说吧，我将从非常有用的第0点开始讲起……

0．  既然标准库里面已经有一个Complex类，何苦自己再写一个呢？（更何况标准库里的这一个是集业内最优秀的高手们多年经验之结晶，绝对不会出现下面讲述的任何一个问题。所以嘛，你还是“不耻复用”吧！）