如果是像貼圖、模型、文字或音源之類單純的實體檔案資料，使用 Reference Counting 機制處理資源共享是絕對沒問題的。但我在文中所提的「物件」指的其實是「Game Object」，也就是在 physical resource 之上的那層遊戲物件。Game Object 可能是由數個不同的 base class 所架構起來的完整物件。

以 Scene Graph 架構的 OGRE 為例，當美術在 3ds Max 中製作了一段魔法攻擊的炫麗特效後，會匯出 mesh、texture、material 以及管理物件用的 osm 檔案。而遊戲程式要把這個特效檔案載入時，必須先去讀取並且解析 osm 檔案中的定義，才能夠建立起特效的 spatial data，也就是 node 與 node 之間的階層關係。問題在於遊戲如果同時需要顯示好幾份魔法攻擊特效時，雖然 mesh、texture 與 material 檔案能夠獲得資源共享的好處，但是最上層的 osm 物件卻沒有辦法達成這樣的目標。

由 osm 檔案建構出來的遊戲物件，通常是一棵完整的 node-based tree，藉由最頂端的 root node 與遊戲世界相互 attach/detach 而產生作用。在這樣的情況下，如果遊戲引擎中的 node 類別沒有提供深層複製的 Prototype 模式，等同於每次需要 osm 物件時，都必須由使用者自己重新建立出完整的遊戲物件結構（重複之前的讀取與解析 osm 檔案程序）。因此，如果能夠在 osm 物件的層面上實作出 Prototype 模式，就可以為程式設計者減輕不少負擔，也會對遊戲的效能提升產生綜效。

所以，在文章裡所指的 Prototype 應用之處，並不是在於低階的資源管理，而是在於比較高階的物件複製層面上。

以我記憶，Prototype 的適合時機是: 建立一個新物件花的資源(例如時間)，比複制並修改一個物件多。否則直接以 constructor (或 static function) 建立物件、或透過 Factory 用動態型別 (例如一個 enum parameter) 建立物件就可以。在實際應用上，好像很少機會碰到那種時機。如果以這個條件為準，本文的例子就不太適合。

反而，一個 IClonable 介面是有需要的。就是當我們真的要複製某一個物件 (而非只是 Prototype)。例如 一個通用的 Copy and Paste 機制處理不同的型別就必需要 polymorphic 的 Clone()。

關於 Clone，令我想起實作遊戲用的 Containers 時，可以 specialize 去支援一些可以 bitwise copyable 的類。例如 Vector 中，如果 Player 是可以 bitwise copyable，就可以令這個 Vector 在 resize 時直接 memcpy() 而不必續一呼叫 copy constructor。