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

总结:

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

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

3、预防错误的方法包括创建新的类型,限定类型的操作,约束对象的值,以及消除客户的资源管理职责。

4、tr1::shared_ptr 支持自定义 deleter。这可以防止 cross-DLL 问题,能用于自动解锁互斥体(mutex)等。


        C++ 被淹没于接口中。函数接口、类接口、模板接口。每一个接口都是客户与你的代码互动的手段。在理想情况下,如果使用某个接口而没有得到预期的行为,这个代码不该编译通过,反过来,如果代码可以编译,那么它做的就是客户想要的。

         开发易于正确使用,而难以错误使用的接口需要你考虑客户可能造成的各种错误。例如,假设你正在设计一个用来表现日期的类的构造函数:

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

        客户可能很容易地造成以错误顺序传递参数或传递非法日期的错误:

Date d(30, 3, 1995); // Oops! Should be"3, 30" , not "30, 3"

Date d(2, 20, 1995); // Oops! Should be"3, 30" , not "2, 20"

        很多客户错误都可以通过引入新类型来预防。确实,类型系统是你阻止那些不合适的代码通过编译的主要支持者。我们可以 引入简单的外覆类型来区别日,月和年,并将这些类型用于 Data 的构造函数

struct Day { //Month和Year与之类似
explicit Day(int d) :val(d) {} :

    intval;
};

class Date {
public:
   Date(const Month& m, const Day& d, const Year& y);
   ...
};
Date d(30, 3, 1995); // error! wrong types
Date d(Day(30), Month(3), Year(1995)); //error! wrong types
Date d(Month(3), Day(30), Year(1995)); //okay, types are correct


        一旦放置了正确的类型,限制其值有时候是通情达理的。例如,月仅有12个合法值,所以 Month 类型应该反映这一点。方法之一是用一个枚举来表现月,但是枚举不具备类型安全性。例如枚举能被作为整数使用。一个安全的解决方案是预先确定合法的 Month 的集合:
class Month {
public:
    static Month Jan() { return Month(1); } // 函数而非对象,返回有效月份
    static Month Feb() { return Month(2); }
    ...
    static Month Dec() { return Month(12); }

    ... // 其它成员函数

private:
    explicit Month(int m); // 阻止生成新的月份,这是月份专属数据
    ...
};
Date d(Month::Mar(), Day(30), Year(1995));

        防止可能的客户错误的另一个方法是限制类型内能够做的事情,常见的限制是加上const。实际上,除非你有很棒的理由,否则就让你的类型行为与内置类型保持一致。客户已经知道像 int 这样的类型如何表现,所以你应该努力使你的类型在合理的前提下有同样的表现。例如,如果 a 和 b 是 int,给 a*b 赋值是非法的。

        避免无端和内置类型不相容的真正原因是为了提供行为一致的接口。很少有特性比一致性更易于引出易于使用的接口,也很少有特性比不一致性更易于加剧接口的恶化。STL容器的接口在很大程度上(虽然并不完美)是一致的,而这使得它们相当易于使用。例如,每一种 STL 容器都有一个名为size的成员函数可以知道容器中有多少对象。与此对比的是 Java,在那里你对数组使用length属性,对String使用length方法,而对List却要使用size方法,在 .NET 中,Array有一个名为Length的属性,而ArrayList却有一个名为Count的属性。一些开发人员认为集成开发环境(IDEs)能补偿这些琐细的矛盾,但他们错了。矛盾在开发者工作中强加的精神折磨是任何IDE都无法完全消除的。


        任何一个要求客户记住某些事情的接口都是有错误使用倾向的,因为客户可能忘记做那些事情。例如,条款13介绍的factory函数,它返回一个指向动态分配的 Investment 继承体系中的对象的指针。

Investment* createInvestment(); 

        为了避免资源泄漏,createInvestment返回的指针最后必须被删除,但这就为至少两种类型错误创造了机会:删除指针失败,或删除同一个指针一次以上

        你可以将createInvestment的返回值存入一个类似auto_ptr 或tr1::shared_ptr 智能指针,从而将使用delete的职责交给智能指针,但仍忘记使用智能指针,不如让factory函数在第一现场即返回一个智能指针:

std::tr1::shared_ptr<Investment>createInvestment();
        这就从根本上强制客户将返回值存入一个tr1::shared_ptr,几乎完全消除了当底层的 Investment 对象不再使用的时候忘记删除的可能性。


        假设从 createInvestment得到一个Investment*指针的客户期望将这个指针传给一个名为getRidOfInvestment的函数,而不是对它使用delete。tr1::shared_ptr 提供了一个需要两个参数(被管理的指针、当引用计数变为零时要调用的deleter)的构造函数。这启发我们创建一个以getRidOfInvestment 为deleter的null tr1::shared_ptr的方法:
std::tr1::shared_ptr<Investment> pInv(0,getRidOfInvestment); 
         这不会通过编译。tr1::shared_ptr的构造函数坚决要求它的第一个参数应该是一个指针,而0不是一个指针,它是一个int。当然,它能转型为一个指针,但那在当前情况下并不够好,tr1::shared_ptr坚决要求一个真正的指针。用强制转型解决这个问题,因此createInvestment的实现代码看起来是这样:

std::tr1::shared_ptr<Investment>createInvestment()
{
    std::tr1::shared_ptr<Investment> retVal(static_cast<Investment*>(0),
    getRidOfInvestment);
    retVal =... ; // 令retVal指向正确对象
    returnretVal;
}
        tr1::shared_ptr的一个特别好的特性是它自动逐指针地使用deleter以消除另一种潜在的客户错误——“cross-DLL问题。”这个问题发生在:一个对象在一个动态链接库(dynamicallylinked library (DLL))中通过 new 被创建,在另一个不同的 DLL中被删除。在许多平台上,这样的cross-DLL new/delete 对会引起运行时错误。tr1::shared_ptr 可以避免这个问题,因为它缺省的deleter只将 delete用于这个tr1::shared_ptr被创建的 DLL 中。这就意味着,例如,如果 Stock 是一个继承自 Investment 的类,而且 createInvestment 被实现如下,
std::tr1::shared_ptr<Investment>createInvestment()
{return std::tr1::shared_ptr<Investment>(new Stock);}

         返回的tr1::shared_ptr能在DLL之间进行传递,而不必关心cross-DLL问题。指向这个 Stock 的 tr1::shared_ptr 将保持对“当这个 Stock 的引用计数变为零的时候,哪一个 DLL 的delete应该被使用”的跟踪。

         tr1::shared_ptr是一个消除某些客户错误的简单方法,值得我们核计其使用成本。最通用的 tr1::shared_ptr 实现来自于 Boost,其shared_ptr的大小是原始指针的两倍,以动态分配内存用于簿记用途和deleter专属数据,当调用它的deleter时使用一个virtual函数来调用,并在多线程程序修改引用次数时蒙受线程同步化的额外开销(你可以通过定义一个预处理符号来使多线程支持失效。)。在缺点方面,它比一个原始指针大且慢,而且要使用辅助动态内存。在许多应用程序中,这些附加的运行时开销并不显著,而对客户错误的减少却是每一个人都看得见的。




评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值