所谓软件设计，是“令软件做出你希望它做的事情”的步骤和做法，通常以颇为一般性的构想开始，最终变成十足的细节，以允许特殊接口的开发。
条款18：让接口容易被正确使用，不易被误用
许多客户端错误可以因为导入新类型而获得预防。在防范“不值得拥有的代码”上，类型系统是你的主要同盟国。
class Date { public: Date(int month,int day,int year); }; Date(30,2,1997)//应该是2,30 //导入新类型防止接口被误用 struct Day { explicit Day(int d):val(d) {} //explicit 避免隐式的转换。 int val; }; struct Month { explicit Month(int d):val(d) {} //explicit 避免隐式的转换。 int val; }; struct Year { explicit Year(int d):val(d) {} //explicit 避免隐式的转换。 int val; }; class Date { public: Date(const Month& m,const Day& d,const Year& y); }; Date(Month(3),Day(30),Year(1997)); //可以用enum来表示月份，但是enum不具备我们希望拥有的安全类型 class Month { public: static Month Jan(){return Month(1)}; //... private: explicit Month(int m); }; Date d(Month::Jan(),Day(30),Year(1997));
不能用对象替换为函数，表示某个月份，因为non-local static对象初始化次序可能存在问题。
除非有好的理由，否则应该尽量令你的类型（定义的类）的行为与内置类型一致
在资源管理方面，也许我们应该“先发制人”，即让函数返回一个资源的指针改为返回一个智能指针。
std::tr1::shared_ptr<Investment> createInvestment();
这便实质上强迫客户将返回值存储于一个tr1::shared_ptr内，几乎消除了忘记删除底部Investment对象的可能性。
tr1::shared_ptr提供的某个构造函数接受两个实参：一个是被管理的指针，另一个是引用次数变成0时被调用的“删除器”。但我们自己制定第二个参数，当然这是安全的。但是留给客户，那也许存在危险。
std::tr1::shared_ptr<Investment>//tr1::shared_ptr构造函数坚持第一个参数必须是个指针。 pInv(static_cast<Investment*>(0), getRidOfInvestment);
tr1::shared_ptr有一个特别好的性质是：它会自动使用它的“每个指针专属的删除器”，因而消除另一个潜在的客户错误：所谓的“cross-DLL problem”。因为它缺省的删除器是来自“tr1::shared_ptr诞生所在的那个DLL”的delete。
请记住：
- 好的接口很容易被正确使用，不容易被误用。你应该在你的所有接口中努力达成这些性质。
- “促进正确使用”的办法包括接口的一致性，以及与内置类型的行为兼容。
- “阻止误用”的办法包括建立新类型、限制类型上的操作，束缚对象值，以及消除客户的资源管理责任。
- tr1::shared_ptr支持定制删除器。这可防范DLL问题，可被用来自动解除互斥量等等。
条款19：设计class犹如设计type
C++就像在其它面向对象编程语言一样，当你定义一个新class，也就定义了一个新type。这意味着你并不只是类的设计者，更是类型的设计者。重载函数和操作符、控制内存的分配和归还、定义对象的初始化和终结......全部在你手上。
设计优秀的类是一项艰巨的工作，因为涉及好的类型是一项艰巨的工作。好的类型有自然的语法，直观的语义，以及一或多个高效实现品。
设计一个良好的类，或者称作类型，考虑一下设计规范：
- 新类型的对象应该如何被创建和销毁？
- 对象的初始化和对象的赋值该有什么样的差别？
- 新类型的对象如果被passed by value（值传递），意味着什么？
- 什么是新类型的“合法值”？
- 你的新类型需要配合某个继承图系吗？
- 你的新类型需要什么样的转换？
- 什么样的操作符和函数对此新类型而言是合理的？
- 什么样的标准函数应该驳回？
- 谁该取用新类型的成员？
- 什么是新类型的“未声明接口”？
- 你的新类型有多少一般化？
- 你真的需要一个新类型吗？
请记住：
- Class的设计就是type的设计。在定义一个新的type之前，请确定你已经考虑过本条款覆盖的所有讨论主题。
条款20：宁以pass-by-reference-to-const替代psss-by-value
缺省情况下C++以by value方式传递对象至函数。除非你另外指定，否则函数参数都是以实际实参的副本为初值，而调用端所获得的亦是返回值的一个副本。这些副本由对象的拷贝构造函数产生。所以在以对象为by value时，可能会调用相应的构造函数（成员对象的构造、基类对象的构造），然后调用对应的析构函数。所以以by value的形式开销还是比较大的。
如果我们用pass-by-reference-to-const，这种传递方式效率高得多：没有任何构造函数或析构函数被调用，因为没有任何新对象被创建。
class Base { public: string name() const; virtual void display const; }; class Derived:public Base { public: virtual void display() const; }; void print(Base b)//(Base& b) { cout<<b.name()<<endl; display(); } //如下调用方式 Derived d; print(d);//b参数会被构造成一个Base对象，所有派生类对象特化的信息都会被消除
以传引用方式传递参数也可以避免对象切割问题：即当一个派生类对象以传值的方式传递并被视为一个基类对象，基类对象的拷贝构造函数会被调用，而“造成此对象的行为像个派生类对象”的那些特化性质全被切割掉了，仅仅留下了基类对象。这一般不是你想要的。
所以我们一般的做法应该是这样：内置对象和STL的迭代器和函数对象，我们一般以传值的方式传递，而其它的任何东西都以传引用的方式传递。
请记住：
- 尽量以pass-by-reference-to-const替代pass-by-value。前者通常比较高效，并可避免切割问题。
- 以上规则并不使用于内置类型，以及STL的迭代器和函数对象。对它们而言，pass-by-value往往比较适当。
条款21：必须返回对象时，别妄想返回其reference
当我们领悟条款20中传值的开销后，总是避免于少用传值，然而在返回对象时，要格外小心了，因为你可能：传递一些引用或指针指向其实已经不存在的对象。这可不是件好事。
任何时候看到一个reference声明式，你都应该立刻问自己，它的另一个名称是什么，引用只是个名称，代表某个既有的对象。
函数创建新对象的途径有二：
- 栈上：即在函数内的局部变量。局部变量在函数返回后就没有存在的意义，所以传引用在栈上不可行。
- 堆上：在堆上构造一个对象，并返回。看似可行，也埋下了资源泄漏的危险。谁该对这对象实施delete呢？而且还必须付出一个构造函数的调用代价。别把这种对资源的管理寄托完全寄托于用户。所以传引用在堆上不可行。
可能还有一种想法：把“让返回的引用指向一个被定义于函数内部的静态对象”。出于我们对多线程安全性的疑虑，以及当线程中两个函数对单份对象的处理也可能带来不可测行为。所以静态对象也是不可行的。
const Rational& operator*(const Rational& a,const Rational& b) { static Rational res; res=... return res; } Rational a,b,c,d; if((a*b)==(c*d))//恒为true //等价于下列 if(operator==(operator*(a,b),operator*(c,d)))
operator==被要求用operator*内静态对象的值和operator*内静态对象的值来比较，两次operator*调用的确改变了各自静态对象的值，因为他们返回的都是引用，因此调用端永远都是static Rational的“现值”。
一个“必须返回新对象”的函数的正确写法是：就让那个函数返回一个新对象。
请记住：
- 绝不要返回pointer或reference指向一个local stack对象，或返回reference指向一个heap-allocated对象，或返回pointer或reference指向一个local static对象而有可能同时需要多个这样的对象。 条款4已经为单线程中合理返回一个reference指向一个local static对象提供一份设计实例。
条款22：将成员变量声明为private
其实只有两种访问权限：private（封装）和其他（不封装）。
请记住：
- 切记将成员变量声明为private。这可赋予客户访问数据的一致性、可细微划分访问控制、允许约束条件获得保护，并提供class作者以充分的实现弹性。
- protected并不比public更具封装性。
条款23：宁以non-member、non-friend替换member函数
面向对象要求，数据和操作数据的函数应该捆绑在一块，这意味着建议member是更好的选择。
面向对象要求数据应该尽可能地封装，因此member比non-memebr带来的封装性更低，因为封装意味着不可看见，越多东西被封装也就是越少的人能够看见，而越少的人能够看见，也就是能最大限度的去改变他们，
对象内的数据，越少的代码能够看见他们，越多的数据被封装，我们也就能最大限度的去改变数据。访问数据的函数量作为有多少代码能够看见数据。
成员函数不仅可以访问private成员变量，也可以取用private函数、enums、typedefs等等。而非成员非友元函数能实现更大的封装性，因为它不能增加访问class之内private成分的函数数量。
将所有便利函数放在多个头文件内但隶属同一个命名空间，意味客户可以轻松扩展这一组便利函数。需要做的就是添加更多non-member non-friend函数到此命名空间内。
请记住：
- 宁可拿non-member non-friend函数替代member函数。这样做可以增加封装性、包裹弹性和机能扩充性
条款24：若所有参数皆需类型转换，请为此采用non-member函数
通常，令类支持隐式类型转换通常是个糟糕的主意。当然这条规则有其例外，最常见的例外是在建立数值类型时。
const Rational operator*(const Rational& rhs) const; //如果定义一个有理数类，并实现*操作符为成员函数，如上所示；那么考虑一下调用： Rational oneHalf(1, 2); result = oneHalf * 2; // 正确，2被隐式转换为Rational（2，1），伴随一个放进参数列之内的参数 //编译器眼中应该是这样： const Rational temp(2); result = oneHalf * temp; result = 2 * oneHalf; //构造函数被声明为explicit时，错误，2，可不被认为是Rational对象；因此无法调用operator*，没有一个参数放进参数列之内
结论：只有当参数被列于参数列之内，这个参数才是隐式类型转换的合格参与者，低位相当于“被调用之成员函数所隶属的那个对象”——即this对象的那个隐喻参数绝不是隐式转换的合格参与者。
所以，支持混合式算术运算的可行之道应该是：让operator*成为一个non-member函数，允许编译器在每一个实参上执行隐式类型转换：
请记住：
- 如果你需要为某个函数的所有参数（包括被this指针所指的那个隐喻参数）进行类型转换，那么这个函数必须是个non-member。
条款25：考虑写出一个不抛异常的swap函数
“以指针指向一个对象，内含真正的数据”那种类型，这种设计形式是pimpl。“将隶属对象的数据”从原对象放进另一个对象，然后赋予原对象一个指针，指向那个所谓的实现对象（implementation object）。
class WidgetImpl { public: //... private: int a,b,c,d,e,f;//数据 vector<double> v;//意味着可能复制很长时间 }; class Widget { public: Widget(const Widget& w); Widget& operator=(const Widget& w) { //... *pImpl=*(w.pImpl); //... } private: WidgetImpl* pImpl; };
交换两个widget对象时，只需要交换两个pImpl指针，可以将swap针对widget特化
namespace std//不允许改变命名空间内的任何东西，但是可以为标准template制造特化版本 { template<>//全特化 void swap<Widget>(Widget& a,Widget& b)//这一特化版本是针对T是Widget设计的 { swap(a.pImpl,b.pImpl);//编译不过，pImple是private } }
可以令Widget内声明一个swap做真正的置换工作，然后将std::swap特化
class Widget { public: void swap(Widget& other) { using std::swap; swap(pImpl,other.pImpl); } private: WidgetImpl* pImpl; }; namespace std//不允许改变命名空间内的任何东西，但是可以为标准template制造特化版本 { template<>//全特化 void swap<Widget>(Widget& a,Widget& b)//这一特化版本是针对T是Widget设计的 { a.swap(b); } }
C++只允许偏特化template class，不允许function template偏特化，如果打算偏特化function template，我们可以为它添加一个重载版本。
客户可以全特化std内的template，但不可以添加新的template（class或function或其他任何东西）到std；
还可以使用命名空间
namespace WidgetStuff { ...//模板化的pImple template<typename T> class Widget{};//同前，内含swap函数 template<typename T> void swap(Widget& a,Widget& b)//非成员函数并不属于命名空间 { a.swap(b); } }
此时如果你打算交换两个swap，C++会根据名称查找法则找到WidgetStuff内的swap版本。
template<typename T> void doSomething(T& a,T& b) { using std::swap;//使std内的swap可用 swap(a,b); return ; }
编译器看到对swap的调用，会找到合适的版本。C++名称查找法则：确保找到global作用域或T所在的命名空间内任何T专属的swap，如果T位于WidgetStuff，编译器会使用“实参取决之查找法则”找出WidgetStuff内的swap，如果没有T专属的swap存在，就是用std内的swap（using的存在）。
std::swap(a,b);//error
编译器会使用std内的swap（包括其任何template特化），而不再使用一个比较适合的T的专属版本。
如果swap的缺省版本对class或template class有可接受的效率就是用他，如果效率不足（意味着class或template使用了pimpl）做以下事
- 提供一个public swap函数，让他高效的置换你的类型的两个对象的值。
- 在你的class或template所在的命名空间内提供一个non-member swap，令他调用上述的swap成员函数。
- 如果你正在编写class而非template class，为你的class特化std::swap，并令他调用你的swap成员函数。
如果你调用swap，要包含一个using声明式，以便让std::swap在你的函数内曝光可见。然后不加任何namespace修饰符调用swa。
请记住：
- 当std::swap对你的类型效率不高时，提供一个swap成员函数，并确定这个函数不抛出异常。
- 如果你提供一个member swap，也该提供一个non-member swap用来调用前者。对于class（而非templates），也请特化std::swap。
- 调用swap时应针对std::swap使用using声明式，然后调用swap并且不带任何“命名空间资格修饰”。
- 为“用户定义类型”进行std templates全特化是好的，但千万不要尝试在std内加入某些对std而言全新的东西。