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

介绍

在 Go-ForIt 用户情景中，有一个要求是每个用户可以是一个请求差事服务的“顾客” 、一个为顾客执行差事的“私人助理”（Personal Assistant（PA）），或兼任两者。还有一个要求是用户可以随时更改他们的注册信息 ― 这样，一个突然想执行差事的“顾客”既可以在他／她的简档中将自己更改为一个“顾客” 又可以更改为一个 PA。根据这些选择，Go-ForIt 用户得到一个显示他们可以采取的行动的菜单。例如，如果一个用户只是一个“顾客”，那么他将只看到顾客可以采取的行动，比如“请求一个差事”。

对于 Go-ForIt 开发者，这意味着用户将随时扮演这两个角色的其中一个：“顾客”或 PA。

理解要求

每种类型的用户都会要求维护特定的持久性信息，还有一些所有的用户都要求维护的持久性信息（比如用户标识和密码）。我们在前面已决定使用 Enterprise JavaBean（EJB）技术维护持久性信息，特别情况下“实体 Bean”（Entity Bean）使用容器管理持久性。由于开发者使用的是 VisualAge for Java 中的“EJB 开发环境”（EJB Development Environment），这种环境支持 EJB 继承，他们会考虑一种捕获各种用户类型之间关系中的“某种” 内在关系的类层次结构。也就是，一个“顾客”是“一种”用户，一个 PA 也是“一种” 用户，从表面上看来这很自然地适合反映那些关系的继承层次结构的类型。

由于“顾客”和 PA 的角色不互相排斥（一个 Go-ForIt 用户可以兼任两者），下图看起来好象是 Go-ForIt 用户情景要求的一个合理模型。