UML类图与关系解读：泛化、聚合及抽象类相关疑问

• 问题1：Person是父类，ProjectEmployee是子类，那是否表示Person同时也是ProjectEmployee？
  不对，泛化关系是「is a kind of」的特化关系，正确的逻辑是：所有ProjectEmployee都是Person，但并非所有Person都是ProjectEmployee。Person作为父类是更通用的概念，子类ProjectEmployee是它的具体分支——比如现实中Person可以是学生、自由职业者，这些都不属于ProjectEmployee范畴，不能混淆泛化的方向。

• 问题2：ProjectEmployee与ProjectTeam存在聚合关系，这是否意味着Person始终属于某个ProjectTeam？
  完全不是。聚合是一种松散的「整体-部分」关联，部分可以独立于整体存在。首先，只有ProjectEmployee和ProjectTeam有聚合关系，Person作为上层通用类，它的实例（比如非项目员工的普通Person）根本不需要归属任何ProjectTeam；其次，就算是ProjectEmployee，聚合关系也允许它暂时不隶属于任何团队（比如刚入职还未分配项目的状态）。

• 问题3：将Person设为抽象类是否更合适？
  这取决于业务场景：

  • 如果你的系统中不会存在单纯的Person实例——所有Person都必须是某个子类（比如ProjectEmployee、Student、Customer）的具体实现，那把Person设为抽象类就非常合适，它可以作为所有子类的通用模板，同时强制只能实例化子类，符合业务逻辑。
  • 如果系统允许存在不归属任何子类的Person（比如仅记录基础信息的普通联系人），那Person就应该是普通类，允许直接实例化。

内容的提问来源于stack exchange，提问作者Kees Lasser