让接口容易被正确使用，不易被误用——effective c++学习笔记

让接口容易被正确使用，不易被误用（Make interface easy to use correctly and hard to use incorrectly.）

如果客户企图使用某个接口而却没有获得他所预期的行为，这个代码不应该通过编译；如果代码通过了编译，它的作为就是客户想要的。

这一条准则非常重要，就像我自己定义的一个垃圾回收机制，它有两个前提：

<!--[if !supportLists]-->1、 <!--[endif]-->返回的对象的reference不允许进行delete操作。这个我是通过将析构函数设定为private函数来实现的。

<!--[if !supportLists]-->2、 <!--[endif]-->函数返回后，这个reference不允许再被使用。这个目前没有限定。这个通过什么来限定？这里可以考虑使用智能指针。

许多客户端的错误可以因为引入新的类型而获得预防。

示例：

class Date

{

public :

Date(int month, int day, int year);

};

这个接口有一个问题，用户调用构造函数是可能会传入错误的参数，比如：Date(30, 3, 1982);，应该是3，30。

注：c++中构造函数失败的通知方式有两种：一是通过异常，一是通过状态位。

可以定义一个结构体：

struct Day

{

explicit Day(int d)

: val(d){}

int val;

};

进一步，month要能够反映一年有12个月这个事实。

class Month

{

public :

static Month Jan(){return Month(1);}

private:

explicit Month (int m);//防止通过其他途径生成Month

};

这样，Date可以这样调用：

Date(Month::Jan(), );

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

“另types容易被使用，不易被误用的表现形式”：除非有好理由，否则应该尽量令你的types的行为与内置的types一致。

一致性的接口更容易导致接口容易被使用。

任何接口如果要求客户必须记得做某些事情，就是有这不正确使用的倾向。

比如，如果一个接口返回一个资源，而要求这个资源必须被客户释放，则可能发生两个错误：未释放和多重释放。

可以使用智能指针消除资源泄漏的问题。

另外，tr1::shared_ptr有一个特性，就是他可以指定这个资源指针的删除器。这样就可以避免另外一个问题：“cross-DLL problem ”，这个问题发生于对象在动态链接库中被new，而在另外一个DLL种被delete，这在很多平台上会导致运行期错误。

注意：

<!--[if !supportLists]-->1、 <!--[endif]-->好的接口很容易被正确使用，不容易被误用。你应该在所有的接口中努力达成这些性质。

<!--[if !supportLists]-->2、 <!--[endif]-->“促进正确使用”的办法包括接口的一致性，以及与内置类型的行为兼容。

<!--[if !supportLists]-->3、 <!--[endif]-->阻止误用的办法包括建立新类型，限制类型上的动作，束缚对象值，以及消除客户对资源的管理责任。

<!--[if !supportLists]-->4、 <!--[endif]-->tr1::shared_ptr支持定制型删除器，这可防范DLL问题。可被用来自动解除互斥锁。