j2ee项目里面service层里面为啥要建立一个接口，一个实现类

Posted 2023-04-05

例如用户注册程序：service层里面要先建立一个接口UserService.java，还要建立一个实现类UserServiceImpl.java。这样有啥好处？而不是直接用一个实现类UserServiceImpl.java。希望知道的能详细描述下！

主要是实现松耦合，降低各个模块间的关联，
实现分层，使各个层之间更清楚职责。
不建立接口也能用，但是建立接口使程序更加灵活 他除了在规范上有卓越贡献外 最精髓的是在多态上的运用。 继承只能单一继承 接口却可以多实现 参考技术A 说简单点
第一种方式：建立个接口
第二种方式：直接实例化
第一种：比如你用Spring框架，可以在用到UserServiceImpl的时候定义接口，最后使用XML方式实例化，这样以后需要修改，只要改xml(所谓的低耦合)
第二种：假设你直接在java文件中直接实例化，万一你不在用这个类了，要用另外的类来代替，需要改java文件，很麻烦（即所谓的耦合度高）
耦合度低的程序要好
现在你可能接触不到，但是使用接口的编程方式对以后的开发非常有帮助，别人看着也高端。 参考技术B 接口可以将程序逻辑层次化，松耦合，多种实现。
另外，更重要的是，接口提供公共调用，实现类封装具体操作，安全性，共享性等，都是很有必要的。
通常实际项目会把基本的所有公共的ADES增删改查全部抽象成一个DBDao接口和一个实现类DBDaoImpl。然后所有Service类同时调用。

j2ee项目里面service层里面为啥要建立一个接口，一个实现类

例如用户注册程序：service层里面要先建立一个接口UserService.java，还要建立一个实现类UserServiceImpl.java。这样有啥好处？而不是直接用一个实现类UserServiceImpl.java。希望知道的能详细描述下！

java是针对接口编程，制定编程规范，这样就拥有较好的可扩展性。做个小项目使用接口看起来还麻烦了，但是做大的项目就不一样了，针对接口编程就显得很重要了，利于维护和扩展。而且在分工上也比较容易配合。比如，我要调用service层方法，直接通过接口调用方法就好了，完全不必关心方法的实现，可以由团队的其他人来做。另外，不针对接口编程，做的只是一个项目。而针对接口编程，可以做成产品，然后在产品的基础上构建项目。相同领域的项目，很多只是具体实现的细节不同而已。 参考技术A 分别定义接口和实现类是java架构思想中开闭原则的体现，对扩展开放，对修改关闭。举个例子：假如你这个注册刚开始是对国内用户开放，中国用户注册成功返回“注册成功”，随着业务扩展，需要海外用户开放，假如美国用户返回“register success”，如果你有接口，可以再美国的AmericaUserServiceImpl.java中实现一个UserService.java的接口，来定义美国用户的注册业务，而不是在之UserServiceImpl.java中增加if else来对不同逻辑进行处理，这样，后续如果某个地区的注册业务有变动，只需要修改对应地区的实现类，修改不会影响到其他地区的实现类，降低了耦合性。
对于小型项目来说，确实可以不用多写一个接口，直接写实现类就可以了。接口+实现类是一种良好的编码习惯而已。就好像写代码时候的缩进和驼峰命名法。 参考技术B 看完这么多人都在说一些假大空的话，实在得回答一次了，有人说为了解耦合，难道少写个接口就不是解耦合了？什么是解耦合，解耦合就是说当你修改某个层的代码，其他层不需要修改代码，这里还涉及不到解耦合，谢谢。有人说是针对接口编程，我就呵呵呵，我做一个项目，各层都是自己写，我多写个接口层，每次修改service层我都要修改接口和实现两处地方，我脑子有病啊？有人说动态代理，我信你鬼，你个糟老头子坏得很，非让我用JDK动态代理，我就不用，我用CGLIB代理怎么了？到底有什么非常深刻的理由让我们必须用接口，是为了对一些具体数据逻辑的保护，而且，annotation注解注解在接口上，非常方便，要不就得写到方法上，而有时会不小心注解到private方法上，而annotation注解对该方法并不能生效，产生设计上的不合理 参考技术C 接口是要实现一个对象,要实现UserServiceImpl.java这个类就要先建立一个接口,通过这个UserService.java接口来实现UserServiceImpl.java 参考技术D 接口规范了你的应用的方法及目的实现类则可以用不同的方法去实现你的应用接口类让设计人员去规划，实现类让具体的应用人员实现，实现时可以因人而异，根据具体情况用不同的方法