2

为域实体使用接口的目的是什么？

在我们的项目中，我们使用域实体的接口。在接口内部，只有 getter 和 setter 方法，甚至没有任何领域逻辑。

为这样的实体使用接口有用吗？这是好习惯吗？

谢谢。

4

3 回答 3

6

有时它是一个好主意的原因有很多，但这实际上取决于项目的范围。

首先：您的陈述“......甚至没有任何领域逻辑。” 没有意义，接口中不能有任何逻辑，接口不能有任何逻辑，只有方法签名。

这样做的主要原因是为了支持不同用途的域对象的多种实现。

您可能希望将域对象编码为接口的原因：

  1. 序列化 - 有时您想要创建域对象的可序列化版本，但不想将该代码与您用于核心应用程序的代码混合在一起。例如，您可能有一个 Person 对象的实现，您只是使用它来为您的 webapp 序列化为 JSON。

  2. 共享 API - 您可能希望分发具有不同对象实现的代码的公共 API 版本，或者您甚至可能只想将接口提供给另一个组（或客户端或供应商）

  3. 支持遗留实现 - 也许您在旧数据库中有一些数据，您需要为此构建一个连接器，这涉及到您的域对象的不同实现以提取数据。

  4. 测试 - 为您的核心类提供接口使单元测试变得更加容易，因为您可以快速排除测试不需要的方法。

于 2013-02-05T19:18:20.550 回答
2
  • 我从来没有参与过发生这种事情的项目。
  • 它不是典型的设计；
  • 我从未听过或读过有人声称这是一种好习惯；
  • 我想不出这样的设计有什么好处。
  • 我能想到它造成的麻烦。

当您访问数据对象的公共实例字段时，您已经在“按合同编程”——这就是您从 bean 获得的所有合同。访问器层什么也没增加，更不用说另一层接口了。Java Beans 承认了这样一个事实，即很多数据就是这样——数据——并且将其封装在合约后面只会损害它的实用性。FP，可能是现存最好的编程范式，正确地理解了这一点。

有人可能会问（实际上是@pst :)，如果不同的实体实现不同的序列化策略会怎样？如果他们在内部以不同的方式存储数据怎么办？也许一个人是超级聪明的，并且出于“性能”的原因做了很多位玩弄。

是的，我们当然可以想象一些实际需要这样做的场景，但它反过来：首先你意识到你将做这样一个项目，然后你围绕 bean 引入接口。你不会提前做，因为“也许，只是也许，这个疯狂的需求会出现在我们项目的中间”。实践清楚地表明，这几乎不会发生。

另外，不要忘记构造函数在这样的设计中是不可能的。强制执行一个项目范围的策略来为每一个领域数据编写抽象工厂——并且没有明确的原因——绝对不是人们可以称之为合理的设计选择。

于 2013-02-05T18:55:15.410 回答
1

我见过一些开发人员将“代码到接口”的建议走得太远了。他们认为他们应该始终使用界面，以防万一有一天它会派上用场。

于 2013-02-05T19:02:21.807 回答