《Effective C++》重点摘要（四）

《Effective C++》第四章：设计与声明

1. 让接口容易被正确使用，不易被误用。一个接口由返回类型、接口名称、和参数列表组成，为了让接口容易被正确的使用，需要小心设计返回类型，最好是简单、直接、自然。接口名称选择很重要，做到简单、达意、无歧义。参数列表形参类型需要身份小心，如果能防范非法输入，尽力为之，形参名也尽可能做到同接口名称一样的标准。另外请保持命名习惯的一致性也能收到奇效。
2. 设计class犹如设计type。用户对语言内置的type支持的行为一般十分熟悉，所以最好自行设计的class能够像内置type一样，让用户使用起来得心应手。为了做到这个，可以问自己下面这些问题：
   1) 新type对象如何被创建和销毁？
   2) 对象的初始化和对象的赋值该有什么差别？
   3) 新type的对象如果被pass-by-value，意味着什么？
   4) 什么是新type的“合法值”？
   5) 新type需要配合某个继承图系吗？
   6) 新type需要什么样的转换？
   7) 什么样的操作符和函数对此新type而言是合理的？
   8) 什么样的标准函数应该驳回？需要拒绝的或是该声明为private的？
   9) 新type的成员访问权限是否合理？
   10) 什么是新type的为声明接口？它对效率、异常安全、资源利用提供何种保证？
   11) 新type有多么一般化？需要template吗？
   12) 这个新type真的是需要的吗？
3. 宁以pass-by-reference-to-const替换pass-by-value。以const引用作为引用的第一理由是安全，不会发生对象切割，第二理由是高效。但是语言内置的简单类型还是以值传递比较高效。
4. 必须返回对象时，别妄想返回其reference。为了效率返回引用……额，别想了，函数内部的局部变量在函数结束时会被析构的，引用怎么可以指向一个没有存在的对象呢？返回指针？可以是可以，但是谁保证释放这个指针指向的内存，并且这种方法也不一定总是有效。也许你可以利用RAII，返回一个智能指针。但是，最好还是返回对象吧，请放心，编译器可以使用NRV优化帮你分担一部分性能忧虑。
5. 将成员变量声明为private。封装得越多，实现者可以在幕后做更多手脚而不影响客户端代码；为封装的成员变量提供访问的函数接口，给用户更一致的使用风格；protected并不比public更具有封装性，因为它在子类中就像public一样。C++中只有两种访问权限：封装的（private）和不封装的。
6. 宁以non-member且non-friend替换member函数。这一个条款真的不适合几句话说清楚，这里我想说的是如果发现某个成员函数只是调用一序列public类型的函数来完成功能，那么就把它编写为一个non-member且non-friend函数。这样可以带来更大的封装性、包裹弹性和机能扩充性，降低编译依赖性。具体原因非常精彩，将以另一篇博文呈现。
7. 若所有参数皆需要类型转换，请为此采用non-member函数。比如为复数类重载一个乘法运算符（*），如果作为一个member函数，那么第一参数this将不能轻松实现转型，所以为了便利，将其实现为一个non-member函数会让日子过得更轻松一点。
8. 考虑写出一个不抛异常的swap函数。应该实现一个member版的swap函数，然后再实现一个non-member版的swap函数，让non-member版调用member版swap函数，一般情况下，这样做是为了copy-and-swap技术，从而做到异常安全，于是，不应该让swap函数抛出异常。