问题描述
我试图在这里表明 Admin 是 User 的一个子类，它通过开放三角形关系连接显示。这足以表明子类依赖于主父类的存在，还是我需要进一步应用组合？我在下面展示了我的例子。我对此感到非常困惑。我觉得通过专业化箭头显示它就足够了，但我不确定。
解决方法
这足以表明子类依赖于主父类的存在还是我需要进一步应用组合？
由于一般化，Admin 是 User，所以如果根本没有 User (User.allInstances()->size() = 0) 那么也没有管理员。但当然，您可以拥有 User(s) 而无需 Admin。
如果你只是想说，无非是概括是必要的。
但是如果您想表明 Admin 是 User 并且只有 1 个管理员，您可以这样做：
如您所见，admin 是 User 类的一个属性（isStatic 为真），因为它写有下划线，不需要为所有实例（包括管理员）使用它。
不使用额外关系的另一种说法是：
当然，如果您想说至少有一个管理员而不是一个管理员，只需在第一个解决方案中使用多重性 1..* 或修改约束以在第二个解决方案中使用 {allInstances()->size() >= 1}。
我想为 Bruno 关于概括的出色而准确的回答添加另一种观点。
是的，使 Admin 成为 User 的特化确实足够了：这意味着 Admin 是 User。这也意味着 Admin 继承了 User 的非私有属性和操作（即 AuthenticateUser()）。最后，它意味着 a 的实例 Admin 也是 User 的实例，因此具有 username 和密码，尽管这些仅对 {{1} } 实例。不幸的是，一旦对象创建为 User，它将始终保持为 Admin。
因此，您对作文的犹豫是完全可以理解的：通常建议prefer composition over inheritance。您可以完美地想象拥有一个具有 Admin 角色的 User，而 Admin 没有继承自 Admin。但这是一个完全不同的设计。而在这种特定情况下，如果没有其他角色，那就很奇怪了。
最后但并非最不重要的一点是，值得一提的是 de decorator pattern 可以将继承与聚合（而不是组合）结合起来：在这个设计中，您将使 User 成为 {{1} 的装饰器}：它通过Admin 责任（即附加操作）扩展了用户的责任。但这可以在运行时完成：您可以创建一个 User，添加一个 Admin 职责，或删除 User 职责。这更具动态性。