一、如無必要，勿增虛函數
比如我們有以下關於球的類層次設計 ,其中需要判斷某種球是否是可以踢的(kickable):
乍一看覺得挺合理的，但仔細想想，其實IsKickable是某種球的本質靜態屬性，用一個虛函數來表示這種信息，是一種浪費，更加合理的方式應該是用一個數據成員和一個普通成員函數：
類似這樣的設計我碰到過至少兩次，一次是被review，一次是review，結果都是改成了第二種我們認為比較合理的方式。
二、不要用 "||" 做復雜的邏輯判斷
"||"是"或運算"符號，當你確實將其作為或運算時，的確很簡單明了。但是有人發明了一種比較tricky的方法來使用它。
舉個例子，我們的程序可能有三種狀態：A, B，或者C，現在有一個變量bOk，如果程序當前狀態為C的話，bOk必須為true，如何來assert?一般比較直觀的做法是：
但是有人覺得有個if判斷比較麻煩，於是發明了：
邏輯理解為：如果不是A也不是B，那麼bOk必須為true。雖然代碼簡化成只有單個語句，但是，這對理解卻帶來了挑戰。
我們一般不推薦用這種不直觀的方式來做判斷。
三、純虛函數與默認實現
有一個基類，我們期望它是一個抽象類，但同時我們又期望其虛函數都有默認實現。這其實一個語法層面的問題：我們是可以把一個虛函數設為純虛的同時提供默認實現的。(但一開始以為不行，想去把構造函數設為pretected來達到類似的效果，但這樣從概念上來講就不是很合理了)
對於這種情況，我想也沒必要把所有函數設為純虛，找一個典型，如把析構函數設為純虛並提供默認實現：
這樣，基類就已經是一個抽象類了，應該是一個可以接受的方案。
