四、设计与声明
-
条款18.让接口容易被使用,不易被误用。
欲开发一个“容易被正确使用,不容易被误用”的接口,首先必须考虑客户可能做出什么样的错误。
预防客户错误的一个办法是,限制类型内什么事可做,什么事不可做。常见的限制是加上const。
另一个一般性准则“除非有好理由,否则应该尽量让你的types行为与内置types一致”。提供行为一致的接口。
- 好的接口很容易被正确使用,不容易被误用。你应该在你的所有接口中努力达成这些性质。
- “促进正确使用”的办法包括接口的一致性,以及与内置类型的行为兼容。
- “阻止误用”的办法包括建立新类型、限制类型上的操作,束缚对象值,以及消除客户的资源管理责任。
- tr1::shared_ptr支持定制删除器。这可防范DLL问题,可被用来自动解除互斥量等等。
-
条款19:设计class犹如设计type
设计一个良好的类,或者称作类型,考虑一下设计规范:
- 新类型的对象应该如何被创建和销毁?
- 对象的初始化和对象的赋值该有什么样的差别?
- 新类型的对象如果被passed by value(值传递),意味着什么?
- 什么是新类型的“合法值”?
- 你的新类型需要配合某个继承图系吗?
- 你的新类型需要什么样的转换?
- 什么样的操作符和函数对此新类型而言是合理的?
- 什么样的标准函数应该驳回?
- 谁该取用新类型的成员?
- 什么是新类型的“未声明接口”?
- 你的新类型有多少一般化?
-
你真的需要一个新类型吗?
-
条款20:宁以 pass-by-reference-to-const 替代 psss-by-value
缺省情况下C++以by value方式传递对象至函数。除非你另外指定,否则函数参数都是以实参的副本为初值,而调用端所获得的亦是返回值的一个副本。这些副本由对象的拷贝构造函数产生。
所以在以对象为by value时,可能会调用相应的构造函数(成员对象的构造、基类对象的构造),然后调用对应的析构函数。所以以by value的形式开销还是比较大的。
而pass by reference to const,没有任何构造函数或析构函数被调用,高效。声明为const是必要的,可以防止传入的参数被修改。
还可以避免对象切割问题。以上规则并不适用于内置类型,以及STL的迭代器和函数对象。对它们而言,pass by value更合适。
-
条款21:必须返回对象时,别妄想返回其reference
任何函数如果返回一个reference指向某个local对象,都会出错“无定义行为”
请记住:绝不要返回pointer或reference指向一个local stack对象,或返回reference指向一个heap-allocated对象,或返回pointer或reference指向一个local static对象而有可能同时需要多个这样的对象。
-
条款22:将成员变量声明为private
切记将成员变量声明为private。这可赋予客户访问数据的一致性、可细微划分访问控制。protected并不比public更具有封装性。
-
条款23:宁以non-member、non-friend替换member函数
这样做可以增加封装性、包裹弹性和机能扩充性
-
条款24:若所有参数皆需类型转换,请为此采用non-member函数
隐式转换。如果你需要为某个函数的所有参数(包括被this指针所指的那个隐喻参数)进行类型转换,那么这个函数必须是个non-member。
-
条款25:考虑写出一个不抛异常的swap函数
五 、实现
太快定义变量可能造成效率上的拖延;过度使用转型(cast)可能导致代码变慢又难维护;返回对象“内部数据之号码牌(handles)”可能会破坏封装并留给客人虚吊号码牌(dangling handles);未考虑异常带来的冲击则可能导致资源泄漏;过度热心地inlining可能引起代码膨胀;过度耦合可能导致让人不满意的冗长建置时间(build times)
-
条款26:尽可能延后变量定义式的出现时间
-
条款27:尽量少做转型动作
const_cast通常被用来将对象的常量性转除。
static_cast 强制隐式转换,如将non-const转换为const,int转double等,但不能将const转non-const
请记住:尽量避免转型,特别是注重效率的代码中避免dynamic_casts。
若转型是必要的,试着将它隐藏于某个函数背后,客户随后可以调用该函数,而不需将转型放进他们的代码里。
宁可:使用C++新式转型,不要使用旧式转型。
-
条款28:避免返回handles指向对象内部成分
避免返回handles(包括references、指针、迭代器)指向对象内部。遵守这个条款可增加封装性,帮助const成员函数的行为像个const,并将发生“虚吊号码牌”(handles所指的东西不存在)的可能性降至最低。
-
条款29:为“异常安全”而努力是值得的
void PrettyMenu:changeBackground(std::istream& imgSrc){
lock(&mutex); //
delete bgImage;
++imageChanges;
bgImage=new Image(ImgSrc);
unlock(&mutex)
}
从“异常安全性”看,当“new Image(imgSrc)”导致异常,对unlock的调用就不会执行,于是互斥器就拥有被把持住。造成资源泄漏
“new Image(imgSrc)”抛出异常,bgImage就指向一个已被删除的对象,而imgeChanges也已被累加,而其实新图像并没有被创建成功。所谓数据败坏
解决资源泄漏问题容易,引入Lock class类 Lock ml(&mutex) // 当函数退出时,自动析构,或者使用对象管理资源。
异常安全函数提供以下三个保证之一:
1、基本承诺:如果异常被抛出,程序内任何事情仍然保持在有效状态下。所有对象都处于一种内部前后一致的状态。
2、强烈保证:若异常抛出,程序状态不被改变。若函数调用成功,就是完全成功,若调用失败,程序恢复到调用函数之前的状态。
3、nonthrow保证,承诺绝不抛出异常,因为总是能够完成原先承诺的功能。
可能的话请提供nothrow保证,但对大部分函数而言,往往提供的是前两种保证之一。
"copy and swap"复制对象数据的副本,修改副本,在不抛出异常的函数中将副本与原件置换" 实现强烈保证。但可能耗用一定的时间和空间。当“强烈保证”不切实际时,必须提供“基本保证”。
-
条款30:透彻了解inlining的里里外外
inline函数背后的整体观念是,将“对此函数的每一个调用”都以函数本体替换。inline只适合函数体内部代码简单的函数使用。
inline函数仅仅是一个对编译器的建议,所以最后能否真正内联,看编译器的意思:
- 它如果认为函数不复杂,能在调用点展开,就会真正内联,并不是说声明了内联就会内联,声明内联只是一个建议而已。
inline 是一种“用于实现的关键字”
-
关键字inline 必须与函数实现体放在一起才能使函数成为内联,仅将inline 放在函数声明前面不起任何作用。
-
建议:inlined函数的定义必须置于头文件中。
请记住:将大多数inlining限制在小型、被频繁调用的函数身上。这可使日后的调试过程和二进制升级更容易,也可使潜在的代码膨胀问题最小化,使程序的速度提升机会最大化。
-
条款31:将文件间的编译依存关系降至最低
设计策略:
1、若使用object reference 或 object pointers可以完成任务,就不用使用objects。
2、如果能够,尽量以class声明式替换class定义式。
3、为声明式和定义式提供不同的头文件
例如:
把Person分割为两个classes,一个提供接口,另一个负责实现该接口。将负责实现的类取名PersonImpl,Person将定义如下:
main class只含一个指针成员,指向其实现类。这种设计称为pimpl idiom(pimpl 是“point to implementation”缩写),这种分离的关键在于以“声明的依存性”替换“定义的依存性”。
像Person这样使用pimpl idiom的classes,往往被称为Handle classes。
#include"Person.h" //声明接口
#include"PersonImpl.h" //定义实现接口,PersonImpl和Person有完全相同的成员函数
Person::Person(const string& name,const Date& birthday,const Address& adr)
:pImpl(new PersonImpl(name,birthday,addr))
{}
string Person::name() cosnt
{
return pImpl->name();
}
另一种制作Handle class的办法是,令Person成为特殊的抽象基类,称为Interface class。这种class的目的是详细描述继承类的接口,因此不带成员变量,也没有构造函数,只有一个virtual析构函数以及一组pure virtual函数,用来叙述整个接口。
Handles class和Interface class解除了接口和实现之间的耦合关系,降低文件间的编译依存性。
在Handle classs身上,成员函数必须通过implementation pointer取得对象数据,会为每一次访问增加一层间接性。
Interface class,由于每个函数都是virtual,每次函数调用都会有一个间接跳跃的成本。
两个都是被设计用来隐藏实现细节的函数本体,一旦脱离inline函数都无法有太大作为。