域模型中的继承与枚举属性

Question

我在工作中进行了一次关于“域模型中的继承使开发人员的生活变得复杂”的讨论。我是一名 OO 程序员，所以我开始寻找论据，证明在域模型中具有继承实际上可以减轻开发人员的生活，而不是到处进行切换。

我想看到的是：

class Animal {

}

class Cat : Animal {

}

class Dog : Animal {

}

另一位同事所说的是：

public enum AnimalType {
    Unknown,
    Cat,
    Dog
}

public class Animal {

    public AnimalType Type { get; set; }

}

我如何说服他（链接是 WELCOME ）类层次结构会比拥有此类枚举属性更好情况？

谢谢！

Answer 1

拥有一个枚举就像为所有那些开放/封闭原则是傻瓜的人举办派对。

它邀请您检查动物是否属于某种类型，然后为每种类型应用自定义逻辑。这可能会产生可怕的代码，这使得在您的系统上继续构建变得困难。

为什么？

“如果是这种类型，则执行此操作，否则执行此操作”会妨碍编写良好的代码。

每当引入新类型时，如果不处理新类型，所有这些 if 都会无效。在较大的系统中，很难找到所有这些“如果”，这最终会导致错误。

更好的方法是使用小型的、定义良好的功能接口（接口隔离原则）。

那么你将只有一个 if 而没有“else”，因为所有具体的东西都可以实现特定的功能。

比较

if (animal is ICanFly flyer)
  flyer.Sail();

看

// A bird and a fly are fundamentally different implementations
// but both can fly.
if (animal is Bird b)
   b.Sail();
else if (animal is Fly f)
   b.Sail();

？前者需要检查一次，而后者则必须对每只会飞的动物进行检查。

Answer 2

枚举适用于以下情况：

1. 值集是固定的并且从不或很少发生变化。
2. 您希望能够表示值的联合（即组合标志）。
3. 您不需要将其他状态附加到每个值。 （Java 没有这个限制。）

如果您可以用数字解决您的问题，那么枚举可能是一个不错的选择，并且类型更安全。如果您需要比上述更多的灵活性，那么枚举可能不是正确的答案。使用多态类，您可以：

1. 静态地确保所有特定于类型的行为都得到处理。例如，如果您需要所有动物都能够 Bark()，那么使用抽象 Bark() 方法创建 Animal 类将让编译器会检查每个子类是否实现了它。如果您使用枚举和大型开关，则无法确保您已处理所有情况。

2. 您可以添加新案例（示例中的动物类型）。这可以跨源文件甚至跨包边界来完成。对于枚举，一旦声明它，它就会被冻结。开放式扩展是 OOP 的主要优势之一。

值得注意的是，你同事的例子并不与你的例子直接相反。如果他希望动物的类型成为公开属性（这对某些事情很有用），您仍然可以在不使用枚举的情况下使用 类型对象模式：

public abstract class AnimalType {
    public static AnimalType Unknown { get; private set; }
    public static AnimalType Cat { get; private set; }
    public static AnimalType Dog { get; private set; }

    static AnimalType() {
        Unknown = new AnimalType("Unknown");
        Cat = new AnimalType("Cat");
        Dog = new AnimalType("Dog");
    }
}

public class Animal {
    public AnimalType Type { get; set; }
}

这为您提供了枚举的便利：您可以执行 AnimalType.Cat 并且可以获得动物的类型。但它也为您提供了类的灵活性：您可以向 AnimalType 添加字段来存储每种类型的附加数据、添加虚拟方法等。更重要的是，您可以通过创建新的动物类型来定义新的动物类型AnimalType 的实例。

Answer 3

我敦促您重新考虑：在贫血域模型中（根据上面的评论），猫行为与狗没有什么不同，因此不存在多态性。动物的类型实际上只是一个属性。很难看出继承权能在那里给你带来什么。

Answer 4

最重要的是，OOPS 意味着对现实进行建模。继承使您有机会说 Cat 是一种动物。动物不应该知道它是否是一只猫，现在对它大喊大叫，然后决定它应该喵叫而不是吠叫，封装在那里被击败。更少的代码，因为现在您不必像您所说的那样执行 If else 。

Answer 5

两种解决方案都是正确的。
您应该看看哪种技术更适合您的问题。

如果您的程序使用很少的不同对象，并且不添加新类，那么最好保留枚举。

但如果你的程序使用了很多不同的对象（不同的类），并且可能会添加新的类，那么以后最好尝试继承的方式。

Answer 6

我的推理如下：

仅当角色/类型永远不会改变时才使用继承。
例如，

对以下内容使用继承：

Fireman <- Employee <- Person 是错误的。

一旦消防员弗雷迪换工作或失业，你就必须杀死他并重新创建一个新类型的新对象，并附加所有旧的关系。

因此，解决上述问题的简单方法是为 person 类提供 JobTitle 枚举属性。
在某些情况下这已经足够了，例如，如果您不需要与角色/类型关联的非常复杂的行为。

更正确的方法是为人员类别提供角色列表。
例如，每个角色代表一个具有时间跨度的工作。

例如

freddy.Roles.Add(new Employement( employmentDate, jobTitle ));

，或者如果这太过分了：

freddy.CurrentEmployment = new Employement( employmentDate, jobTitle );

这样，弗雷迪就可以成为一名开发人员，而我们不必先杀死他。

然而，我所有的漫谈仍然没有回答你是否应该使用枚举或类型层次结构作为职位。

在纯粹的内存面向对象中，我想说在这里对职位使用继承是更正确的。

但是，如果您正在进行 O/R 映射，如果映射器尝试将每个子类型映射到新表，您最终可能会在幕后得到有点过于复杂的数据模型。
因此，在这种情况下，如果没有与类型相关的真实/复杂行为，我通常会采用枚举方法。
如果使用受到限制并且它使事情变得更容易或更简单，我可以接受“if type == JobTitles.Fireman ...”。

例如，.NET 的 Entity Framework 4 设计器只能将每个子类型映射到一个新表。当您查询数据库时，您可能会得到一个丑陋的模型或大量的连接，而没有任何真正的好处。

但是，如果类型/角色是静态的，我确实会使用继承。
例如，对于产品。

您可能有 CD <- 产品和书籍 <- 产品。
继承在这里获胜，因为在这种情况下，您很可能具有与类型关联的不同状态。
CD 可能具有多个曲目属性，而书籍可能具有多个页数属性。

简而言之，这取决于 ;-)

另外，最终您很可能会得到很多 switch 语句。
假设你想编辑一个“Product”，即使你使用继承，你也可能有这样的代码：

if (product is Book)
Response.Redicted("~/EditBook.aspx?id" + 产品.id);

因为在实体类中编码编辑书 url 会很丑陋，因为它会迫使您的业务实体了解您的网站结构等。