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

先考虑下面这个接口：

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

虽然声明是比较合理的，但是有时候人们不一定会这样做，例如做下面这样调用对于客户来说也是完全可能的：

Data(2, 30, 1995);

可能只是手误打错了30和20，但是接口额使用者并不能很好的观察的这一点，看看下面对这个接口的重新设计：

struct Month{
Month(int mon):val(mon){}
int val
};
struct Day{
Month(int day):val(day){}
int val
};
struct Year{
Month(int year):val(year){}
int val
};
接口就会设计成这样：
Data(Month , Day, Year);
那么调用的时候可能就需要这样去调用：
Data(Month(month), Day(day), Year(year));

虽然看起来可能会比较繁琐，但是用户犯错误的概率也大大降低了。
（这个地方可以回过头来考虑一下第四条）

还有一个例子就是前面的13条里面的一个函数：

Investment * createInvestment();
//使用原始指针可能会使得用户饭错误的概率大大增加，这里尝试使用一个智能指针来返回更好！
shared_ptr<Investment> createInvestment()
{
...
return shared_ptr<Investment>(new Investment(tmpIvst));
}

一般，返回智能指针的话也应该给他取指定一个很好的删除器，
PS: shared_ptr有一个很好的特性即使i，他可以给每个单独的指针指定特定的删除器。这有助于避免new/delete的一种情况，对于一个指针在一个Dll中被赋值，但是另一个Dll中却被delete掉，而
对于shared_ptr就不会有这种问题，其删除器是在new的时候就指定好了的删除器，所以不会出现像上述那样的跨越Dll的new/delete情况。

小结：
1. 好的接口容易被正确使用，不易被误用
2. 取经正确使用的方法包括有接口的一致性，以及与内置类型的行为兼容
3. 组织误用的方法包括有： 建立新的类型（例如上面的struct），限制类型上的操作，束缚对象的值，以及消除客户的资源管理责任。
4. shared_ptr支持自定义删除器，这可以防范DLL问题，条款14就用这个特性来自动解除了互斥锁。