oop - 避免抽象类和继承

Question

考虑一下我有一个 Event 与 Invitations(每个“被邀请的人”代表一个 Invitation，所以有多个 Invitation em> 参加一个事件):

[«aggregate root»;Invitation]<>1..*-[«value object»;EventIdentifier]
[«value object»;EventIdentifier]-<>[«aggregate root»;Event]
[«value object»;Invitee|emailAddress;facebookIdentifier]-<>[«aggregate root»;Invitation]

被邀请者，然而，可以是或者电子邮件地址或 facebookIdentifier，这是业务逻辑的本质。通常我会使用 FacebookInvitee 和 EmailInvitee 创建一个 AbstractInvitee，并创建一个与摘要的关联，但我现在知道这是邪恶的。

我是否应该实际上有 FacebookInvitee 和 EmailInvitee 并且 Invitation 每个都有一个 facebookInvitee 和一个emailInvitee 属性；如有必要，一个服务或其他服务会将它们合并在一起？

感谢您的建议!

编辑

我刚刚想到了以下看起来相当整洁的想法，

[«value object»;Invitee|type;identifier]-<>[«aggregate root»;Invitation]

type 在某种程度上是 FACEBOOK 和 EMAIL 的常量，而 identifier 则是 FB UID或电子邮件地址。

Answer 1

Usually I would have made an AbstractInvitee with FacebookInvitee and EmailInvitee, and created an association to the abstract, but that's evil as I know now.

继承并没有那么邪恶。

如果您的类 FacebookInvitee 和 EmailInvitee 具有相同的接口(interface)，我认为没有理由避免继承。如果接口(interface)不同并且需要转换为具体类型，继承会增加复杂性。

The type is somehow a constant with FACEBOOK and EMAIL, and the identifier then is the FB UID or the email address respectively.

您的示例与 Replace Subclass with Fields 非常相似重构。无论如何，需要编写 if-else 代码块来检查被邀请者 type 并使用其 identifier 在某处发送邀请。谁应该为此负责？在您的解决方案中，Invitee 只是一个没有行为的 DTO。如果 Invitee 有行为并且可以 Send() 自己发出邀请，那么我将使用继承并为每个具体类(例如 FacebookInvitee)实现 Send() , 电子邮件受邀者)。