您是否为域模型中的每个公共类定义了一个接口？优点和缺点？

Question

您是否为域模型中的每个公共类实现了一个接口？优点和缺点？

更新：如果在单独的程序集中定义了存储库接口和域模型类，如果我们不为每个域类定义接口，则不会存在循环依赖关系。

Answer 1

没有

缺点。

1. 噪音代码。
2. 更多要写。
3. YAGNI。

Answer 2

您应该为层之间的依赖关系定义接口，而不是为每个类定义接口。因此，您的服务层应该依赖于存储库接口，并且您的表示层应该依赖于服务接口。过去，没有很多硬性和快速的规则，其他的则在有意义的地方使用它们。

常识是任何优秀设计的重要组成部分。

Answer 3

通过为某个类在特定情况下播放的角色命名，可以使用接口来使代码更具表现力。单个班级可以扮演多个角色。例如，当Man与Cat交互时，Cat可能具有Pet接口，而当鼠标与Cat交互时，Cat可能具有Predator接口。

您可能会发现Mock Roles, not Objects相关且有趣的阅读。

Answer 4

没有。只接口你当时需要的东西。如果您尝试过早思考，您的代码将变得复杂且无法维护。在一段时间内，程序员将抛弃接口，因为它们很难通过所有接口来弄清楚需要什么。为了这个目的而做的任何事都会导致灾难。

Answer 5

从我的观点来看，这是过度的。只是我的2美分......

Answer 6

不，我不这样做...... 如果目前没有必要，你为什么要这样做？

如果将来结果应该是必要的（那些'应该'表示它是YAGNI），你可以执行'提取界面' - 重构。
（现代IDE让它变得非常容易）。

Answer 7

我可能会在我的下一个Asp.Net项目中这样做。

我的理由是我们当前项目需要某处存储一些与UI相关的额外状态。如果我们使用了域模型类的接口，我们就可以在用户控件代码中将实体类子类化，并替换为具有该额外状态的我们自己的类。

我知道，这看起来很脏。我希望通过会话机制获得Java的Seam框架。

Answer 8

这取决于项目的类型。如果您正在编写一个将被大量重用的API（例如Sharepoint API包装器），我会更倾向于这样做。

对于其他不会被大量重用的项目，默认情况下，我不会强调为每个公共类都设置一个接口。相反，我会专注于使用精心设计的界面链接图层。

Answer 9

从不变性的角度来看，您可以考虑在您的域对象上放置接口：

在您的代码中的大多数地方，您都希望对象是不可变的，这样您就可以保证它们不会被更改 - 在这种情况下，您将使用某种返回接口的数据访问对象，确保您的域对象不能被更改。

如果您正在编写用户最终编辑域对象的某种管理页面，则需要公开setter - 您的数据访问对象需要返回'MutableDomainObject'实例（一个类或一个类）子接口）。

话虽如此，我同意上面表达的YAGNI哲学 - 如果你现在不需要保证不变性，那么目前可能不值得投资。以后将接口分解出去应该不会太困难。