(續上期）
“空泛的討論讓人厭煩。”，Solmyr 笑容可掬的說道，“不如我們設定一個簡單的場景來看看你的計數器怎么使用吧。假設你是暴雪的程序員，要為星際爭霸設計程序表示神族的單位，那么最簡單的方案是 ——”，Solmyr 停了下來，望向 zero 。
zero 松了一口氣 —— 這個問題還不算困難。他在腦中整理了一下思路：“神族的單位應該設計為一個基類，然后每種特定的兵種從這個類派生，每個單位就是這樣一個類的對象。”想到這里，他飛快的在百板上寫下：
class ProtossUnit
{
……
};
class Probe : public ProtossUnit
{
……
};
class Zealot : public ProtossUnit
{
……
};
class Dragoon : public ProtossUnit
{
……
};
Solmyr 點了點頭，接著說到：“很好。接下來，我們都知道星際爭霸里每個單位都是要占用人口的，也就是說我們得確切知道單位個數，很明顯，這是一個對象計數的應用。那么我們該怎樣利用你剛才實現的計數器呢？”
zero 順手就在白板上寫下：
class Probe : public ProtossUnit
{
……
Counter<Probe> m_MyCounter;
};
class Zeolot : public ProtossUnit
{
……
Counter<Zeolot> m_MyCounter;
};
class Dragoon : public ProtossUnit
{
……
Counter<Dragoon> m_MyCounter;
};
不對！！
zero 心中劃過警兆：這感覺太熟悉了！幾乎每次慘遭 Solmyr 毒手之前，都有這種感覺！他幾乎都可以感受到 Solmyr 正在尋找順手的東西來砸他。一定有什么地方不對了！
回過頭來看看自己寫下的東西，zero 很快的發現了自己的錯誤：Counter<Zeolot> 和 Counter<Dragoon> 是不同的類，它們的計數值各自獨立，而星際爭霸中各兵種占用人口是共享的。
“既然是共享的，那么應該加到基類里。”，zero 急急忙忙的擦去了上面兩行代碼，寫下：
class ProtossUnit
{
……
Counter<ProtossUnit> m_MyCounter;
};
還 …… 還是不對！zero 立刻又發現了問題：不同的兵種可能占用的人口數并不相同，象 Probe 就只占用一個人口，而 Zealot 和 Dragoon 就要占用兩個，這 …… 這 ……
zero 再度擦去了剛寫下的代碼，站在白板之前舉棋不定。這時 Solmyr 的聲音響了起來：“怎么了？有困難嗎？”。此時 Solmyr 臉上的笑容顯得特別可惡。
“不，我只是不清楚星際爭霸中的人口是怎樣定義的，這個游戲我從來沒有玩過。”，zero 試圖拖延一點時間。
“是嗎？昨天我怎么還聽到你在討論‘星際爭霸神族戰術’？而且剛才你一下子就寫出了三個神族兵種的名稱，拼寫準確。”，Solmyr 輕易的戳破了 zero 的謊言。
“……”，zero 不由得懊惱起來。“怎么辦？得讓它們共享一個計數器，而且每種兵種的計數值必須不一樣 …… 對了！”zero 腦中靈光一閃，寫下如下代碼：
class Probe : public ProtossUnit
{
……
Counter<ProtossUnit> m_MyCounter;
};
class Zeolot : public ProtossUnit
{
……
Counter<ProtossUnit> m_MyCounter;
Counter<ProtossUnit> m_MyCounter;
};
class Dragoon : public ProtossUnit
{
……
Counter<ProtossUnit> m_MyCounter;
Counter<ProtossUnit> m_MyCounter;
};
“Yeah！OK 了！”，zero 高興的喊道，全然不顧臺下帶著笑意的目光 —— 這樣的有趣場面已經成了公司里的著名娛樂之一。“共享一個計數器的關鍵是用哪個類別作為模板參數！不一定非得把本身作為模板參數，完全可以用各個兵種共同的基類！”
“那計數值不是 1 呢？”
“多放幾個計數器就行了！”
“嗯，還算不錯。”
zero 很高興的看到 Solmyr 上前來在白板上打了一個勾，然而喜悅僅僅維持了一瞬間 —— Solmyr 順手又在勾上打了一個點。
“為什么打個點？”，zero 不滿的問。
“因為你的計數器設計不佳，想象一下 Carrier ，它占 8 個人口，你是不是要在 Carrier 類中寫 8 個 Counter 成員？或者聲明一個 Counter 的數組？這樣的聲明清晰嗎？易讀嗎？”
“呃 ……”
“而且這樣使用 Counter 成員變量，需要計數的對象在空間上會付出更大的代價，對于小對象，大小甚至可能翻一倍。”
“嗯 ……”
“更進一步的說，計數值為 n 的對象，需要構造 n 個 Counter 對象，運行性能也要受影響。”
“啊 …… ”
“現在你說說看，怎么改進你的計數器，同時不用改動原來的客戶代碼？”
“哦 …… ”
zero 陷入了沉思：改進后的計數器應該有指定計數值的能力，這個能力應該是 …… 應該是對應于一個計數器對象而非整個計數器類的，因為共享同一個計數器的類可能計數值不同，也就是說這里需要為計數器類的對象指定一個參數 …… 啊！原來這么簡單！
“我知道了！答案就是構造函數！”，zero 飛快的把計數器類的定義改為（原來定義請參見上一期）：
template <class T>
class Counter
{
public:
Counter(int step) // 改動部分
{
m_step = step;
m_count += m_step;
};
~Counter(){ m_count -= m_step; }; // 改動部分
int GetCout(){ return m_count; };
private:
static int m_count;
int m_step; // 新加部分
};
“嗯，不錯，不過還有問題。”，Solmyr 一邊點頭一邊說，“這樣一來，以前編寫的使用 Counter 類的客戶代碼就不能編譯了 —— 它們會報告說構造的時候少了一個參數。”
“這好辦。”，zero 很快發現了自己漏掉了什么。他把構造函數的定義改為：
Counter(int step = 1)
“這樣一來，以前的客戶代碼會缺省的得到計數值 1 ，就像以前一樣。”
“嗯，表現不錯，不過 ……”
zero 心中一緊。
“算了，今天就這樣吧。”
“Yeah！”
“把今天這些討論整理成詳細文檔，下班以前交給我”
“啊！～～～～”
………………
就這樣，再一次的，故事在 zero 的慘叫聲中結束了。