Effective C++笔记（二）_尽量以定义是替代声明-CSDN博客

本文链接：https://blog.csdn.net/Aaron_M/article/details/105083303

四、设计与声明

条款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函数，用来叙述整个接口。