第六章，杂项讨论

32-在未来时态下发展程序

考虑程序未来可能发生改变的点，思考虚函数的真正含义，决定要不要定义为虚函数。

设计classes，使用防止编译通过的设计来规避错误的使用，而不是写注释那样缺乏防范性的做法。（以C++本身来表现各种规范）

为每一个class处理assignment和copy construction动作，即使没有人使用那样的动作。

让classes的操作符和函数拥有自然的语法和直观的语义。和内建类型的行为保持一致，参考ints的表现。

只要能编译通过的代码就会有人写出来（now: 也许是AI）,接受使用者会犯错的事实，设计classes，让classes更加容易被正确使用。

努力写出可移植性代码（如果是AI，则同样要求它），即使定制型硬件的程序，通常也可能被要求移植到其他硬件系统。前期所做的可移植性努力会让平台切换要做的工作事半功倍。

设计代码，使得“系统改变带来的冲击”得以局部化。尽可能采用封装性质，尽可能让实现细目(细节)成为private。

尽量避免设计出virtual base classes，因为这种classes必须被每一个deriver class初始化。

未来时态下开发程序：我们不问自己，class此刻如何被使用，我们问的是这个class被设计作为什么用途。

如果class被设计作为一共base class（即使现在不是），它就应该拥有一个virtual destrcutor。

现在式思维有其必要，比如软件需要“很快”上市。未来式思维更多是带来一些额外的考虑：

1、提供完整的classes，即使目前用不到，当新的需求进来，不需要回头去修改classes。

2、设计接口，使其利于共同的操作行为，阻止共同的错误。让classes可以轻易的被正确引用，难以错误使用。比如copying和assignment并不合理的classes，就禁止这些动作的发生。

3、尽量使代码一般化（泛化），除非有不良的巨大后果。例如，设计的算法用于树状结构来回遍历，考虑将其一般化，以便能够处理任何种类的directed acyclic graph（有向无环图）

“未来式思维”可增加代码重用性、加强可维护性、使它更健壮。 并促使在一共“改变实乃必然”的环境中有着优雅的改变。