条款18 让接口容易被正确使用,不易被误用
记住:
★“促进正确使用”的办法包括接口的一致性,以及与内置类型的行为兼容
★“阻止误用”的办法包括建立新类型、限制类型上的操作,束缚对象值,以及消除客户的资源管理责任(即类的设计者应先发制人)。
★tr1::shared_ptr支持定制型删除器。这可防范DLL问题,可被用来自动解除互斥锁等等。
--------------------------------------------------------------------------
C++的接口包括:function接口、class接口、template接口......
接口的理想情况:若客户企图使用某个接口而却没有获得他所预期的行为,应让这个代码通不过编译;若代码通过了编译,它的作为就该是客户所想要的。
a 通过导入新类型来预防接口被误用:
1 class Date { 2 public: 3 Date( int month, int day, int year ); 4 ... 5 }; 6 客户易犯错误: 7 Date d( 30, 3, 1995 ); //传递参数次序错误 8 Date d( 2, 30, 1995 ); //传递一个无效的月份或天数
可以通过导入简单的外覆类型(即建立新类型)来解决:
struct Day { explicit Day( int d ):val(d) {} //结构体中也可以使用成员初始化列表, //涨姿势了!!! int val; }; struct Month { explicit Month( int m ):val(m) {} int val; }; struct Year { explicit Year( int y ):val(y) {} int val; }; Date class改为: class Date { public: Date( const Month &m, const Day &d, const Year &y ); ... }; 使用时: Date d( Month(3), Day(30), Year(1995) );
b 通过限制对象值来预防接口被误用:
如预先定义所有有效的Months: class Month { public: static Month Jan() { return Month(1); } //返回有效月份 static Month Feb() { return Month(2); } //同上 ... private: explicit Month( int m ); //阻止生成新的月份,这是月份专属数据 }; 使用时: Date d( Month::Mar(), Day(30), Year(1995) );
c 通过限制类型上的操作来预防接口被误用:
如:常见的限制是加上const。
d 消除客户的资源管理责任(即类的设计者应先发制人):
对于如下语句:
Investment* createInvestment(); //此函数返回的是dumb ptrs
客户可将其返回值置入智能指针,因而将delete责任推给智能指针,但万一客户忘记就完了,此时应先发制人,就令上面函数返回一个智能指针:
std::tr1::shared_ptr<Investment> createInvestment() { //建立一个null shared_ptr并以getRidOfInvestment为删除器 std::tr1::shared_ptr<Investment> retVal( static_cast<Investment*>(0), getRidOfInvestment ); retVal = ...; //令retVal指向正确对象 return retVal; }
shared_ptr有个好的性质是:它会自动使用它的“每个指针专属的删除器”,因而消除另一个潜在的客户错误:cross-DLL problem。这个问题发生于“对象在DLL中被new创建,却在另一个DLL内被delete销毁”。在许多平台上,这一类“跨DLL之new/delete成对运用”会导致运行期错误。shared_ptr无这个问题,∵它缺省的删除器是来自“tr1::shared_ptr诞生所在的那个DLL”的delete。
shared_ptr比原始指针大且慢,而且使用辅助动态内存。在许多应用程序中这些额外的执行成本并不显著,然而其“降低客户错误”的成效却相当显著(意指性价比很高)。
条款19 设计class犹如设计type
记住:
★class的设计就是type的设计。在定义新的type之前,请确定你已经考虑过本条款覆盖的所有讨论主题