通过枚举属性而不是使用 GetType() 来识别对象类型是一种不好的做法吗？

Question

我有一组对象，它们都实现一个（自定义）接口：IAuditEvent。

每个对象都可以存储在数据库中，并且每个对象类型都使用唯一的数字 ID。

存储对象的方法围绕 List 循环，因此它需要知道每个对象的具体类型才能存储正确的数字 id。

在 IAuditEvent 上拥有枚举属性以便每个对象都可以使用唯一的枚举值来标识其类型，这种做法是否不好？

我可以看到最简单的解决方案是编写将 Type 转换为整数的方法，但是如果我需要出于其他目的枚举审核事件怎么办？将我的枚举属性放在 IAuditEvent 上是否仍然是错误的？

Answer 1

该数据库类型 ID（或鉴别器）本质上是每种类型的元数据。在每个实例上混合数据和元数据并不是很好。我的首选解决方案是编写一个自定义属性来保存此元数据，将其应用于每种类型，并使用 Type 的 GetCustomAttributes 方法读取这些元数据。

[DatabaseDiscriminator(123)]
public class MyAuditEvent : IAuditEvent
{
}

Answer 2

是的，这很糟糕。您现在假设 IAudit 的每个实现都知道其他实现，因为它们都应该有一个唯一的 ID；此外，您需要为接口的每个新实例添加一个新值到enum。这只是应用程序内部不需要的额外信息，仅在数据表示中需要。

而是在您的业务层中有一个查找表：

new Dictionary<Type, int> {
    { typeof(UserAudit), 1 },
    { typeof(OrderAudit), 2 }
}

Answer 3

简短的回答：这取决于。

记住接口的用途。它们的全部目的是向界面用户隐藏实现。当谈到接口时，我看到两种类型的代码：

使用接口的代码。这段代码应该只知道 IAuditEvent，而不是它的实现类。如果此代码需要了解不同类型的审核事件（我的意思是最一般意义上的“类型”，而不是具体的类），那么我认为向 IAuditEvent 添加 Type 属性是一个很好的做法。就用户而言，甚至不需要为每种类型提供不同的实现。

另一种类型的代码是实现接口的代码，我的意思不仅是从 IAuditEvent 继承的类，还包括构造并直接使用这些实现的类。如果这个并且只有这个代码需要知道它正在处理什么类型的IAuditEvent（这里我指的是类中的类型），那么我会说添加 Type 属性是不好的做法，因为它暴露了实现的一些部分。这段代码也可以做一个instanceof 检查。

Answer 4

实现接口的目的是抽象实现 - 只要您使用接口并且不关心实现类型，因此不需要用枚举值来标识它。

话虽如此，我要做的方法是拥有一个公共基类型，它既实现接口又具有返回枚举的抽象属性：

public abstract class BaseType : IAuditEvent
{
    public abstract MyTypeEnum TypeId { get; }

    ... add any base implementation of the interface ...
}

然后在每个派生对象中：

public class MyConcreteType : BaseType 
{
    public MyTypeEnum TypeId { get { return MyTypeEnum.SpecificValue; } }

    ... any overrides, etc ....
}

这种方法有几个优点

• ：保持你的代码干净。当在多个类中实现接口时，很可能会有一些不同对象可以共享的接口的通用实现，这些实现可以放在基类中。明智地使用抽象和虚拟方法/属性。

• 使用枚举来标识对象可以帮助避免那些无休止且乏味的 if (myObj.GetType() == typeof(ObjectA)) {} else if (myObject.GetType() == typeof(ObjectB) )... 语句，当需要根据实现者的类型进行分支时 - 现在您只需使用基于 TypeId 属性返回的枚举的 switch 语句

  ，

如果您添加更多实现，您仍然会遇到必须扩展枚举的问题，但那就是一个相对简单的代码更改，并且如果要添加更多实现，则无论如何都必须重新编译（因此扩展枚举并不是什么大问题，但如果可能的话，您确实希望避免更改已分配的值）。