一、如无必要，勿增虚函数

乍一看觉得挺合理的，但仔细想想，其实IsKickable是某种球的本质静态属性，用一个虚函数来表示这种信息，是一种浪费，更加合理的方式应该是用一个数据成员和一个普通成员函数：

类似这样的设计我碰到过至少两次，一次是被review，一次是review，结果都是改成了第二种我们认为比较合理的方式。

二、不要用 "||" 做复杂的逻辑判断

"||"是"或运算"符号，当你确实将其作为或运算时，的确很简单明了。但是有人发明了一种比较tricky的方法来使用它。

举个例子，我们的程序可能有三种状态：A， B，或者C，现在有一个变量bOk，如果程序当前状态为C的话，bOk必须为true，如何来assert？一般比较直观的做法是：

但是有人觉得有个if判断比较麻烦，于是发明了：

我们一般不推荐用这种不直观的方式来做判断。

三、纯虚函数与默认实现

有一个基类，我们期望它是一个抽象类，但同时我们又期望其虚函数都有默认实现。这其实一个语法层面的问题：我们是可以把一个虚函数设为纯虚的同时提供默认实现的。但一开始以为不行，想去把构造函数设为pretected来达到类似的效果，但这样从概念上来讲就不是很合理了

对于这种情况，我想也没必要把所有函数设为纯虚，找一个典型，如把析构函数设为纯虚并提供默认实现：

这样，基类就已经是一个抽象类了，应该是一个可以接受的方案。