zh-google-styleguide/google-cpp-styleguide/classes.rst

3. 类
------------------------
TODO

类是 C++ 中代码的基本单元. 显然, 它们被广泛使用. 本节列举了在写一个类时的主要注意事项.

3.1. 构造函数的职责
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

.. tip::
    构造函数中只进行那些没什么意义的 (trivial, YuleFox 注: 简单初始化对于程序执行没有实际的逻辑意义, 因为成员变量 "有意义" 的值大多不在构造函数中确定) 初始化, 可能的话, 使用 ``Init()`` 方法集中初始化有意义的 (non-trivial) 数据.

定义:
    在构造函数体中进行初始化操作.

优点:
    排版方便, 无需担心类是否已经初始化.

缺点:
    在构造函数中执行操作引起的问题有:

        - 构造函数中很难上报错误, `不能使用异常 <#...>`_.
        - 操作失败会造成对象初始化失败，进入不确定状态.
        - 如果在构造函数内调用了自身的虚函数, 这类调用是不会重定向到子类的虚函数实现. 即使当前没有子类化实现, 将来仍是隐患.
        - 如果有人创建该类型的全局变量 (虽然违背了上节提到的规则), 构造函数将先 ``main()`` 一步被调用, 有可能破坏构造函数中暗含的假设条件. 例如, `gflags <http://code.google.com/p/google-gflags/>`_ 尚未初始化.

结论:
    如果对象需要进行有意义的 (non-trivial) 初始化, 考虑使用明确的 ``Init()`` 方法并 (或) 增加一个成员标记用于指示对象是否已经初始化成功.

3.2. 默认构造函数
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

.. tip::
    如果一个类定义了若干成员变量又没有其它构造函数, 必须定义一个默认构造函数. 否则编译器将自动生产一个很糟糕的默认构造函数.

定义:
    ``new`` 一个不带参数的类对象时, 会调用这个类的默认构造函数. 用 ``new[]`` 创建数组时，默认构造函数则总是被调用.

优点:
    默认将结构体初始化为 "无效" 值, 使调试更方便.

缺点:
    对代码编写者来说, 这是多余的工作.

结论:
    如果类中定义了成员变量, 而且没有提供其它构造函数, 你必须定义一个 (不带参数的) 默认构造函数. 把对象的内部状态初始化成一致/有效的值无疑是更合理的方式.

    这么做的原因是: 如果你没有提供其它构造函数, 又没有定义默认构造函数, 编译器将为你自动生成一个. 编译器生成的构造函数并不会对对象进行合理的初始化.

    如果你定义的类继承现有类, 而你又没有增加新的成员变量, 则不需要为新类定义默认构造函数.

3.3. 显式构造函数
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

.. tip::
    对单个参数的构造函数使用 C++ 关键字 ``explicit``.

定义:
    通常, 如果构造函数只有一个参数, 可看成是一种隐式转换. 打个比方, 如果你定义了 ``Foo::Foo(string name)``, 接着把一个字符串传给一个以 ``Foo`` 对象为参数的函数, 构造函数 ``Foo::Foo(string name)`` 将被调用, 并将该字符串转换为一个 ``Foo`` 的临时对象传给调用函数. 看上去很方便, 但如果你并不希望如此通过转换生成一个新对象的话, 麻烦也随之而来. 为避免构造函数被调用造成隐式转换, 可以将其声明为 ``explicit``.

优点:
    避免不合时宜的变换.

缺点:
    无

结论:
    所有单参数构造函数都必须是显式的. 在类定义中, 将关键字 ``explicit`` 加到单参数构造函数前: ``explicit Foo(string name);``

    例外: 在极少数情况下, 拷贝构造函数可以不声明成 ``explicit``. 作为其它类的透明包装器的类也是特例之一. 类似的例外情况应在注释中明确说明.

.. _copy-constructors:

3.4. 拷贝构造函数
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

.. tip::
    仅在代码中需要拷贝一个类对象的时候使用拷贝构造函数; 大部分情况下都不需要, 此时应使用 ``DISALLOW_COPY_AND_ASSIGN``.

定义:
    拷贝构造函数在复制一个对象到新建对象时被调用 (特别是对象传值时).

优点:
    拷贝构造函数使得拷贝对象更加容易. STL 容器要求所有内容可拷贝, 可赋值.

缺点:
    C++ 中的隐式对象拷贝是很多性能问题和 bug 的根源. 拷贝构造函数降低了代码可读性, 相比传引用, 跟踪传值的对象更加困难, 对象修改的地方变得难以捉摸.

结论:
    大部分类并不需要可拷贝, 也不需要一个拷贝构造函数或重载赋值运算符. 不幸的是, 如果你不主动声明它们, 编译器会为你自动生成, 而且是 ``public`` 的.

    可以考虑在类的 ``private:`` 中添加拷贝构造函数和赋值操作的空实现, 只有声明, 没有定义. 由于这些空函数声明为 ``private``, 当其他代码试图使用它们的时候, 编译器将报错. 方便起见, 我们可以使用 ``DISALLOW_COPY_AND_ASSIGN`` 宏:
        .. code-block:: c++

            // 禁止使用拷贝构造函数和 operator= 赋值操作的宏
            // 应该类的 private: 中使用

            #define DISALLOW_COPY_AND_ASSIGN(TypeName) \
                        TypeName(const TypeName&); \
                        void operator=(const TypeName&)

    在 ``class foo:`` 中:
        .. code-block:: c++

            class Foo {
                public:
                    Foo(int f);
                    ~Foo();

                private:
                    DISALLOW_COPY_AND_ASSIGN(Foo);
            };

    如上所述, 绝大多数情况下都应使用 ``DISALLOW_COPY_AND_ASSIGN`` 宏. 如果类确实需要可拷贝, 应在该类的头文件中说明原由, 并合理的定义拷贝构造函数和赋值操作. 注意在 ``operator=`` 中检测自我赋值的情况 (Yang.Y 注: 即 ``operator=`` 接收的参数是该对象本身).

为了能作为 STL 容器的值, 你可能有使类可拷贝的冲动. 在大多数类似的情况下, 真正该做的是把对象的 *指针* 放到 STL 容器中. 可以考虑使用 ``std::tr1::shared_ptr``.

.. _structs_vs_classes:

3.5. 结构体 VS. 类
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

.. tip::
    仅当只有数据时使用 ``struct``, 其它一概使用 ``class``.

在 C++ 中 ``struct`` 和 ``class`` 关键字几乎含义一样. 我们为这两个关键字添加我们自己的语义理解, 以便未定义的数据类型选择合适的关键字.

``struct`` 用来定义包含数据的被动式对象, 也可以包含相关的常量, 但除了存取数据成员之外, 没有别的函数功能. 并且存取功能是通过直接访问位域 (field), 而非函数调用. 除了构造函数, 析构函数, ``Initialize()``, ``Reset()``, ``Validate()`` 外, 不能提供其它功能的函数.

如果需要更多的函数功能, ``class`` 更适合. 如果拿不准, 就用 ``class``.

为了和 STL 保持一致, 对于仿函数 (functors) 和特性 (traits) 可以不用 ``class`` 而是使用 ``struct``.

注意: 类和结构体的成员变量使用 `不同的命名规则 <...>`_.

.. _inheritance:

3.6. 继承
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

.. tip::
    使用组合 (composition, YuleFox 注: 这一点也是 GoF 在 <<Design Patterns>> 里反复强调的) 常常比使用继承更合理. 如果使用继承的话, 定义为 ``public`` 继承.

定义:
    当子类继承基类时, 子类包含了父基类所有数据及操作的定义. C++ 实践中, 继承主要用于两种场合: 实现继承 (implementation inheritance), 子类继承父类的实现代码; 接口继承 (interface inheritance), 子类仅继承父类的方法名称.

优点:
    实现继承通过原封不动的复用基类代码减少了代码量. 由于继承是在编译时声明, 程序员和编译器都可以理解相应操作并发现错误. 从编程角度而言, 接口继承是用来强制类输出特定的 API. 在类没有实现 API 中某个必须的方法时, 编译器同样会发现并报告错误.

缺点:
    对于实现继承, 由于子类的实现代码散布在父类和子类间之间, 要理解其实现变得更加困难. 子类不能重写父类的非虚函数, 当然也就不能修改其实现. 基类也可能定义了一些数据成员, 还要区分基类的实际布局.

结论:
    所有继承必须是 ``public`` 的. 如果你想使用私有继承, 你应该替换成把基类的实例作为成员对象的方式.

    不要过度使用实现继承. 组合常常更合适一些. 尽量做到只在 "是一个" ("is-a", YuleFox 注: 其他 "has-a" 情况下请使用组合) 的情况下使用继承: 如果 ``Bar`` 的确 "是一种" Foo, ``Bar`` 才能继承 ``Foo``.

    必要的话, 析构函数声明为 ``virtual``. 如果你的类有虚函数, 则析构函数也应该为虚函数. 注意 `数据成员在任何情况下都必须是私有的 <....>`_.

    当重载一个虚函数, 在衍生类中把它明确的声明为 ``virtual``. 理论依据: 如果省略 ``virtual`` 关键字, 代码阅读者不得不检查所有父类, 以判断该函数是否是虚函数.

.. _multiple-inheritance:

3.7. 多重继承
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

.. tip::
    真正需要用到多重实现继承的情况少之又少. 只在以下情况我们才允许多重继承: 最多只有一个基类是非抽象类; 其它基类都是以 ``Interface`` 为后缀的 :ref:`纯接口类 <interface>`.

定义:
    多重继承允许子类拥有多个基类. 要将作为 *纯接口* 的基类和具有 *实现* 的基类区别开来.

优点:
    相比单继承 (见 :ref:`继承 <inheritance>`), 多重实现继承可以复用更多的代码.

缺点:
    真正需要用到多重 *实现* 继承的情况少之又少. 多重实现继承看上去是不错的解决方案, 但你通常也可以找到一个更明确, 更清晰的不同解决方案.

结论:
    只有当所有父类除第一个外都是 :ref:`纯接口类 <interface>` 时, 才允许使用多重继承. 为确保它们是纯接口, 这些类必须以 ``Interface`` 为后缀.

.. note::
    关于该规则, Windows 下有个 :ref:`特例 <windows-code>`.


.. _interface:

3.8. 接口
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

.. tip::
    接口是指满足特定条件的类, 这些类以 ``Interface`` 为后缀 (不强制).

定义:
    当一个类满足以下要求时, 称之为纯接口:

        - 只有纯虚函数 ("``=0``") 和静态函数 (除了下文提到的析构函数).
        - 没有非静态数据成员.
        - 没有定义任何构造函数. 如果有, 也不能带有参数, 并且必须为 ``protected``.
        - 如果它是一个子类, 也只能从满足上述条件并以 ``Interface`` 为后缀的类继承.

    接口类不能被直接实例化, 因为它声明了纯虚函数. 为确保接口类的所有实现可被正确销毁, 必须为之声明虚析构函数 (作为上述第 1 条规则的特例, 析构函数不能是纯虚函数). 具体细节可参考 Stroustrup 的 *The C++ Programming Language, 3rd edition* 第 12.4 节.

优点:
    以 ``Interface`` 为后缀可以提醒其他人不要为该接口类增加函数实现或非静态数据成员. 这一点对于 :ref:`多重继承 <multiple-inheritance>` 尤其重要. 另外, 对于 Java 程序员来说, 接口的概念已是深入人心.

缺点:
    ``Interface`` 后缀增加了类名长度, 为阅读和理解带来不便. 同时，接口特性作为实现细节不应暴露给用户.

结论:
    只有在满足上述需要时, 类才以 ``Interface`` 结尾, 但反过来, 满足上述需要的类未必一定以 ``Interface`` 结尾.

3.9. 运算符重载
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

.. tip::
    除少数特定环境外，不要重载运算符.

定义:
    一个类可以定义诸如 ``+`` 和 ``/`` 等运算符, 使其可以像内建类型一样直接操作.

优点:
    使代码看上去更加直观, 类表现的和内建类型 (如 ``int``) 行为一致. 重载运算符使 ``Equals()``, ``Add()`` 等函数名黯然失色. 为了使一些模板函数正确工作, 你可能必须定义操作符.

缺点:
    虽然操作符重载令代码更加直观, 但也有一些不足:

    - 混淆视听, 让你误以为一些耗时的操作和操作内建类型一样轻巧.
    - 更难定位重载运算符的调用点, 查找 ``Equals()`` 显然比对应的 ``==`` 调用点要容易的多.
    - 有的运算符可以对指针进行操作, 容易导致 bug. ``Foo + 4`` 做的是一件事, 而 ``&Foo + 4`` 可能做的是完全不同的另一件事. 对于二者, 编译器都不会报错, 使其很难调试;

    重载还有令你吃惊的副作用. 比如, 重载了 ``operator&`` 的类不能被前置声明.

结论:
    一般不要重载运算符. 尤其是赋值操作 (``operator=``) 比较诡异, 应避免重载. 如果需要的话, 可以定义类似 ``Equals()``, ``CopyFrom()`` 等函数.

    然而, 极少数情况下可能需要重载运算符以便与模板或 "标准" C++ 类互操作 (如 ``operator<<(ostream&, const T&)``). 只有被证明是完全合理的才能重载, 但你还是要尽可能避免这样做. 尤其是不要仅仅为了在 STL 容器中用作键值就重载 ``operator==`` 或 ``operator<``; 相反, 你应该在声明容器的时候, 创建相等判断和大小比较的仿函数类型.

    有些 STL 算法确实需要重载 ``operator==`` 时, 你可以这么做, 记得别忘了在文档中说明原因.

    参考 :ref:`拷贝构造函数 <copy-constructors>` 和 :ref:`函数重载 <function-overloading>`.

3.10. 存取控制
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

.. tip::
    将 *所有* 数据成员声明为 ``private``, 并根据需要提供相应的存取函数. 例如, 某个名为 ``foo_`` 的变量, 其取值函数是 ``foo()``. 还可能需要一个赋值函数 ``set_foo()``.

一般在头文件中把存取函数定义成内联函数.

参考 :ref:`继承 <inheritance>` 和 :ref:`函数命名 <function-names>`

.. _declaration-order:

3.11. 声明顺序
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

.. tip::
    在类中使用特定的声明顺序: ``public:`` 在 ``private:`` 之前, 成员函数在数据成员 (变量) 前;

类的访问控制区段的声明顺序依次为: ``public:``, ``protected:``, ``private:``. 如果某区段没内容, 可以不声明.

每个区段内的声明通常按以下顺序:

    - ``typedefs`` 和枚举
    - 常量
    - 构造函数
    - 析构函数
    - 成员函数, 含静态成员函数
    - 数据成员, 含静态数据成员

宏 ``DISALLOW_COPY_AND_ASSIGN`` 的调用放在 ``private:`` 区段的末尾. 它通常是类的最后部分. 参考 :ref:`拷贝构造函数 <copy-constructors>`.

``.cc`` 文件中函数的定义应尽可能和声明顺序一致.

不要在类定义中内联大型函数. 通常, 只有那些没有特别意义或性能要求高, 并且是比较短小的函数才能被定义为内联函数. 更多细节参考 :ref:`内联函数 <inline-functions>`.

3.12. 编写简短函数
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

.. tip::
    倾向编写简短, 凝练的函数.

我们承认长函数有时是合理的, 因此并不硬性限制函数的长度. 如果函数超过 40 行, 可以思索一下能不能在不影响程序结构的前提下对其进行分割.

即使一个长函数现在工作的非常好, 一旦有人对其修改, 有可能出现新的问题. 甚至导致难以发现的 bug. 使函数尽量简短, 便于他人阅读和修改代码.

在处理代码时, 你可能会发现复杂的长函数. 不要害怕修改现有代码: 如果证实这些代码使用 / 调试困难, 或者你需要使用其中的一小段代码, 考虑将其分割为更加简短并易于管理的若干函数.

译者 (YuleFox) 笔记
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

#. 不在构造函数中做太多逻辑相关的初始化;
#. 编译器提供的默认构造函数不会对变量进行初始化, 如果定义了其他构造函数, 编译器不再提供, 需要编码者自行提供默认构造函数;
#. 为避免隐式转换, 需将单参数构造函数声明为 ``explicit``;
#. 为避免拷贝构造函数, 赋值操作的滥用和编译器自动生成, 可将其声明为 ``private`` 且无需实现;
#. 仅在作为数据集合时使用 ``struct``;
#. 组合 > 实现继承 > 接口继承 > 私有继承, 子类重载的虚函数也要声明 ``virtual`` 关键字, 虽然编译器允许不这样做;
#. 避免使用多重继承, 使用时, 除一个基类含有实现外, 其他基类均为纯接口;
#. 接口类类名以 ``Interface`` 为后缀, 除提供带实现的虚析构函数, 静态成员函数外, 其他均为纯虚函数, 不定义非静态数据成员, 不提供构造函数, 提供的话，声明为 ``protected``;
#. 为降低复杂性, 尽量不重载操作符, 模板, 标准类中使用时提供文档说明;
#. 存取函数一般内联在头文件中;
#. 声明次序: ``public`` -> ``protected`` -> ``private``;
#. 函数体尽量短小, 紧凑, 功能单一;