□ 继承

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