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