C++编程规范之类的设计与继承（读书笔记）

第32条　弄清所要编写的是哪种类

第33条　用小类代替巨类
摘要：小类更易于编写，更易于保证正确，测试和使用，更有可能适用于各种不同的情况。应该用小类体现简单概念，不要用大杂烩式的类，它们要实现的概念既多又复杂。

第34条　用组合代替继承
摘要：耦合性太强，应该尽量避免，因此，应该用组合代替继承，除非知道后者确实对设计有好处。
组合是指在一个类型中嵌入另一个类型的成员变量。用这种方式能够保存和使用对象，还能控制耦合强度。

第35条　避免从并非要设计成基类的类中继承
摘要：将独立类用作基类是一种严重的设计错误，应该避免。要添加行为，应该添加非成员函数而不是成员函数。要添加状态，应该使用组合而不是继承。要避免从具体的基类中继承。

第36条　优先提供抽象接口
摘要：抽象接口有助于我们集中精力保证抽象的正确性，不至于受到实现或者状态管理细节的干扰。优先采用实现了抽象接口的设计层次结构。

第37条　公用继承即可替换性。继承，不是为了重用，而是为了被重用
摘要：继承能够使基类的指针或者引用实际指向某个派生类的对象，既不会破坏代码的正确性，也不需要改变已有代码。

第38条　实施安全的改写
摘要：负责任的进行改写，改写一个虚拟函数时，应该保持可替换性，即保持基类中函数的前后条件，不要改变虚拟函数的默认参数，应该显式的将改写函数重新声明为virtual。谨防在虚拟类中隐藏重载函数。

第39条　考虑将虚拟函数声明为非公用的，将公用函数声明为非虚拟的
摘要：在基类中进行修改代码高昂，请将公用函数设为非虚拟的，应该将虚拟函数设为私有的，或者如果派生类需要调用基类版本，则设为保护的。

第40条　要避免提供隐式转换

第41条　将数据成员设为私有的，无行为的聚集（C语言形式的struct）除外

第42条　不要公开内部数据
摘要：不要过于自动自发，避免返回类所管理的内部数据的句柄，这样类的客户就不会不受控制地修改对象自己拥有的状态。

第43条　明智地使用Pimpl
摘要：抑制语言的分离欲望，c＋＋将私有成员指定为不可访问的，但并没有指定为不可见的，虽然这样自有其好处，但是可以考虑通过Pimpl惯用法使私有成员真正不可见，从而实现编译器防火墙，并提高信息隐藏度。

第44条　优先编写非成员非友元函数
非成员非友元函数通过尽量减少依赖提高了封装性。

第45条　总是一起提供new和delete

 如果定义了new则最好二个一起定义，定义了new应该也定义delete
Class T{
static void*operator new(std::size_t);
static void*operator new(std::size_t,CustomAllocator&);
static void*operator delete(std::size_t);
};

第46条　如果提供类专门的new，应该提供所有标准形式（普通、就地和不抛出）
摘要：如果类定义了operator new的重载，则应该提供operator new所有三种形式――普通(plain),就地(in-place)和不抛出(nothrow)的重载，不然类的用户就无法看到和使用它们。

static void*operator new(std::size_t);//普通
static void*operator new(std::size_t,std::nothrow_t) throw();//不抛出
static void*operator new(std::size_t,void*);//就地

第37，38，39，43条没有理解