我正在喝coolade并喜欢它 – 接口,IoC,DI,TDD等等.运作得很好.但我发现我必须努力使一切都成为一个界面！我有一个工厂,这是一个界面.它的方法返回可能是接口的对象(可能使测试更容易).这些对象是他们所需服务的DI接口.我发现保持接口与实现同步是为了增加工作 – 向类添加方法意味着将它添加到类接口,模拟等.
我是否过早考虑了接口？有什么最好的做法可以知道什么时候应该返回一个接口而不是一个对象？
当您想模拟对象与其中一个协作者之间的交互时,接口非常有用.但是,对于具有内部状态的对象,接口的值较小.
例如,假设我有一个与存储库对话的服务,以便提取某些域对象以便以某种方式操作它.
从存储库中提取接口有明确的设计价值.我对存储库的具体实现很可能与NHibernate或ActiveRecord紧密相关.通过将我的服务链接到接口,我可以清楚地分离这个实现细节.事实上,我可以为我的服务编写超快速独立单元测试,因为我可以将它交给模拟IRepository.
考虑从存储库返回的域对象以及我的服务所依赖的域对象,价值较低.当我为我的服务编写测试时,我会想要使用一个真实的域对象并检查它的状态.例如.在调用service.AddSomething()之后我想检查是否有东西被添加到域对象中.我可以通过简单检查域对象的状态来测试它.当我单独测试我的域对象时,我不需要接口,因为我只对对象执行操作并在其内部状态下进行测试.例如如果它正在睡觉,我的羊吃草是否有效？
在第一种情况下,我们对基于交互的测试感兴趣.接口有用,因为我们想拦截在测试对象和带有模拟的协作者之间传递的调用.在第二种情况下,我们对基于状态的测试感兴趣.接口在这里没有帮助.尝试意识到你是在测试状态还是交互,让它影响你的界面或没有界面决定.
请记住(如果您安装了Resharper的副本),以后提取界面非常便宜.如果您决定不需要该接口,那么删除接口并恢复到更简单的类层次结构也很便宜.我的建议是在没有接口的情况下启动,并在发现要模拟交互时按需提取它们.
当您将IoC引入图片时,我倾向于提取更多接口 – 但是要试着控制你将多少个类移到IoC容器中.通常,您希望将这些限制为基本上无状态的服务对象.
