□ 继承

    相信有为数不少的巫师对於  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)
