条款18：让接口容易被正确使用，不易被误用
考虑我们要设计一个Date类，其构造函数接受年月日三个参数，我们是否应该用int来表示这三个参数呢？可以，但不够好，因为月日的顺序往往不同的国家有不同的习惯，如果是int很容易会被误用，好一点的办法是定义不同的struct来表达月、日和年，这样用户就没那么容易误用接口了。这这里，月和日的取值是有范围的，如果我们让类型能够反应这种范围，那用户就更不容易犯错了，我们也许首先会想到enum，但enum不具有类型安全性，比如它可以很容易被当成int使用，更好的办法是，用static函数代替对象，来表达特定的月份，我们之所以不用static对象是因为non-local static对象的初始化次序有可能会有问题，所以我们使用static函数。
在条款13中，我们引入了一个factory函数，返回一个指针指向Investment继承体系中的一个动态分配对象：Investment * createInvestment();，为了避免资源泄漏，我们希望客户把获取的指针放到shared_ptr对象中确保资源最后被释放，但是万一客户忘记把它放到管理对象中，那就会有资源泄漏的风险了，如果我们把createInvestment的函数强制返回shared_ptr的对象，那客户就不必再把对象放到管理对象中了。更进一步，如果获取的对象，我们希望客户使用GetRidOfInvestment()来释放，而不是delete，那客户也是很容易误用的，但如果我们在返回的shared_ptr中指定deleter，那就也不会造成使用错误的删除器删除了。
条款19：设计class犹如设计type
条款20：宁以pass-by-reference-to-const 替换 pass-by-value
默认情况下，C++使用by value方式传递对象到函数，这时参数传递的成本是一次Copy构造函数、一次析构函数，而且如果对象中其他对象需要构造或者析构，则每个对象及自对象的构造函数和析构函数都要被调用一次，成本可是不低！替代的方式就是用pass-by-reference-to-const 代替pass-by-value。这样做还可以避免pass-by-value时的对象切割问题：当一个子类对象以pass-by-value的方式传递个一个需要基类对象的函数中，基类的Copy构造函数会被调用，这时会造成该对象子类部分的数据和性质丢失，只留下一个基类对象，这样很容易出现问题。具体例子可以再补充或者看书。
另外，内置类型很小，有人也许会认为小型对象进行pass-by-value是不会产生效率和对象切割问题的？不是的，效率跟对象大小没关系，小型对象也有可能需要很高的Copy构造代价，就是代价不高，还是会有效率上的问题，编译器对内置类型和自定义类型的处理方式是不一样的，即使它们底层有相同的表述形式，比如编译器很可能不会把一个只有一个double的对象放到寄存器中，但是很乐意把光秃秃的double放到寄存器中。如果使用pass-by-reference-to-const ，编译器一定会把reference放到寄存器中。小型对象不一定适合pass-by-value的另一个原因是现在的type很小，但将来有可能会变大。所以，唯一可以假设pass-by-value不昂贵的对象就是：内置类型和STL的迭代器和函数对象。
条款21：必须返回对象时，别妄想返回其reference
条款22：将成员变量声名为private
条款23：宁以non-member、non-friend替换member 函数
条款24：若所有类型需要类型转换，请为此采用non-member函数
条款25：考虑写出一个不抛出异常的swap函数