程序员小马哥
简单来说就是看情況。
主要看你项目：
- 变动情况
- 以及架构
- 人员
- 项目情况
比如，项目原来使用的hibernate，后续可能要切换为mybatis，那么dao就需要使用接口。这就不会影响上层代码的修改。
再比如，项目是个单体应用，任何代码的修改都需要重新编译整个项目，那可以不用接口。而如果项目是分模块编译部署的，那就可以使用接口解耦，假设dao有修改，只需要重新编译部署dao模块即可，不影响上层模块。
再来，如果项目组新手较多，可能简单的代码结构更适合。复杂项目结构的学习成本要高。
假如，项目进度很急，可以使用简单粗暴的方式先撸～
可以用经济学上的成本来解释原因。
经济学上的成本定义是：你做一件事，所放弃的其它事情中，价值最大的那件事的价值就是你做这件事的成本。
你使用接口的成本就是你不使用接口所花费的成本（包括后续的维护成本）。
如果项目变动多、模块部署、项目不急，那使用接口的成本就低于不使用接口的成本，虽然早期可能不用接口看起来更简单；反之，则不用接口的成本低，甚至框架都可以不使用～
毕竟工具是为了提高效率的，何必和自己过不去呢！
架构思维
你反思说明你开启智商了。我也曾问过很多程序员包括自己，为什么每写一个类都要找写一个接口，再写一个实现类Impl？竟然没有一个程序员能正确回答，大部分都竟然说老师或者书上都这么教的，而且学spring框架都这么干。前面有人也回复了接口是稳定的，实现类不稳定，经常要改。但一般代码都是你自己写的，稳不稳定自己不清楚吗？如果一定要改，连接口一起改岂不是更费劲。所以往深层次思考，连spring框架都要去质疑了。
所以我的结论是，国内的开发习惯导致了这个疑问。因为作为团队开发来讲，规范的开发习惯是先写接口和测试用例，实现类甚至会写一个伪代码以保证测试代码能正确运行。测试驱动的软件开发是一定要实现和接口分离的，从J2EE到Spring架构的演化都是遵循这个目标。
现实是一个程序员自己搞定好几层，然后没有一行测试代码。这种情况下每个类都写一个接口再写一个实现类，岂不是画蛇添足吗！
这是我的见解，欢迎拍砖。
Shooray
我刚开始也是很随意，service偶尔用，直到有一次，表增加一个字段，调用处都得改，几十个地方调用，就问你绝不绝望？
SAni
用接口是为了以后换业务逻辑和数据访问方便维护和扩展。这是面向对象的编程思想-多态。
刚开始写的时候，你会感觉会多写了一个接口文件，没什么用。但是当你代码越来越多时，如果你调用的不是接口，而是具体的类。需要更改时，你只能有两种做法，一是重构所有调用代码里的类名，二是选择直接修改原有的service或dao。在项目复杂的情况下这两种做法都更容易出错。你可以想象一下如果有1000个方法调用某个dao的class，当你需要把dao从mysql换到oracle的时候，你需要改1000个方法里的调用的类名。
如果你调用的地方是接口，那无需改方法里对象变量的类型。你只需要写新的service或dao的impl，亦或者新的service和dao继承旧的，只重写部分方法。用的时候只需要通过注入就可以让所有调用service或dao的接口使用新的实现类或方法。
saizone
这是必须的，我们的开发手册中不允许出现Service层中方法是非实现接口的方法。
在DAO层中，如果是采用Mybatis3.0以上，本身我们编写的方法都是基于接口的，所以不存在这个问题。
在Service层中，我们为了代码规范、方法复用，我们必须定义接口。举个简单的例子：
我们一个业务系统中可能有多个业务模块都有CRUD的方法，那我们是要在每个Service接口的方法中定义add、get、update等CRUD的方法吗？当然不是。我们只要定义一个接口，接口中定义好这些方法，相应的业务类去实现这些接口就行，然后在各自的实现类去实现这些接口即可。
所以说，为了代码规范和接口复用，我们需要定义接口。
阿迈达聊技术
如果是直接对外提供的接口，那加上接口层是很有必要的。在实际中写代码的过程中，比如说这个service是提供出去的rpc接口，如果没有接口的话。 以后非常难扩展，毕竟接口有多实现的机制。
如果是自己内部的调用的话，就没有必要写接口层了，写了也许会增加代码的复杂性。我们内部做到类的单一职业性最好。
程序猿小劲
接口不是为了替换实现。如果从mysql改成Oracle，只要把方法内容改变即可。不改变方法声明就行。做接口，是为了共存。接口往往都会和工厂模式一起用。比如，发送代办，可以做一个send的接口。这样可以有多个实现类。比如短信，邮件，微信，钉钉等。至于service和dao是否需要接口，我觉得如果是做产品，则需要接口。定制时，只要通过继承原实现类并重写方法实现。否则定制只能通过修改源代码实现。至于修改了某个类的方法导致1000个调用了此方法的类要重编译，那要看是否修改了方法声明。即便使用接口，接口申明改了也要全部编译的。只要不是产品，或者通用组件，纯业务上的service和dao没有太大必要使用接口。日志，代办，消息等通用服务组件上使用接口还是有必要的。当然使用了接口，在转变为微服务上，成本会小很多。通过接口代理，可以实现该业务实现类在不同的架构上的重用。
lsong98sh
其实这是以前JAVAEE标准提倡的，后来大家就跟着弄了。在实际中确实大多数项目一个接口只有一个实现，如果觉得不需要用接口去切换实现的bean就不用加呗。但是现在仍然提倡面向接口编程，这个观念是没错的。
这个本质上就是一种设计模式，需要用就用，不需要就不用。
NovRain61
用UserDao来举例子吧！
在是service中要调用userDao我们怎么调用的呢？是不是@Autowirte UserDao userDao 这样的吧？这样其实并没有在调用的代码中用到实现类，所以我可以随时更换实现类，更换实现类而不用去修改调用的地方，这个才是用接口最关键的地方吧！
灿烂深空
接口分离原则(ISP)，是面向对象方法学一个非常重要的原则，接口是稳定的，接口的具体实现是易变的，上层组件不要直接依赖于下层组件，而是要上层组件和下层组件通过接口实现依赖，上层组件以聚合关联接口，下层组件以泛化实现接口，从而实现面向对象方法学的另一个重要原则——依赖反转原则（DIP），这样下层组件的改变不会影响上层组件。只对接口编程，不要对具体实现编程。比如下层DAO使用的ORM由hibernate换成mybatis，上层Service组件不变；再比如JDBC编程都是以接口方式进行，而数据库的变化和JDBC驱动的变化不会影响我们的上层代码。
