开发项目中，都是一个接口，一个实现类，有的DAO层接口还会继承一个父接口，这么做有什么好处
开发项目中，都是一个接口，一个实现类，有的DAO层接口还会继承一个父接口，这样做有什么好处？
这些项目都是一些小项目，这样做的好处是什么？对后期维护很有利？
像DAO层接口又会继承一个父接口，我能理解的只有规范化函数的名称，到底这样做能给开发带来什么样的好处？
求有经验的给小弟点指引，实在迷惑，感激不尽。
------解决思路----------------------
个人感觉是一种规范吧。。
刚开始学java的时候老师教这么多不理解。
以后进了公司跟着一个师傅学，发现在日本8年工作经验的师傅竟然也是坚持这么多，
后来慢慢自己习惯了这种结构，觉得还是蛮有好处的。
第一，看接口很明了的知道这个接口有哪些功能。
第二，写好了接口，接口的具体实现有可能并不是由自己实现，说白了，降低耦合性。
第三，如果以后嵌入第三方SDK的话，经常会用到这个实现接口的方式。自己写SDK的话当然也需要用到。
当然我说的是接口，
dao,service,action三层接口原理类似。现在几乎已经不写java服务端了，这方面就不多说了。
------解决思路----------------------
针对接口编程有利于后期扩展，也有利于后期业务有变动时减少对原来业务逻辑的处理。
------解决思路----------------------
第一： 接口一般是用来规范代码结构。一般大公司会由SE先将系统架构搭建号，将许多操作进行接口来定义规范。让大家按照统一的方式来开发代码，有利于团队的合作。
第二：接口 有利于进行后期扩展，可以不改变原来业务的代码，实现扩展
接口如果用的好，在后期扩展什么的，会体现出来
如果没有驾驭接口的能力，一味的以套路进行接口的编写，建议还不如不写。要不反倒增加工作量
------解决思路----------------------
小项目觉得就没必要了，但是也说不准以后有大的改动呢。
1. 这样做使代码分离，方便后期维护
2. 代码可读性比较高，看接口就知道该类想实现什么功能
3. 代码逻辑分离，这样写的代码一层层分下去最后在控制层只要调用。高内聚低耦合的原则。
我感觉好像就这些了。
这些项目都是一些小项目，这样做的好处是什么？对后期维护很有利？
像DAO层接口又会继承一个父接口，我能理解的只有规范化函数的名称，到底这样做能给开发带来什么样的好处？
求有经验的给小弟点指引，实在迷惑，感激不尽。
------解决思路----------------------
个人感觉是一种规范吧。。
刚开始学java的时候老师教这么多不理解。
以后进了公司跟着一个师傅学，发现在日本8年工作经验的师傅竟然也是坚持这么多，
后来慢慢自己习惯了这种结构，觉得还是蛮有好处的。
第一，看接口很明了的知道这个接口有哪些功能。
第二，写好了接口，接口的具体实现有可能并不是由自己实现，说白了，降低耦合性。
第三，如果以后嵌入第三方SDK的话，经常会用到这个实现接口的方式。自己写SDK的话当然也需要用到。
当然我说的是接口，
dao,service,action三层接口原理类似。现在几乎已经不写java服务端了，这方面就不多说了。
------解决思路----------------------
针对接口编程有利于后期扩展，也有利于后期业务有变动时减少对原来业务逻辑的处理。
------解决思路----------------------
第一： 接口一般是用来规范代码结构。一般大公司会由SE先将系统架构搭建号，将许多操作进行接口来定义规范。让大家按照统一的方式来开发代码，有利于团队的合作。
第二：接口 有利于进行后期扩展，可以不改变原来业务的代码，实现扩展
接口如果用的好，在后期扩展什么的，会体现出来
如果没有驾驭接口的能力，一味的以套路进行接口的编写，建议还不如不写。要不反倒增加工作量
------解决思路----------------------
小项目觉得就没必要了，但是也说不准以后有大的改动呢。
1. 这样做使代码分离，方便后期维护
2. 代码可读性比较高，看接口就知道该类想实现什么功能
3. 代码逻辑分离，这样写的代码一层层分下去最后在控制层只要调用。高内聚低耦合的原则。
我感觉好像就这些了。