□ 繼承

    相信有為數不少的巫師對於  LPC 物件的「多重繼承」感到困惑﹐這是因為許
多 mudlib 的繼承結構十分混亂﹐而且沒有固定風格﹐因此這裡特別說明一下我們
的繼承結構所遵循的風格﹕

    「任何物件﹐可以繼承最多一個『標準物件』﹐和接著標準物件的繼承敘述之
後﹐若干個『物件特徵』。」

    其中的『物件特徵』以『標準物件』所未曾繼承過的物件特徵為限﹐換句話說
一個物件特徵不應該在任何物件中被繼承超過兩次以上。

□ 標準物件 (standard objects)

    也就是位於 /std 下的物件﹐這些物件如果加上一個適當的 create() 函數就
可以成為一個完整的物件。不過﹐無論在任何情況下﹐都不應該對一個標準物件做
clone 的動作﹐你只能繼承它。

    標準物件作為各式物件的主體﹐如果一個物件除了標準物件外沒有另外繼承任
何其他的物件特性﹐而且物件中除了 create() 之外沒有第二個函數﹐如一般的房
間、怪物、物品等﹐應該在 create() 函數結束之前﹐用 replace_program()  將
自己的程式用標準物件取代﹐因為 create() 只有在物件被創造(或 clone)出來時
執行一次﹐以後再也用不到了﹐所以乾脆用所繼承的標準物件取代﹐這樣可以省下
為數不少的記憶體。

    在某些情形下﹐一個標準物件只是另一個標準物件與一些物件特性的組合﹐其
物件本身並不定義其他的函數﹐如 npc.c﹐原因是因為我們「常常會用到這樣的組
合」﹐如果將這樣的組合定義為一個標準物件﹐就可以用前面提到的在 create()
中用  replace_program 省下不少記憶體﹐因為標準物件的程式在記憶體中只存一
份而已。

□ 物件特性 (features)

    也就是 /feature 下的物件﹐這些物件只是提供單一的屬性模組﹐是純粹用來
被繼承的物件﹐當然﹐絕對不應該去 clone 它﹐你只能繼承它。

    定義物件特性的原則是「模組化」﹐也就是說﹐要能盡量在獨立於標準物件外
的情形下工作﹐雖然完全獨立是不可能的﹐但「盡量就是」。物件特性﹐顧名思義
﹐提供的是一項特性(如 equip.c)、特殊功能(如 alias.c, more.c)、或一些相互
關連密切的函數組成的模組(如 attack.c) ﹐如果所要描述的特性具有能讓許多不
同物件使用的性質﹐應該優先把它寫成一個物件特性﹐反之﹐則把它寫成一個標準
物件。

    好了﹐看了這麼多文謅謅的定義﹐我們用一個例子來解釋「標準物件」和「物
件特性」的意義。比方說我們要寫一個能夠裝備的劍之精靈(生物)﹐用以下的繼承
方式定義﹕

    inherit NPC;        // 標準物件 NPC
    inherit F_EQUIP;    // 物件特性 「可裝備」

    聰明的你﹐到這裡應該看得出這種組合的彈性了吧﹐因為  NPC 並不具有能讓
不同物件使用的性質﹐因此我們把它寫成標準物件﹐而「可裝備」因為具有這種性
質﹐所以寫成一個物件特性﹐如果在傳統的 mudlib ﹐monster.c 與 weapon.c 都
是「標準物件」型的物件﹐就算有哪位巫師膽敢同時繼承這兩個檔案﹐後果一定相
當可怕。

    如果你細心的話﹐其實可以發現分析到最後﹐一個最基本的標準物件只是幾個
物件特性的組合﹐所謂的標準物件事實上是將一些物件特性「包裝」起來﹐所以理
想中應該「盡量避免」在標準物件中定義函數﹐但是也不必過分地硬將所有的標準
物件拆開成一些奇怪的物件特性﹐這些東西可能和遊戲系統規劃者的思考方式與個
人喜好有關﹐總而言之﹐「簡單」「合理」「富彈性」應該是設計繼承結構的主要
考量。

By Annihilator@ES2 (12-14-94)