《Effective C++》总结——设计与声明

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

    要点：

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

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

如何设计高效的classes？几乎每一个class都要求你面对如下提问：

1. 新type的对象应该如何被创建和销毁？
2. 对象的初始化和对象的赋值有什么样的差别？
3. 新type的对象如果被passed by value（以值传递），意味着什么？
4. 什么是新type的“合法值”？
5. 你的新type需要配合某个继承图系吗？
6. 你的新type需要什么样的转换？
7. 什么样的操作符和函数对此新type而言是合理的？
8. 什么样的标准函数应该驳回？
9. 谁该取胜新type的成员？
10. 什么是新type的“未声明接口”？
11. 你的新type有多么一般化？
12. 你真的需要一个新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

    可能受到pass-by-value的效率牵连的影响，你可能会一心一意根除pass-by-value带来的种种问题。这可能会导致你犯下一个致使的错误：传递一些reference指向其实并不存在的对象。比如你可能写出下面这样的代码：
    const Rational& operator* (const Rational& lhs,const Rational& rhs)
    {
        Rational result(lhs.n*rhs.n,lhs.d*rhs.d);
        return result;
    }
    这里返回的是一个局部变量，当函数结束的时候result将被销毁，因此我们应该避免这种写法。

    你可能想到返回栈上的对象引用不行，我可以返回堆上的引用吧，于是你写出这样的代码
    const Rational& operator* (const Rational& lhs,const Rational& rhs)
    {
        Rational *result=new Rational(lhs.n*rhs.n,lhs.d*rhs.d);
        return result;
    }
    但是我会说返回一个堆上的对象引用可能会引发更严重的问题：到底是谁来完成delete操作？
    比如这样的调用代码：
        Rational w,x,y,z;
        w=x*y*z;
    这里先执行x*y，将返回一个全新的Rational对象，我们称它为ta,然后ta其与z进行operator*操作，这时又将生成一个新的Rational对象，并将w指向它，好了，你有没有发现此时ta已经丢失了？所以这绝对会导致内存泄漏。

    或许你已经注意到，不论返回一个栈上对象还是堆上的对象都会出现问题，因此你可以又会想到返回一个静态数据的Rational引用，于是你写出了如下的代码。
    const Rational& operator* (const Rational& lhs,const Rational& rhs)
    {
        static Rational result;
        result=...;
        return result;
    }

    考试下面这些完全合理的客户代码：
    Rational a,b,c,d;
    ...
    if((a*b)==(c*d)){
        ...
    }else{
        ...
    }
    这时可能达不到你想的结果，因为(a*b)==(c*d)总是被算为true。

    以上的例子足够说服你，想要对operator*这样的函数返回reference，只是浪费时间而已，如下做法应该可以被接受的：
    const Rational& operator* (const Rational& lhs,const Rational& rhs)
    {
        return Rational(lhs.n*rhs.n,lhs.d*rhs.d);
    }

    要点：

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

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

    public意味着不封装，而几乎可以说不封装意味不可改变，特别是对被广泛使用 classes而言。因此对于类的客户来说，如果你的变量改变的话，那么对客户来说需要改动的地方非常多，将成员变量隐藏在函数接口背后，可以为“所有可能的实现”提供弹性。
    而protected成员变量也十分类似，protected成员变量的封装性并不高于public成员变量，因为假如我们要取消一个protected成员变量的话，所有它的子类都将不能使用，因此protected成员变量就像public成员变量一样缺乏封装性。
    因此从封装的角度来看变量，只有两种访问权限：private（提供封装）和其它（不提供封装）。

    要点：

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

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

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

条款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而言全新的东西。