Effective C++ 设计与声明

条款18：让接口容易被正确使用，不易被误用 Make interfaces easy to use correctly and hard to use incorrectly.

欲开发一个“容易被正确使用，不容易被误用”的接口，首先必须考虑客户可能做出什么样的错误。

请记住
■ 好的接口很容易被正确使用，不容易被误用。你应该在你的所有接口中努力达成这些性质。
■ “促进正确使用”的办法包括接口的一致性，以及与内置类型的行为兼容。
■ “阻止误用”的办法包括建立新类型、限制类型上的操作，束缚对象值，以及消除客户的资源管理责任。
■ shared_ptr支持定制型删除器（custom deleter）。这可防范DLL问题，可被用来自动解除互斥锁（mutexes；见条款14）等等。

条款19：设计class犹如设计type Treat class designas type design.

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

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

请记住
■ 尽量以pass-by-reference-to-const替换pass-by-value。前者通常比较高效，并可避免切割问题（slicing problem）。
■ 以上规则并不适用于内置类型，以及 STL 的迭代器和函数对象。对它们而言，pass-by-value往往比较适当。

条款21：必须返回对象时，别妄想返回其reference Don't try to return a reference when you must return an object.

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

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

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

条款23：宁以non-member、non-friend替换member函数 Prefer non-member non-friend functions tomember functions.

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

个人理解：
能够以non-member non-friend函数实现的功能自然比成员函数更少的直接操作内容数据，自然就增加了封装性。由于不是和类直接绑定，自然增加了扩充性。

条款24：若所有参数皆需类型转换，请为此采用non-member函数 Declare non-member functions when type conversions should apply to all parameters.

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

个人理解：实际中每太注意这种情况，遇到了在分析一下。

条款25：考虑写出一个不抛异常的swap函数 Considersupport for a non-throwing swap.

请记住
■ 当std：：swap对你的类型效率不高时，提供一个swap成员函数，并确定这个函数不抛出异常。
■ 如果你提供一个member swap，也该提供一个non-member swap用来调用前者。对于classes（而非templates），也请特化std：：swap。
■ 调用swap时应针对std：：swap使用using声明式，然后调用swap并且不带任何“命名空间资格修饰”。
■ 为“用户定义类型”进行std templates全特化是好的，但千万不要尝试在std内加入某些对std而言全新的东西。

摘自《Effective C++：改善程序与设计的55个具体做法：第三版》