条款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”。
最后: