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

 

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

 

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

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

1、  返回的对象的reference不允许进行delete操作。这个我是通过将析构函数设定为private函数来实现的。

2、  函数返回后，这个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，这在很多平台上会导致运行期错误。

注意：

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

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

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

4、  tr1::shared_ptr支持定制型删除器，这可防范DLL问题。可被用来自动解除互斥锁。