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

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

Make interferences easy to use correctly and hard to use incorrectly.

一致性

“让types容易被正确使用，不容易被误用”，进一步表现为：

• 除非有更好的理由，否则应该尽量让我们定义的types的行为与内置的types一致。

避免无端的与内置类型不兼容，真正的理由是**为了提供行为一直的接口。**STL容器的接口就比较一直，这就使得它们非常容易被使用。例如，每个STL容器都有size函的成员函数，它会告诉调用者目前容器内的对象的个数。

如果一个接口要求使用者必须记住某些事情，就会有着“不正确使用”的倾向，因为使用者很有可能忘记做这件事。举个例子，在条款13中所说的factory函数，它会返回一个指针指向Investment继承体系内的一个动态分配的对象：

Investment* createInvestment();

为了避免资源的泄漏，createInvestment返回的指针最终必须要深处，但是在这个过程中，至少可能会出现两个错误机会：（1）没有删除指针。（2）删除同一个指针超过一次。

在条款13中提供的解决办法是将createInvestment的返回值存储在一个智能指针内，于是delete的责任就赋予了智能指针。不过，使用者如果忘记使用智能指针，则会出现问题。因此，较为理想的接口就是令factory函数返回一个智能指针：

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

因此，这实际上就是强迫使用者将返回值存储在一个tr1::shared_ptr内，因此几乎就消除了忘记删除底部Investment对象的可能性。

假设class的设计，希望“从createInvestment取得Investment*指针”，将该指针传递给一个名为getRidOfInvestment的函数，而不是直接delete。而这样设计的一个接口却会产生新的错误：

• 企图使用错误的资源析构机制。
  即使用delete替换getRidOfInvestment。

对于这个问题，一个解决办法则是：

• 返回一个“将getRidOfInvestment绑定为删除器（deleter）”的tr1::shared_ptr。

首先，在前面的条款中有讲到过，tr1::shared_ptr提供的构造函数有两个实参：

• （1）被管理的指针
• （2）引用次数变成0时被调用的“删除器”

由此可得，我们可以创建一个null tr1::shared_ptr并以getRidOfInvestment作为其删除器：

//试图创建一个null shared_ptr并携带一个自定的编译器
std::tr1::shared_ptr<Investment> pInv(0, getRidOfInvestment);
//错误的形式！无法通过编译！！

上面的代码是不能通过编译的，因为tr1::shared_ptr构造函数的第一个参数必须是个指针，而0不是指针。因此，转型（cast）可以解决这样的问题：

//正确地创建一个null shared_ptr并携带一个自定的编译器
std::tr1::shared_ptr<Investment> pInv(static_cast<Investment*>(0), getRidOfInvestment);

因此，如果我们想要实现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;
}

cross-DLL problem

另外，如果被pInv管理的原始指针（raw pointer）可以在建立pInv之前确定下来，那么“将原始指针传给pInv构造函数”比“现将pInv初始化为null在对其赋值”更好。

tr1::shared_ptr的一个优秀的性质是：

• 它会自动的使用它的“每个指针专属的删除器”

这样的性质消除了一个潜在的可能错误：

• “cross-DLL problem”

这个问题发生于“对象在动态链接库（DLL）中被创建，但却在另一个DLL内被delete销毁”。在一些平台上，这一类“跨DLL的new/delete成对运用”会导致运行期间错误。

然而tr1::shared_ptr就没有这个问题，因为它默认的删除器是来自“tr1::shared_ptr诞生所在的那个那个DLL”的delete。举个例子来说，如果Stock派生自Investment，而createInvestment的实现如下：

std::tr1::shared_ptr<Investment> createInvestment()
{
    return std::tr1::shared_ptr<Investment>(new Stock);
}

返回的那个tr1::shared_ptr可被传递给任何其他的DLLs，无需在意“cross-DLL problem”。这个指向Stock的tr1::shared_ptr会追踪记录“当Stock的引用次数变成0时该调用的那个DLL’s delete”。

最后：

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

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

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

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