一个经典的Spring IOC疑难症状释疑

to:downpour

接口是为了隔离，这一点是接口给我们带来的好处，但是接口也同时带来了更多的类，这是获取好处的代价。如果说哲学问题的话，就是任何好处都是有代价的。所以前面我们讨论的是什么时候用的问题？而不是接口好不好的问题。

我觉得，你所说团队协作和使用不使用接口没有直接的关系，我写一个类，只要方法签名好了，他就可以去Mock（Mockito Jmock 或者直接子类扩展）。个人觉得说方便团队协作才引入接口是对接口本质的误解。

至于接口的本质是什么，他和类的本质区别在哪里，目前个人的理解是这样的：

接口站在程序或框架最高抽象的角度,描述实体交互关系，忽略实现细节，以便通过接口，将程序或框架的全貌勾勒出来，达到先整体后细节层层推进开发程序的目的，确保在稳定的前提下使实现拥有无限的可能。

这里以Spring框架为例来进行说明吧：Spring通过BeanFactory, ConfigurableBeanFactory等接口勾勒出了Bean创建的“蓝图”，然后通过XmlBeanFactory StaticListableBeanFactory等这些实现类以各种方式实现这“蓝图”，再如Spring定义了ApplicationContext接口，接口中描述了应用上下文的“蓝图”，而使用FileSystemXmlApplicationContext（Spring 1.0就有），AnnotationConfigApplicationContext（Spring 3.0 才有）等这些实现类，实现这个适用于不同场景下的蓝图。

针对上面的例子，我们来看Spring为什么要定义BeanFactory和ApplicationContext接口？我想至少有以下两点原因：

1）从宏观上描述了Spring这个IOC框架的“蓝图”，使框架在此蓝图下保持稳定，保证经典“开闭原则”的“闭”；

2）使Spring框架可以不断在原来精心设计的“蓝图”下，自由挥洒，不断扩展，使Spring有无限的实现可能
（FileSystemXmlApplicationContext，AnnotationConfigApplicationContext即实现了不同的上下文场景），达到证经典“开闭原则”的“开”；

这里没有涉及到任何“团队协作”的问题，而是框架扩展性和稳定性平衡的问题。所以回过头来，如果你的Service不会有多种实现，不会有多种实现场景，那么使用接口是没有任何好处的，只会增加类的数量，这违反了“简单就是最好”的原则。如果你的Service在不同的场景下拥有不同的实现（通过配置注入不同的实现），那么这时你再把它定义为接口才是适合的。

接口的使用与系统内系统外其实关系不大。接口所表达的契约原本其实并不是用于与第三方进行交互的，而是起到一个编程层次的隔离。

凡事都用接口，或者凡事都不用接口 都说明对接口存在误解，要区分什么时候用 什么时候不用需要下些功夫。