Effective C++：4、设计与声明

简介：

所谓软件设计，是 “令软件做出你希望它做的事情” 的步骤和做法，通常以颇为一般性的构想开始，最终演变为十足的细节，以允许特殊接口（interfaces）的开发。这些接口而后必须转换为 C++ 声明式。本章中我将对良好 C++ 接口的设计和声明发起攻势。我以或许最重要、适合任何接口设计的一个准则作为开端：“让接口容易被正确使用，不容易被误用”。这个准则设立了一个舞台，让其他更专精的准则对付一大范围的题目，包括正确性、高效性、封装性、维护性、延展性，以及协议的一致性。

以下准备的材料并不覆盖你需要知道的优良接口设计的每一件事，但它强调某些最重要的考虑，对某些最频繁出现的错误提出警告，为 class、function 和 template 设计者经常遭遇的问题提供解答。

条款18：让接口更容易被正确使用，不易被误用

• 好的借口很容易被正确使用，不容易被误用。你应该在你的所有接口中努力达成这些性质。

• “促进正确使用” 的方法包括接口的一致性，以及与内置类型的行为兼容。

• “阻止误用” 的办法包括建立新类型、限制类型上的操作，束缚对象值，以及消除客户的资源管理责任。

• tr1::share_ptr 支持定制型删除器（custom deleter）。这可防范 DLL 问题，可被用来自动解除互斥锁（mutexes；见条款14）等等。

条款19：设计 class 犹如设计 type

• Class 的设计就是 type 的设计。在定义一个新 type 之前，请确定你已经考虑过本条款覆盖的所有讨论主题。

条款20：宁以 pass-by-reference-to-const 替换 pass-by-value

• 尽量以 pass-by-reference-to-const 替换 pass-by-value。前者通常比较高效，并可避免切割问题（slicing problem）。

• 以上规则并不适用于内置类型，以及 STL 的迭代器和函数对象。对它们而言，pass-by-value 往往比较适合。

条款21：必须返回对象时，别忘想返回其 reference

• 绝不要返回 pointer 或 reference 指向一个 local stack 对象，或返回 reference 指向一个 heap-allocated 对象，或返回 pointer 或 reference 指向一个 local static 对象而有可能同时需要多个这样的对象。条款4已经为 “在单线程环境中合理返回 reference 指向一个 local static 对象” 提供了一份设计实例。

条款22：将成员变量声明为 private

• 切记将成员变量声明为 private 。这可赋予客户访问数据的一致性、可细微划分访问控制、允诺约束条件获得保证，并提供 class 作者以充分的实现弹性。

• protected 并不比 public 更具封装性。

条款23：宁以 non-member、non-friend 替换 member函数

• 宁可拿 non-member、non-friend 替换 member函数。这样做可以增加封装性、包裹弹性（packaging flexibility）和机能扩充性。

条款24：若所有参数皆需类型转换，请为此采用 non-member 函数

• 如果你需要为某个函数的所有参数（包括被 this 指针所指的那个隐喻参数）进行类型转换，那么这个函数必须是个 non-member 。

条款25：考虑写出一个不抛出异常的 swap 函数

• 当 std::swap 对你的类型效率不高时，提供一个 swap 成员函数，并确定这个函数不抛出异常。

• 如果你提供一个 member swap，也该提供一个 non-member swap 用来调整前者。对于 classes （而非 templates），也请特化 std::swap 。

• 调用 swap 时应针对 std::swap 使用 using 声明式，然后调用 swap 并且不带任何 “命名空间资格修饰”。

• 为 “用户定义类型” 进行 std templates 全特化是最好的，但千万不要尝试在 std 内加入某些对 std 而言全新的东西。