Solmyr 的小品文系列之四：物件計數（下） (轉)

Solmyr 的小品文系列之四：物件計數（下） (轉)[@more@](續上期）
“空泛的討論讓人厭煩。”，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 m_MyCounter;
};

class Zeolot : public ProtossUnit
{
??……
??Counter m_MyCounter;
};

class Dragoon : public ProtossUnit
{
??……
??Counter m_MyCounter;
};

不對！！

zero 心中劃過警兆：這感覺太熟悉了！幾乎每次慘遭 Solmyr 毒手之前，都有這種感覺！他幾乎都可以感受到 Solmyr 正在尋找順手的東西來砸他。一定有什麼地方不對了！

回過頭來看看自己寫下的東西，zero 很快的發現了自己的錯誤：Counter 和 Counter 是不同的類，它們的計數值各自獨立，而星際爭霸中各兵種佔用人口是共享的。

“既然是共享的，那麼應該加到基類裡。”，zero 急急忙忙的擦去了上面兩行程式碼，寫下：

class ProtossUnit
{
??……
??Counter m_MyCounter;
};

還 …… 還是不對！zero 立刻又發現了問題：不同的兵種可能佔用的人口數並不相同，象 Probe 就只佔用一個人口，而 Zealot 和 Dragoon 就要佔用兩個，這 …… 這 ……

zero 再度擦去了剛寫下的程式碼，站在白板之前舉棋不定。這時 Solmyr 的響了起來：“怎麼了？有困難嗎？”。此時 Solmyr 臉上的笑容顯得特別可惡。

“不，我只是不清楚星際爭霸中的人口是怎樣定義的，這個遊戲我從來沒有玩過。”，zero 試圖拖延一點時間。

“是嗎？昨天我怎麼還聽到你在討論‘星際爭霸神族戰術’？而且剛才你一下子就寫出了三個神族兵種的名稱，拼寫準確。”，Solmyr 輕易的戳破了 zero 的謊言。

“……”，zero 不由得懊惱起來。“怎麼辦？得讓它們共享一個計數器，而且每種兵種的計數值必須不一樣 …… 對了！”zero 腦中靈光一閃，寫下如下程式碼：

class Probe : public ProtossUnit
{
??……
??Counter m_MyCounter;
};

class Zeolot : public ProtossUnit
{
??……
??Counter m_MyCounter;
??Counter m_MyCounter;
};

class Dragoon : public ProtossUnit
{
??……
??Counter m_MyCounter;
??Counter m_MyCounter;
};

“Yeah！OK 了！”，zero 高興的喊道，全然不顧臺下帶著笑意的目光 —— 這樣的有趣場面已經成了公司裡的著名娛樂之一。“共享一個計數器的關鍵是用哪個類別作為模板引數！不一定非得把本身作為模板引數，完全可以用各個兵種共同的基類！”

“那計數值不是 1 呢？”

“多放幾個計數器就行了！”

“嗯，還算不錯。”

zero 很高興的看到 Solmyr 上前來在白板上打了一個勾，然而喜悅僅僅維持了一瞬間 —— Solmyr 順手又在勾上打了一個點。

“為什麼打個點？”，zero 不滿的問。

“因為你的計數器設計不佳，想象一下 Carrier ，它佔 8 個人口，你是不是要在 Carrier 類中寫 8 個 Counter 成員？或者宣告一個 Counter 的陣列？這樣的宣告清晰嗎？易讀嗎？”

“呃 ……”

“而且這樣使用 Counter 成員變數，需要計數的物件在空間上會付出更大的代價，對於小物件，大小甚至可能翻一倍。”

“嗯 ……”

“更進一步的說，計數值為 n 的物件，需要構造 n 個 Counter 物件，執行也要受影響。”

“啊 …… ”

“現在你說說看，怎麼改進你的計數器，同時不用改動原來的客戶程式碼？”

“哦 …… ”

zero 陷入了沉思：改進後的計數器應該有指定計數值的能力，這個能力應該是 …… 應該是對應於一個計數器物件而非整個計數器類的，因為共享同一個計數器的類可能計數值不同，也就是說這裡需要為計數器類的物件指定一個引數 …… 啊！原來這麼簡單！

“我知道了！答案就是構造！”，zero 飛快的把計數器類的定義改為（原來定義請參見上一期）：

template
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 的慘叫聲中結束了。