为域实体使用接口的目的是什么？
在我们的项目中，我们使用域实体的接口。在界面内部，只有getter和setter方法，甚至没有任何域逻辑。
对这样的实体使用接口有用吗？这是好习惯吗？
感谢。
答案 0 :(得分：4)
有很多理由说明为什么有时这是一个好主意，但它实际上取决于项目的范围。
首先：你的陈述“......甚至没有任何领域逻辑。”没有意义，接口中不能有任何逻辑，接口不能有任何逻辑，只有方法签名。
完成此操作的主要原因是支持域对象的多个实现以用于不同用途。
您可能希望将域对象编码为接口的原因：
序列化 - 有时您想要创建可序列化 您的域对象的版本，但不想混合该代码 使用您用于核心应用程序的代码。例如，你可能有 您刚才使用的Person对象的实现 为您的webapp序列化为JSON。
共享API - 您可能希望分发公共API版本 您的代码具有不同的对象实现，或者您 甚至可能只想让接口可供另一个使用 组（或客户或供应商）
支持遗留实施 - 也许你有一些数据 您需要为其构建连接器的旧数据库 用于提取数据的域对象的不同实现 进行。
测试 - 拥有核心类的接口构成单元 因为你可以快速找出你的方法，所以测试更容易 不需要测试。
答案 1 :(得分：3)
当您访问数据对象的公共实例字段时，您已经“编程收缩” - 这是您从bean获得的所有合同。访问层不会增加任何内容，更不用说另一层界面了。 Java Beans承认这样一个事实，即大量数据只是 - 数据 - 并将其封装在合同背后只会损害其实用性。 FP，可能是现存最好的编程范式，这一点是正确的。
有人可能会问（这是@pst，实际上:)，如果不同的实体实现不同的序列化策略会怎么样？如果他们在内部存储数据怎么办？也许一个人超级聪明，因为“表现”的原因而做了很多事情。
是的，我们当然可以想象一些的情况，其中实际上需要这样做，但反过来说：第一次你意识到你会这样做项目，然后你引入围绕bean的接口。你没有预先做到，因为“也许，只是也许，这个疯狂的要求将在我们的项目中间出现”。而实践清楚地表明，这几乎从未发生过。
另外，不要忘记在这样的设计中构造函数是不可能的。实施项目范围的政策，为每一个域数据编写抽象工厂 - 并且没有明确的理由 - 绝对不是人们可以称之为合理的设计选择。
答案 2 :(得分：1)
我见过一些开发人员将“代码到界面”的建议方式过分了。他们认为他们应该始终使用界面，以防它有可能在某一天派上用场。