C++之让接口容易被正确使用，不易被误用（18）---《Effective C++》

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

C++中如果想要开发一个“容易被正确使用，不易被误用”的接口，首先必须考虑客户可能犯的错误，以日期类举例：

class Date{
    Date(int month,int day,int year);
    ...
}

这样可以吗？当然可以呀，那么有问题吗？当然有呀，如果用户想要通过如下代码调用时候，这锅谁背？

Data d(1,10,1995);//到底是1月10号，还是10月1号；
Date(1996,100,1);//什么意思，却能通过编译

别想甩锅啦，当然设计者来背啦，你如果不设计错的话，用户怎么可能调用，那么我们怎样避免这个问题呢？设计人员可需要费些心思啦！

struct Day{
explicit Day(int d):val(d){}
int val;
};
struct Month{
explicit Month(int m):val(m){}
int val;
};
struct Year{
explicit Year(int y):val(y){}
int val;
};
class Date{
public:
    Date(const Month& m,const Day& d,const Year& y);
    ...
}
Date d(10,1,1995);//无法编译，无法隐式转换；
Date d(Day(30),Month(2),Year(1995));//错误，类型匹配错误
Date d(Month(3),Day(30),Year(1995));//终于正确啦

这样的设计显然比上面的设计更好一些啦，那么，有没有错误呢？试试呀！
请看如下代码：

Date d(Month(100),Day(1000),Year(1995));//也能通过编译

很不幸的是，这样也能通过编译，又是设计人员的锅，好心累，不过没办法，干一行爱一行呀，总不能甩锅给用户吧！逻辑错误，我们继续设计相应的代码，解决逻辑错误咯！
下面我们以月份Month类举例，Day类类似！

class Month{
public:
    static Month Jan(){return Month(1);
    }
    static Month Feb(){return Month(2);
    }
    ...
    static Month Dec(){return Month(12);
    }
    ...
private:
    explicit Month(int m):m(m){}
    int m;
    ...
};
Date d(Month::Mar(),Day(30),Year(1995));

相似的情况还有很多，例如任何接口如果要求用户必须要记得某件事情，就是在玩火，因为用户可能会忘记，例如条款13中的代码：
Investment* createInvestment();
为避免资源泄露，createInvestement()返回的指针最终必须被删除，但这样至少给了用户两种错误的机会：没有删除指针或者删除指针超过两次！设计人员设计时候可以设计为：

std::trl::shared_ptr<Investement> createInvestment();

这样便强制了用户将返回值存储在一个trl::shared_ptr中，不管用户会不会忘记删除，RAII类机制总是可以保证在程序在函数或块结束的时候释放这些资源！
我们还可以这样操作，通过为std::trl::shared_ptr带上另一个参数，即引用次数变为0时候调用的“删除器”，这启发我们创建一个null的std::trl::shared_ptr并伊getRidOfInvestment作为删除器，代码演示：

std::trl::shared_ptr<Investment> pInv(0,getRidOfInvestment);
    //这样无法通过编译，因为0虽然可以转换为指针，但在这种情况下不好，因为std::trl::shared_ptr坚持要一个纯指针，类型转换可以解决这种问题
std::trl::shared_ptr<Investement> pInv(static_cast<Investment*> (0),getRidOfInvestment);

或者这样：

std::trl::shared_ptr<Investment> createInvestment(){
    std::trl::shared_ptr<Investment> retVal(static_cast<Investment*>(0),getRidOfInvestment);
    ret=...
    return retVal;
}

这样的话，我们通过使用static_cast转换进行强制类型转换（后续条款款27将有介绍static_cast）我们先将原始指针置为null，然后在对其进行赋值，这样的话效率并不好，直接将指针传给retVal效果会更好，具体答案见条款26（还没发布呢，后续将连更博客！）
std::trl::shared_ptr有一个特别好的性质是：它会自动调用它的“每个指针专属删除器”，进而消除另一个潜在的客户错误。很多“cross-DLL problem”发生于“对象在动态链接库（DLL）中被new创建，却在另一个DLL内被delete掉，导致出错”，std::trl::shared_ptr没有这个问题，因为它缺省的删除器来自于”std::trl::shared_ptr诞生在所在的那个DLL”的delete。举个例子吧，假设HelInvestment是派生自Investment类，参看如下代码：

std::trl::shared_ptr<Investment> createInvestement(){
    return std::trl::shared_ptr<Investment>(new HelInvestment);
}

返回的std::trl::shared_ptr可被传递给其他任何DLLs，无需在意“cross-DLL problem”，这个指向HelInvestment的std::trl::shared_ptr会追踪记录“当HelInvestment的引用计数变为0是改掉用的那个DLL中的delete函数，不会被另一个DLL的delete函数调用“。
总结：
1）好的接口容易被正确调用，不易被无用，因此，设计人员需要负责；
2）“促进正确使用”的办法包括接口一致性，以及与内置类型行为兼容；
3）“阻止误用”的办法包括建立新的类型、限制类型上的操作，舒服对象值，以及消除客户的资源管理责任；
4）std::trl::shared_ptr支持定制版删除器，这可防范cross-DLL problem，可悲用来自动接触互斥锁问题等等。