开发项目中，都是一个接口，一个实现类，有的DAO层接口还会继承一个父接口，这样做有什么好处？

[a540057001]

这些项目都是一些小项目，这样做的好处是什么？对后期维护很有利？
像DAO层接口又会继承一个父接口，我能理解的只有规范化函数的名称，到底这样做能给开发带来什么样的好处？
求有经验的给小弟点指引，实在迷惑，感激不尽。

[言月秋]

一些好的习惯.

[yue_hun]

接口主要还是定义规范

[yue_hun]

第一： 接口一般是用来规范代码结构。一般大公司会由SE先将系统架构搭建号，将许多操作进行接口来定义规范。让大家按照统一的方式来开发代码，有利于团队的合作。 第二：接口 有利于进行后期扩展，可以不改变原来业务的代码，实现扩展 接口如果用的好，在后期扩展什么的，会体现出来 如果没有驾驭接口的能力，一味的以套路进行接口的编写，建议还不如不写。要不反倒增加工作量

[Inhibitory]

如果你不是做框架，给别人提供修改接口实现的机会，只是为了项目而开发，不考虑扩展，没必要做这么麻烦，根据项目特点使用合适的技术，不是用最先进的设计的就是最好的。

[不是太高的手]

其实小项目 没必要 这样做

[失落夏天]

个人感觉是一种规范吧。。 刚开始学java的时候老师教这么多不理解。 以后进了公司跟着一个师傅学，发现在日本8年工作经验的师傅竟然也是坚持这么多， 后来慢慢自己习惯了这种结构，觉得还是蛮有好处的。 第一，看接口很明了的知道这个接口有哪些功能。 第二，写好了接口，接口的具体实现有可能并不是由自己实现，说白了，降低耦合性。 第三，如果以后嵌入第三方SDK的话，经常会用到这个实现接口的方式。自己写SDK的话当然也需要用到。 当然我说的是接口， dao,service,action三层接口原理类似。现在几乎已经不写java服务端了，这方面就不多说了。

[枫醉秋]

其实就是一种默认的规范吧。。。 大部分就是套用3层架构的

[安特矮油]

针对接口编程有利于后期扩展，也有利于后期业务有变动时减少对原来业务逻辑的处理。

[wanghualeilei]

看这个项目的代码是否都在你们控制范围 如果不是 尽量添加接口 如果代码可控 用不着

[_南天北落]

小项目觉得就没必要了，但是也说不准以后有大的改动呢。 1. 这样做使代码分离，方便后期维护 2. 代码可读性比较高，看接口就知道该类想实现什么功能 3. 代码逻辑分离，这样写的代码一层层分下去最后在控制层只要调用。高内聚低耦合的原则。 我感觉好像就这些了。

[聪头]

清楚明了，好分活

[tony4geek]

上面很多人都说了了。

[a540057001]

引用 2 楼 AA5279AA 的回复:

个人感觉是一种规范吧。。 刚开始学java的时候老师教这么多不理解。 以后进了公司跟着一个师傅学，发现在日本8年工作经验的师傅竟然也是坚持这么多， 后来慢慢自己习惯了这种结构，觉得还是蛮有好处的。 第一，看接口很明了的知道这个接口有哪些功能。 第二，写好了接口，接口的具体实现有可能并不是由自己实现，说白了，降低耦合性。 第三，如果以后嵌入第三方SDK的话，经常会用到这个实现接口的方式。自己写SDK的话当然也需要用到。 当然我说的是接口， dao,service,action三层接口原理类似。现在几乎已经不写java服务端了，这方面就不多说了。

谢谢，各位的回答总算让我摆脱了心中的纠结，稍后结贴

[a540057001]

引用 7 楼 daijun1025 的回复:

第一： 接口一般是用来规范代码结构。一般大公司会由SE先将系统架构搭建号，将许多操作进行接口来定义规范。让大家按照统一的方式来开发代码，有利于团队的合作。 第二：接口 有利于进行后期扩展，可以不改变原来业务的代码，实现扩展 接口如果用的好，在后期扩展什么的，会体现出来 如果没有驾驭接口的能力，一味的以套路进行接口的编写，建议还不如不写。要不反倒增加工作量

谢谢，各位的回答总算让我摆脱了心中的纠结，稍后结贴

[a540057001]

引用 9 楼 my_God_sky 的回复:

小项目觉得就没必要了，但是也说不准以后有大的改动呢。 1. 这样做使代码分离，方便后期维护 2. 代码可读性比较高，看接口就知道该类想实现什么功能 3. 代码逻辑分离，这样写的代码一层层分下去最后在控制层只要调用。高内聚低耦合的原则。 我感觉好像就这些了。

谢谢，各位的回答总算让我摆脱了心中的纠结，稍后结贴

[郗晓勇]

http://goobbe.com/questions/3671959/benefits-of-implementing-an-interface