界面精神错乱

Question

我正在喝冷却器，喜欢它-接口，IoC，DI，TDD等等。但我发现我必须与一种使一切都成为界面的倾向作斗争！我有一家工厂，它是一个接口。它的方法返回对象，这些对象可以是接口(可能使测试更容易)。这些对象是到它们所需服务的DI‘’ed接口。我发现，使接口与实现保持同步是对工作的添加--向类添加方法意味着将其添加到类+接口、模拟等。

我是否过早地将接口考虑在内？是否有最佳实践可以知道什么时候应该返回接口和对象？

Answer 1

当您想要模拟对象与其协作者之间的交互时，接口非常有用。但是，对于具有内部状态的对象，接口中的值较少。

例如，假设我有一个与存储库对话的服务，以便提取某个域对象，以便以某种方式对其进行操作。

从存储库中提取接口有一定的设计价值。我对存储库的具体实现很可能与NHibernate或ActiveRecord有很强的链接。通过将我的服务链接到接口，我可以从这个实现细节中得到一个清晰的分离。碰巧我还可以为我的服务编写超级快的独立单元测试，现在我可以给它一个模拟的IRepository。

考虑到从存储库返回的域对象，以及我的服务所依赖的域对象，值就会减少。当我为我的服务编写测试时，我想要使用一个真实的域对象并检查它的状态。例如，在调用service.AddSomething()之后，我想检查某个内容是否添加到域对象中。我可以通过简单地检查域对象的状态来测试这一点。当我孤立地测试我的域对象时，我不需要接口，因为我只打算对对象执行操作，并测试它的内部状态。我的羊睡觉时吃草有效吗？

在第一种情况下，我们对基于交互的测试感兴趣。接口是有用的，因为我们想拦截在被测试对象和它的协作者之间传递的调用。在第二种情况下，我们感兴趣的是基于状态的测试。接口在这里帮不上忙。试着意识到你是在测试状态还是交互，让它影响你的界面或者没有界面决定。

请记住(如果您安装了Resharper的副本)，稍后提取一个接口是非常便宜的。如果您最终决定不需要接口，那么删除接口并恢复到更简单的类层次结构也是很便宜的。我的建议是在没有接口的情况下开始，当您发现想要模拟交互时，按需提取它们。

当您将IoC引入到图片中时，我将倾向于提取更多的接口--但请尝试限制您将多少类插入到IoC容器中。通常，您希望将这些限制限制在基本无状态的服务对象上。

Answer 2

听起来你有点受BDUF的影响了。

把冷却器放轻松，让它自然流动。

Answer 3

记住，虽然灵活性是一个有价值的目标，但是使用IoC和DI增加灵活性(在某种程度上这是TDD的需求)也增加了复杂性。灵活性的唯一要点是使下游的变化更快、更便宜或更好。每一个IoC/DI点都会增加复杂性，从而使其他地方的变化变得更加困难。

实际上，在这里，您需要一个“大设计前沿”( Big )来某些范围:确定哪些领域最有可能发生变化(和/或需要进行广泛的单元测试)，并计划那里的灵活性。重构以消除不太可能发生变化的灵活性。

现在，我并不是说你可以用任何精确性来猜测哪里需要灵活性。你会错的。但很可能你会得到一些正确的东西。如果您稍后发现您不需要灵活性，则可以在维护中考虑到它。在您需要它的地方，可以在添加特性时考虑到它。

现在，可能改变或不改变的领域取决于您的业务问题和IT环境。这里有一些反复出现的区域。

1. 我总是认为集成到其他系统的外部接口是高度可变的。
2. 无论什么代码为用户界面提供后端，都需要支持UI中的更改。但是，主要是为功能的改变做计划:不要过度使用不同的UI技术(例如支持智能客户端和web应用程序-使用模式会有太大的差异)。
3. 另一方面，将可移植性编码到不同的数据库和平台是通常是浪费时间，至少在公司环境中是这样。问一问，并检查哪些计划可能存在，以取代或升级技术在您的软件的可能寿命。
4. 对数据内容和格式的更改是一项棘手的工作:虽然数据偶尔会发生变化，但我看到的大多数设计处理这些更改都很糟糕，因此可以直接使用具体的实体类。

但只有你才能判断哪些东西可能或不应该改变。