Go-ForIt 记事：eXtreme DragonSlayers 专题报告，第 9 部分: 避开继承的高“税收”

核心提示： 图 1. 用户类型不宜使用继承的情况在这里使用继承时最讨厌的是 ― 一个用户的所有信息都要根据用户注册时或更新过他们的用户信息后所做出的选择，用 3 个类其中一个的实例来表示，Go-ForIt 记事：eXtreme DragonSlayers 专题报告，第 9 部分: 避开继承的高“税收”(2)

图 1. 用户类型

不宜使用继承的情况

在这里使用继承时最讨厌的是 ― 一个用户的所有信息都要根据用户注册时或更新过他们的用户信息后所做出的选择，用 3 个类其中一个的实例来表示。比较麻烦的副作用是如果一个用户发生类型切换，那么必须删除前一种类型对应的实例所表示的“全部”用户信息，并将它们作为用户新类型对应的 EJB 的新实例重新创建。在一个用户从作为 PA 切换到同时兼任 PA 和“顾客”的示例中，只要求添加新的特定于“顾客”的信息，而其它信息（特定于 PA 的信息和特定于“用户”的信息）保持不变。

继承的另一个缺点是随着不同 user 类的数量的增加，各种组合也变得数目众多，维护起来越发困难。 例如，我们可以为那些拥有某类责任保险的 PA 引入一个名为 BondedPersonalAssistant 的 user 类。如果我们假设这份保险只覆盖 PA 能够执行的差事的子集，这样用户可以随时扮演一个“有担保 PA”（Bonded PA）或一个 PA，那么最后我们会得到一个拥有 7 种可能的子类组合的模型。尽管这种推理只是对将来的一种预测，我们与“用户情景”的作者的会话 ― 当然，是非正式的 ― 却使我们相信不同类型的用户很有可能出现在“用户情景”的下一步里。

继承看起来好像更适合这样一种环境：其中各种用户类型互斥，用户可以是一个“顾客”或一个 PA，但不可以 兼任两者，而且用户无法将自己随意变为其它用户类型。