刚学习spring的时候，很多教程之类的都再说先定义interface，在写impl，然后在注入的时候有几种注入方式。但是后面项目做多了，在很多项目中却发现很多人都抛弃了interface了，觉得interface麻烦。对于interface，你们抱有什么不同的看法呢？
如果同一个功能有不同的实现，考虑到多态的话，最好还是定义interface，1、可以约定相同的方法，入参，出参。2、不同的人实现方法的时候各自逻辑不同。3、调用方可以根据不同的业务，注入不同的bean即可，代码不用变，只是注解变一下即可@Resource(name = "beanName")
所以，当项目小，开发人员少或者且开发人员水平较高且接近的情况下，可以选择不写interface，可以减少编码。
能有啥看法呢，看人吧. interface更规范，工程化，后期维护和扩展比较友好。就像是江湖中的名门正派，非interface就像是野鸡门派，没啥对错，正邪不都是看人心嘛
欢迎关注，《一行代码把服务干挂了，竟然是Docker误把库删了......》, 一起来围观吧 https://blog.csdn.net/qq_34417408/article/details/117388594?utm_source=app&app_version=4.8.0&code=app_1562916241&uLinkId=usr1mkqgl919blen
先看几个应用场景吧：
情景1：在开源框架中有很多这种情况，就是某个功能支持用户自定义扩展。说白了,它提供了一个接口，我们只需要实现这个接口，把我们自己的实现逻辑补上，就可以让框架按照我们的逻辑来执行。问题来了，框架的作者并不知道我们的实现类是什么，如果不定义一个接口，那么要如何在框架中调用我们的实现类呢?
情景2：我和同事分别做项目的2个不同功能模块，但是同事的功能中却需要调用我这头实现的部分逻辑。为了让他有一个"占位符"可用，我是不是应该快速的写个接口扔给他呢?
情景3：一个适配器功能，或是说一个简单的工厂类，如果没有定义接口，那么面对众多实现类，要如何统一操作呢?
情景4：想让项目的代码符合某种"规范"，但是又不可能看着别人写代码吧，那好办，先出一套接口，然后你们就看着办~
情景5：java中没有多继承，但是可以多实现接口，那么就有一件很有趣的事情了，一个实现类可以实现多个接口，然后此时接口可以有选择的暴露实现类的部分方法，做到"窄化"实现类功能的目的。
当然例子还有很多...这些情况其实可以说是接口好处的体现，所以java有面向接口编程的建议。
但是说回Service层一定要有接口吗？那到未必，因为说到底，多一个接口仅仅是扩展性和某些情况下有优势，但是我们是否需要或者会用到接口的这些便利性，这个不好说，在不确定的情况下我们未必一定要为"可能"买单。
但是，只是多写那几行代码，付出一点就可能避免"未来"的大"麻烦"，何乐而不为呢?