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

要设计一个“容易被正确使用，不易被误用”的接口，首先必须考虑客户可能做出什么样的错误。

例如为一个用来表现日期的class设计构造函数：

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

虽然这个代码能够进行使用，但客户容易犯下错误：

1.他们可能会以错误的次序传递参数

例：Date d(30,3,1995);//应该是3，30而不是30，3

2.他们可能传递一个无效的月份或天数

例：Date d(2,30,1995);//2月没有第30天

针对上述错误，可以导入简单的外覆类型（wrapper types）来区别天数、月份和年份，然后于Date构造函数中使用这些类型：

struct Day{
    explict Day(int d):val(d){}
    int val;
};
struct Month{
    explict Month(int m):val(m){}
    int val;
};
struct Year{
    explict Year(int y):val(y){}
    int val;
};
class Date{
public:
    Date(const Month& m,const Day& d,const Year& y);
};
//Date d(30,3,1995);//错误，不正确的类型
//Date d(Day(30),Month(3),Year(1995));//错误，不正确的类型
//Date d(Month(3),Day(30),Year(1995));//正确

对于上述代码，最好用class定义Day，Month和Year。

令Day，Month和Year成为成熟且经充分锻炼的class并封装其内数据，比简单使用上述的struct好。 

预防客户错误的另一个方法是，限制类型内什么事可做，什么事不能做。常见的限制是加上const。

另一个一般性准则是“除非有好理由，否则应该尽量令你的type的行为与内置type一致”。

例如，客户已经知道像int这样的type有些什么行为，所以你应该努力让你的type在合样合理的前提下也有相同表现。例如，若a和b都是int，则对a*b赋值并不合法，所以除非你有好的理由与此行为分道扬镳，否则应该让你的type也有相同的表现。

任何接口如果要求客户必须记得做某些事情，就是有着“不正确使用”的倾向，因为客户可能会忘记做那件事。

例如，条款13导入了一个factory函数，它返回一个指针指向Investment继承体系内的一个动态分配对象：

Investment* createInvestment();

为避免资源泄漏，createInvestment返回的指针最终必须被删除，但那至少给了两个客户错误机会：

1.没有删除指针

2.或删除指针同一个指针超过一次

改进是将createInvestment的返回值存储于一个智能指针内，因而将delete责任推给智能指针。但万一客户忘了使用智能指针怎么办？

再改进是先发制人，令factory函数返回一个智能指针：

std::tr1::shared_ptr<Investment> createment();

 这实质上强迫了客户将返回值存储于一个tr1::shared_ptr内，几乎消弭了忘记删除底部Investment对象（当它不再被使用时）的可能性。

返回tr1::shared_ptr让接口设计者得以阻止一大群客户犯下资源泄漏的错误，因为tr1::shared_ptr允许当智能指针被建立起来时指定一个资源释放函数（所谓删除器）绑定于智能指针上。

假设class设计者期许那些“从createInvestment取得Investment* 指针”的客户将该指针传递给名为getRidofInvestment的函数，而不是直接在它身上使用delete。但这样的一个接口又导致了另一个问题，即“企图使用错误的资源析构机制”（也就是拿delete替换getRidofInvestment）。

改进是先发制人，返回一个“将gerRidoInvestment绑定为删除器（deleter）”的tr1::shared_ptr。

tr1::shared_ptr提供的某个构造函数接受两个实参：一个是被管理的指针，另一个是引用次数为0时将被调用的“删除器”。可以创建一个null tr1::shared_ptr并以getRidofInvestment作为其删除器：

std::shared_ptr<Investment> pInv(0,getRidofInvestment);
//企图创建一个null shared_ptr并携带一个自定的删除器
//但此式无法通过编译

上述代码无法通过编译，因为tr1::shared_ptr构造函数坚持其第一参数必须是个指针，而0不是指针，虽然0可隐式转换为一个指针，但在此情况下并不够好，因为tr1::shared_ptr坚持要一个不折不扣的指针。可以显式转换：

std::tr1::shared_ptr<Investment> 
pInv(static_cast<Inestment*>(0)),getRidofInvestment);
//建立一个null shared_ptr并以gerRidofInvestment为删除器

因此，要实现createInvestment使它返回一个tr1::shared_ptr并夹带getRidofInvestment函数作为删除器，总的代码为：

std::tr1::shared_ptr<Investment> createInvestment()
{
    std::tr1::shared_ptr<Investment> 
    retVal(static_cast<Investment*>(0),getRidofInvestment);
    //retVal=...//令retVal指向正确对象
    return retVal;
}

若被pInv管理的原始指针可以在建立pInv之前先确定下来，则“将原始指针传给pInv构造函数”会比“先将pInv初始化为null再对它做一次赋值操作”为佳。

tr1::shared_ptr的一个性质：它会自动使用它的“每个指针专属的删除器”，因而消除另一个潜在的客户错误：所谓"cross-DLL problem"。这个问题发生于“对象再动态连接程序库（DLL）中被new创建，却在另一个DLL内被delete销毁”。在许多平台上，这一类“跨DLL的new/delete成对运用”会导致运行期错误。但tr1::shared_ptr没有这个错误，因为它缺省的删除器是来自“tr1::shared_ptr诞生所在的那个DLL”的delete。这意思是tr1::shared_ptr会跨DLL记录指向对象的引用次数。

总结

1.好的接口很容易被正确使用，不易被误用。你应该在你的所有接口中努力达成这些性质。

2.“促进正确使用”的办法包括接口的一致性，以及与内置类型的行为兼容。

3.“阻止误用”的办法包括建立新类型、限制类型上的操作，束缚对象值，以及消除客户的资源管理责任。

4.tr1::shared_ptr支持定制型删除器（custom deleter）。这可防范DLL问题，可被用来自动解除互斥锁（mutexes,见条款14）等等。