Question

我正在我的系统中创建域模型。在设计模型对象时，我应该为每个实体对象创建接口吗？人们告诉我，我们的Web层不应该关心实体的实现，我们应该能够交换实现，但我不确定是否会发生。

例如，如果我们有一个维护学生列表的Teacher类，则getStudents方法可以是：

public List<Student> getStudents() {
      return this.students;
}

或者这个：

public List<Student> getStudents() { 
     return someExternalService.retrieveStudents();
}

我理解这个好处，但一般做法是什么？

Answer 1

除非你有充分的理由认为你需要换掉模型，否则我不会担心。基于YAGNI原则（You ain't gonna need it）

Answer 2

我见过或参与过的任何项目都没有域实体的接口。

但在我的一个项目中，我有界面NamedEntity：

public interface NamedEntity {
   int getId ();
   String getName ();
}

所有域实体都实现了此接口。它让我有可能不为不同的实体创建不同的jsf转换器，但创建了一个使用此接口而不是具体域类的转换器。

Answer 3

我不能说一般的做法，但这不仅仅是隐藏实施。

这是关于将界面正式化为文档和合同的基础。

在将模型抽象为接口时，您将为服务客户端开发人员创建文档。根据您的开发风格，您可能已经或可能没有正式的服务描述（例如，基于WSDL的描述）。接口可以满足这种需求。

Answer 4

我认为在检索对象的服务接口和模型对象本身之间存在重要区别。

在运行时，加载模型对象的服务可能因请求数据的位置而异。但无论您如何创建此对象，预期的数据对象的格式和类型都不会更改。因此，携带状态的模型对象不需要接口，但是创建和加载这些模型对象的服务类需要接口。

如果模型对象不仅仅是一个简单的bean类型的对象，而是一个暴露某种行为的对象，那么模型对象拥有接口的唯一原因是有意义的。

Answer 5

我的一般观点是，我不为域模型创建一对一的接口集，因为这除了复制域模型的类结构之外什么都不做。它没有添加任何有用的东西。

我可以立即想到的两个案例考虑引入接口：

一个接口描述了域模型中某些类的合同/行为，其中对于实现它的类的行为进行建模非常有用
您需要将您的域模型公开给外部客户端，并希望隐藏它们的实现细节

换句话说，如果它们可以帮助您描述行为或帮助您隐藏客户端的实现细节，请添加接口。其他原因可能是有效的，但这些是我想到的两个。

Answer 6

提取接口是最简单的重构之一;最糟糕的情况是它是一个类重新命名 - ＆gt;移动方法。一旦找到理由，改变主意的努力是微乎其微的。我总是发现，如果一个决定很容易改变，它会更加强化YAGNI和KISS。反驳的论点是，最初创建一个接口并不是很费力，这是正确的，但如果做出多次决定，维护会随着时间的推移而增加 - 通常不会被使用。

模型对象应该有接口吗？

6 个答案: