【有书共读】《More Effective C++》笔记7

Rule 32  在未来时态下开发程序

1.用C++语言自己来表达设计上的约束条件，而不是用注释或文档。

   [很好的思想，但需要熟练掌握C++特性]

2.因为万物都会变化，要写能承受软件发展过程中的混乱攻击的类。

3.要使得自己的类易于被正确使用而难以误用。

4.如果一个公有基类没有虚析构函数，所有的派生类基其成员函数都不应该有析构函数。

   如果多重继承体系有许多析构函数，每个基类都应该有应该虚析构函数。

5.未来时态的考虑认为：如果一个类被设计为作一个基类使用（即使现在还没有被这么使用），它就应该有一个虚析构函数。这样的类在现在和将来都行为正确，并且当新类从它们派生时并不影响其它库用户。

 Rule 33  将非尾端类设计为抽象类

1. C++的强类型原则将评定混合类型赋值非法；然而，通过将“基类”的赋值操作设为虚函数，我们打开了混合类型操作的门。

2.在运行期使用dynamic_cast进行类型检测，这个函数复杂并且昂贵－－dynamic_cast将引用一个type_info结构。

3.绝大部分纯虚函数都没有实现，但纯虚析构函数是个特例，它们必须被实现（因为它们在派生类析构函数被调用时也将被调用），将析构函数设为“纯虚”的唯一麻烦就是必须在类的定义之外实现它。

4.从一个无数据的实体类派生新的实体类是安全的。

5.只有在设计出的类能被将来的类从它继承而不需要它作任何修改时，你才能从数据包的抽象类中获得好处。

6.当发现需求从一个实体类派生出另外一个实体类时，即表示需要通过公有继承将两个实体类联系起来，也通常表示需要一个新的抽象类。

7.非尾端类应该是抽象类；在处理外来的类库时，你可能需要违背这个规则；但对于你能控制的代码，遵守它可以提高程序的可靠性、健壮性、可读性、可扩展性。