一个接口如果只可能有一个实现类，那还有必要做这个接口吗？

[luckyman_2]

做了几年开发，一直没考虑过这个问题，以前用SSH框架，总是各个层之间调用都是通过接口。但是，做多项目后就发现一个问题，很多业务逻辑层的接口，基本上实现类是唯一的（其实不止业务逻辑层，项目其它地方很多接口的实现类也都是唯一的），这个时候用接口好处到底是什么呢？
我认为接口是描述一种行为，不关心具体实现方式，所以它应该具有普适性，像我上面说的那种场景下，硬要用接口是否过于迂腐，大家怎么看这个问题？

[luckyman_2]

引用 1 楼 Javainging 的回复:

接口怎么可能只有一个实现类呢？

我说的是实际项目中，自己定义的那些接口。比如，控制层中用到IGetUserInfoService这么个接口，然后有GetUserInfoService这么个类去实现它，取得用户信息。但整个项目中，除了GetUserInfoService类，已经没有别的类去实现IGetUserInfoService接口了。这种情况下，IGetUserInfoService接口存在的意义是什么，直接用实现类有何不妥之处呢？

[yxyver]

新手一个，同样疑问，求解。难道接口是为了以后升级时重写实现类？

[天才小小布]

使用接口的好处就在于代码可以 重复使用，我们可以定义一个接口，根据不同的功能再写实现类，这样的代码更有逻辑和层次感。直接写实现类也是可以的，但是我们编写也要考虑到后续的开发和管理，不能只单单考虑一个方法的实现。

[luckyman_2]

引用 4 楼 w410589502 的回复:

使用接口的好处就在于代码可以 重复使用，我们可以定义一个接口，根据不同的功能再写实现类，这样的代码更有逻辑和层次感。直接写实现类也是可以的，但是我们编写也要考虑到后续的开发和管理，不能只单单考虑一个方法的实现。

接口的优点其实我也知道，网上也有不少论述，不过，关于在何种场景下考虑用接口，何种场景下可以不必用接口，这方面的论述几乎没有。我只是想问问看各位在你们的实际项目中，有没有那种几乎不太有可能扩展的接口，你们对这类型的接口是如何看的。比如说我2楼的回答里面提到的IGetUserInfoService，这是属于业务逻辑层的接口，就是个简单取得用户信息功能，就算以后更换数据库，那也是改Dao层，业务逻辑几乎不会变。

[心随自在飞]

的确 ，这是个值得讨论的问题， 如果为了以后维护升级，加接口还是有必要的， 当然，不加接口有很多也是可以实现的。 这本来就不是一个能说的清楚的话题 主要还是看项目管理吧。 看你自己项目中的自己如何定义罢了。

[Cabbage_gang]

一、后期扩展考虑，指不定什么时候要重写呢？虽然几率很小，但是做个借口也不费事啊！~ 二、易于阅读，只需要给借口中写好注释，后期阅读的时候可以先只接口，然后整个项目的框架体系，以及业务逻辑就差不多清楚了！~ 三、习惯了...... 四、还没想好！~ 五、我实在编不下去了

[luckyman_2]

引用 3 楼 yxyver 的回复:

新手一个，同样疑问，求解。难道接口是为了以后升级时重写实现类？

以前看某教学视频有提到个开发原则：对扩展开放，对修改封闭。可那毕竟是比较理想化的说法，真要做到的话，开发人员本身的素养和项目经理管理水平都是有很高要求的。 实际是，项目中有些接口，可能只是程序员写程序的思维定势，因为教程上说要做接口就做了，原本就没考虑扩展，我质疑的是，这些接口存在的意义

[oO临时工Oo]

一、接口便于高层代码设计 如果你是个高级程序员，你在设计系统的时候，可能只会开发系统主要业务逻辑，并且用接口基本可以实现主业务逻辑的相互调用，而剩下的事就是不断去实现这些接口，这些事完全可以交给一个新手来管理。 二、便于面向服务的程序设计 比如，你开发了一个通用模块，这个模块一般有固守的功能或业务逻辑，那么你的功能和业务逻辑都体现在对外接的接口上。如果内部业务实现有变化 ，只需要调整实现类，接口不变，这样，调用你的代码模块就不需要变更。这样使用者（用通用模块的代码）和服务接供者（通用模块代码）之间的耦合度就会降低。 三、便于代码阅读 良好的注释，别人阅读你的代码时，只需要看看接口的注释，不需要看你过多的实现细节。 现看你提问的出发点，你提及的GetUserInfoService，可能由于业务功能太简单，没有体现出接口的好处。现在的培训也好、市面上的Java书籍也好，都会交人封装接口，IUserServer UserServiceImpl IUserDao UserDaoImpl，其实这是有好处的，主要是培养使用接口的好习惯。但是在这种业务逻辑单一的“用户-角色－权限”管理功能，是不能很好体现出接口的好处。 接口主要是面向通用应用程序、第三方插件、通用业务逻辑的，主要目的是降低代码耦合度、提高代码的可维护性、提高代码的可复用性，他唯一不具有的特点就是“让运行高效”。 在常规Java领域，写维护效率高的程序，而不是写运行效率高的程序。

[fudapeng7]

连接口都搞计划生育了~~

[这个逗b]

写个接口又不会费多大事，但是万一系统升级 需要用这个接口呢？便于代码的维护而已。 举个生活中的例子。 就好像插线板。 你一个人住家里，墙上的插线孔够你用，你就不需要买插线板了对么？万一有个客人要来？或者你以后结婚了。这个插线孔还够么？

[Java_er]

接口怎么可能只有一个实现类呢？

[scmod]

反正我觉得是比较没意义的... 设计的太宽了...基础的搞个几个接口有用 后面具体实现直接实现基础那几个就好了感觉 不用继承基础写一堆然后又实现 感觉一般service跟dao的接口都挺没意义的 虽然好像基本都这么做,但是总觉得改起来超麻烦

[yzx2015fd]

不用接口你不同层就耦合了。还怎么替换掉不同层。

[sandsli]

就题目而言 不用接口实现多态 就毫无意义 的存在可以砍掉。大多数的项目并没有那么多花头搞那么多接口，那次业务级别 改动不是从数据库改到前端，里面的方法签名加参数减参数的， 每次还要该两变 接口改下，实现改下，关键是 每次看代码 F12定位不到实现类上去，很恼火。 所以 对内的接口 完全没必要留，徒增代码量 双倍注释，我就要爽，我就要干掉他（接口）， 需要多态的情况下再去写，为了写接口而写接口 太作了

[我纯洁全身都纯洁]

为了公用。。。。

[luckyman_2]

引用 14 楼 sands2218212 的回复:

就题目而言 不用接口实现多态 就毫无意义 的存在可以砍掉。大多数的项目并没有那么多花头搞那么多接口，那次业务级别 改动不是从数据库改到前端，里面的方法签名加参数减参数的， 每次还要该两变 接口改下，实现改下，关键是 每次看代码 F12定位不到实现类上去，很恼火。 所以 对内的接口 完全没必要留，徒增代码量 双倍注释，我就要爽，我就要干掉他（接口）， 需要多态的情况下再去写，为了写接口而写接口 太作了

确实，虽然接口的设计需要一定功底，但也不可能一劳永逸，业务变动而接口不改的情况极少。但是，在java领域，用接口还是主流思想，做j2ee过来的，基本都是那一套，已经到了墨守成规的地步，明明就知道麻烦，但又拿不出什么干货来说明这样做的好处。 除非能遇到激进型团队，说干掉接口就干掉接口。 不知不觉提这个贴子也两年了，结贴喽

[若文]

我也觉得没有多大用处.在实际的项目中,一个接口就只对一个实现类. 而且基本用注解实现类. 那么要再写一个新的实现类,那原来的注解是否要撤销?两个都注解, 调用一个接口的方法的时候,会去找哪个实现类?还得修改原来的实现类的一些注解或配置文件. 如果是通过注解来做实现类,而实现类又好多个. 那维护的时候, 找真正的实现方法都是很头大的. 不能快捷定位到. 我觉得实际项目中没有太大作用.