67,512
社区成员
发帖
与我相关
我的任务
分享面向接口编程困惑
小弟工作也有两年多了，最近正在搭建公司的一个框架，目前剩下的问题就是用不用接口。可能是之前做的项目不是非常大，也有可能是工作中没有细心观察，至今没有感受到接口编程带来的好处。在开发中没有出现过“看，这就是使用接口带来的好处”或者是“幸好这个地方是用接口实现的，要不就惨了”。
相反，使用接口感觉到的只是种种不便，一直纠结于写接口，然后写实现类----因为很少有项目能在开发之前完完全全设计好接口，剩下的工作就是实现。
有没有人能说几个应用场景充分阐述一下必须使用接口，使用普通类会带来很多麻烦？为了节省大家的时间，请不要说笼统的说使用接口带来的好处，这些网上都有，大部分开发人员也知道。
相反，使用接口感觉到的只是种种不便，一直纠结于写接口，然后写实现类----因为很少有项目能在开发之前完完全全设计好接口，剩下的工作就是实现。
有没有人能说几个应用场景充分阐述一下必须使用接口，使用普通类会带来很多麻烦？为了节省大家的时间，请不要说笼统的说使用接口带来的好处，这些网上都有，大部分开发人员也知道。
...全文
请发表友善的回复…
发表回复
毛员外 2014-05-14
- 打赏
- 举报
看了楼上一些说的，觉得很对，对于接口吧，得看项目大小，项目越大了，模块越多了，特别是版本出的比较勤快的那种，不用接口这种思想，会很蛋疼，从某种程度来说，接口其实就是一种说好了就不变的约定，设计的时候定义的接口来做契约也好，不套接口，定义一个类一系列方法直接的实现也好，都是一种“说一不二”的，即敲定了天塌下来也改变不了的，想要新的，加接口，原有的是不能变的。所以呢，这就是一种思想而已
ChosenWang 2012-09-01
- 打赏
- 举报
接口对于编码规范来说起了很大作用，如果想往架构师方式发展的话，必须要接受这种思想。可能在代码上看不到什么用处，可是要想的长远一点的话，意义就不一样了。
Woodpecker 2012-09-01
- 打赏
- 举报
接口这个可能那些开发java语言的感触更深吧，举个例子，java1.5的很多IO类已经被NIO重写了，但是我们用的时候还是用的以前的IO接口，实际上效率已经提升了，但是我们不需要改变我们的程序就能感受到...我觉得项目越大，改动越多，扩展性要求越高，接口的好处感受的越明显
a512796048 2012-09-01
- 打赏
- 举报
这是mvc2模式 最大的特点就是接口方便扩展 对外开往，现在都是移动互联时代了，很多网站都要有手机登陆，这时候就需要提供接口， 比如说 有些功能跨很多模块 这时候通过接口很好管理
Justin_Chiang 2012-08-31
- 打赏
- 举报
面向接口编程，个人觉得是架构师考虑的问题，架构师就是专门来拿捏本次项目运用的什么框架，什么语言，会遇到什么问题，针对问题搞点共通什么的，如何提高效率等等---------------------------------------------------------其实我也不懂。
pkanyue 2012-08-28
- 打赏
- 举报
我们现在的项目要做产品，要代码统一，但是呢，各个省份不同客户的业务、模型都有所差别，如果单纯的把代码糅合在一起实现产品化，想想都挺可怕，客户更不可能同意这种糅合。
怎么解决呢，自然想到多态了，想到了复用，而接口呢正符合这种特点，但是要怎样使用接口呢，又想到设计模式。
而我们试想一下如果不用接口...会是怎么一种场景 ...
怎么解决呢，自然想到多态了，想到了复用，而接口呢正符合这种特点，但是要怎样使用接口呢，又想到设计模式。
而我们试想一下如果不用接口...会是怎么一种场景 ...
MyOracleX 2012-08-28
- 打赏
- 举报
[Quote=引用 18 楼 的回复:]
接口感觉还好啊，很好用啊
[/Quote]
好在什么地方，能举例说明一下吗
接口感觉还好啊，很好用啊
[/Quote]
好在什么地方，能举例说明一下吗
zwx617909257 2012-08-28
- 打赏
- 举报
定义了借口，相当于定义了一个标准。对项目的分层开发有帮助。还有就是修改的时候能方便些、
Smile_Ares 2012-08-28
- 打赏
- 举报
接口感觉还好啊，很好用啊
scbb 2012-08-28
- 打赏
- 举报
[Quote=引用 15 楼 的回复:]
引用 11 楼 的回复:
哈哈，以中国IT民工的开发效率。
Service ServiceImpl DAO还不是一天写掉了呀。。。。
还关心个啥，你先写接口，实现类慢慢写哦，我调用接口的类可以做了。
嗯，但是哪怕就是你自己随便定义下接口，事实上，也体现了它的好处是不是，起他们调用的人，知道你的方法名，参数，注释是什么，至于你怎么实现的，要实现多久，那完全不管我的事。我只管把我自……
[/Quote]
呵呵，我有点抬杠了。我觉得Eternalc很多很好。
现实中我也肯定接口的。 问题讨论讨论更清楚。
引用 11 楼 的回复:
哈哈，以中国IT民工的开发效率。
Service ServiceImpl DAO还不是一天写掉了呀。。。。
还关心个啥，你先写接口，实现类慢慢写哦，我调用接口的类可以做了。
嗯，但是哪怕就是你自己随便定义下接口，事实上，也体现了它的好处是不是，起他们调用的人，知道你的方法名，参数，注释是什么，至于你怎么实现的，要实现多久，那完全不管我的事。我只管把我自……
[/Quote]
呵呵，我有点抬杠了。我觉得Eternalc很多很好。
现实中我也肯定接口的。 问题讨论讨论更清楚。
MyOracleX 2012-08-28
- 打赏
- 举报
“Eternalc”的分工的确能体现接口的好处。但这个恐怕不是使用接口的唯一原因吧，除了开发效率和分工，大家再说说使用接口的其他原因，比如可扩展性等
Eternalc 2012-08-28
- 打赏
- 举报
[Quote=引用 11 楼 的回复:]
哈哈，以中国IT民工的开发效率。
Service ServiceImpl DAO还不是一天写掉了呀。。。。
还关心个啥，你先写接口，实现类慢慢写哦，我调用接口的类可以做了。
[/Quote]
嗯，但是哪怕就是你自己随便定义下接口，事实上，也体现了它的好处是不是，起他们调用的人，知道你的方法名，参数，注释是什么，至于你怎么实现的，要实现多久，那完全不管我的事。我只管把我自己的那层写好了就好了，对不对。
而对于写DAO的人，我根本不关心你复杂的上层业务是什么。我只管写自己的高效SQL即可。
而对于写View的人，我根本不关心你后台怎么处理的，我只管给你对应的参数，然后用你的返回值展示即可了。
但是对于太多还在走一人一模块的，那接口的好处就被抹杀了，所以很多人觉得接口鸡肋也很正常的，毕竟我们的项目又不是jdbc，成天吃饱了换各种实现。你今天数据库SQLServer ，明天Oracle，我觉得吃饱了，你直接告诉客户，我这个数据库是oracle 就是了。
哈哈，以中国IT民工的开发效率。
Service ServiceImpl DAO还不是一天写掉了呀。。。。
还关心个啥，你先写接口，实现类慢慢写哦，我调用接口的类可以做了。
[/Quote]
嗯，但是哪怕就是你自己随便定义下接口，事实上，也体现了它的好处是不是，起他们调用的人，知道你的方法名，参数，注释是什么，至于你怎么实现的，要实现多久，那完全不管我的事。我只管把我自己的那层写好了就好了，对不对。
而对于写DAO的人，我根本不关心你复杂的上层业务是什么。我只管写自己的高效SQL即可。
而对于写View的人，我根本不关心你后台怎么处理的，我只管给你对应的参数，然后用你的返回值展示即可了。
但是对于太多还在走一人一模块的，那接口的好处就被抹杀了，所以很多人觉得接口鸡肋也很正常的，毕竟我们的项目又不是jdbc，成天吃饱了换各种实现。你今天数据库SQLServer ，明天Oracle，我觉得吃饱了，你直接告诉客户，我这个数据库是oracle 就是了。
Eternalc 2012-08-28
- 打赏
- 举报
[Quote=引用 7 楼 的回复:]
你放眼望去中国最不缺的就是coding的人，会前台又会框架，还会DB的人多得是。。。。
[/Quote]
会和高效是2码事，我会写SQL，但我写出的SQL能比DBA高效吗？有的人写的SQL，可能要查1分钟，有的人只要1秒，效率差太多。
同样HQL调用，有的人是for嵌套着循环，有的人能写出相对复杂一些的HQL，实际中遇到很多了。
其次是效率，实际开发中，最难的就是业务。现在5个人，如果分模块，你要5个人业务都达到一样的水平都去学习来开发快，还是其他人直接做其他的，专门有人熟悉业务的去理解新的业务块，我觉得后者要快很多。
我觉得要5个啥都会，样样都半通水的，不如要5个人，各有长处的，然后用一个把他们整合在一起，这样实际开发效率要高很多。因为这样的优势，我是体会过的，体会很深。但是在公司，很多事，也不是我们说的算的，所以很多时候，对于我们而言，难免接口就是一个累赘的东西。起码在我未体会过这种分工之前，我也这么觉得。
我干嘛非要一个DAO，我写一个接口，然后我自己再去实现它，我吃饱了，我还不如写一个公共的DAO，然后调用传入对应的对象调用就是了。反正我写的DAO也就是我自己调用，看不懂DAO我可以加注释。做一个接口，没啥意义。
你放眼望去中国最不缺的就是coding的人，会前台又会框架，还会DB的人多得是。。。。
[/Quote]
会和高效是2码事，我会写SQL，但我写出的SQL能比DBA高效吗？有的人写的SQL，可能要查1分钟，有的人只要1秒，效率差太多。
同样HQL调用，有的人是for嵌套着循环，有的人能写出相对复杂一些的HQL，实际中遇到很多了。
其次是效率，实际开发中，最难的就是业务。现在5个人，如果分模块，你要5个人业务都达到一样的水平都去学习来开发快，还是其他人直接做其他的，专门有人熟悉业务的去理解新的业务块，我觉得后者要快很多。
我觉得要5个啥都会，样样都半通水的，不如要5个人，各有长处的，然后用一个把他们整合在一起，这样实际开发效率要高很多。因为这样的优势，我是体会过的，体会很深。但是在公司，很多事，也不是我们说的算的，所以很多时候，对于我们而言，难免接口就是一个累赘的东西。起码在我未体会过这种分工之前，我也这么觉得。
我干嘛非要一个DAO，我写一个接口，然后我自己再去实现它，我吃饱了，我还不如写一个公共的DAO，然后调用传入对应的对象调用就是了。反正我写的DAO也就是我自己调用，看不懂DAO我可以加注释。做一个接口，没啥意义。
MyOracleX 2012-08-28
- 打赏
- 举报
[Quote=引用 9 楼 的回复:]
可以想想，这种分工下，如果没有接口，我写Service的时候，我如何去调用DAO层的？我根本不知道你实现我要的数据的方法名是什么，参数是如何定义的，返回值又是什么，那么我得去问你，我一天可能要用几十个方法，我能每个都问你吗？我今天问了你，你说XXX（String，int），回头你自己觉得不对，应该是XXX（Map），那调用的人怎么办
而有了接口，我就可以调用了，而实现接口的人，也是固定的，……
[/Quote]
擦！说的太好了，太给力了！和我想的一样，就是说不出来，哈哈
可以想想，这种分工下，如果没有接口，我写Service的时候，我如何去调用DAO层的？我根本不知道你实现我要的数据的方法名是什么，参数是如何定义的，返回值又是什么，那么我得去问你，我一天可能要用几十个方法，我能每个都问你吗？我今天问了你，你说XXX（String，int），回头你自己觉得不对，应该是XXX（Map），那调用的人怎么办
而有了接口，我就可以调用了，而实现接口的人，也是固定的，……
[/Quote]
擦！说的太好了，太给力了！和我想的一样，就是说不出来，哈哈
MyOracleX 2012-08-28
- 打赏
- 举报
[Quote=引用 5 楼 的回复:]
比如你有一个类，类里面有个方法，20个类中都要引用这个方法；突然有一天，要修改这个方法的参数或者相应的字段，那你是不是要修改20处？如果写成接口，只需要修改实现接口的那个方法即可。我是这样理解的，呵呵。
[/Quote]
按你意思，写成一个接口，20个类都要实现这个接口，然后接口中的方法参数变了或者字段变了，那剩下的呢....难道实现类能不做任何改动
比如你有一个类，类里面有个方法，20个类中都要引用这个方法；突然有一天，要修改这个方法的参数或者相应的字段，那你是不是要修改20处？如果写成接口，只需要修改实现接口的那个方法即可。我是这样理解的，呵呵。
[/Quote]
按你意思，写成一个接口，20个类都要实现这个接口，然后接口中的方法参数变了或者字段变了，那剩下的呢....难道实现类能不做任何改动
scbb 2012-08-28
- 打赏
- 举报
[Quote=引用 9 楼 的回复:]
可以想想，这种分工下，如果没有接口，我写Service的时候，我如何去调用DAO层的？我根本不知道你实现我要的数据的方法名是什么，参数是如何定义的，返回值又是什么，那么我得去问你，我一天可能要用几十个方法，我能每个都问你吗？我今天问了你，你说XXX（String，int），回头你自己觉得不对，应该是XXX（Map），那调用的人怎么办
而有了接口，我就可以调用了，而实现接口的人，也是固定的，……
[/Quote]
哈哈，以中国IT民工的开发效率。
Service ServiceImpl DAO还不是一天写掉了呀。。。。
还关心个啥，你先写接口，实现类慢慢写哦，我调用接口的类可以做了。
可以想想，这种分工下，如果没有接口，我写Service的时候，我如何去调用DAO层的？我根本不知道你实现我要的数据的方法名是什么，参数是如何定义的，返回值又是什么，那么我得去问你，我一天可能要用几十个方法，我能每个都问你吗？我今天问了你，你说XXX（String，int），回头你自己觉得不对，应该是XXX（Map），那调用的人怎么办
而有了接口，我就可以调用了，而实现接口的人，也是固定的，……
[/Quote]
哈哈，以中国IT民工的开发效率。
Service ServiceImpl DAO还不是一天写掉了呀。。。。
还关心个啥，你先写接口，实现类慢慢写哦，我调用接口的类可以做了。
MyOracleX 2012-08-28
- 打赏
- 举报
[Quote=引用 6 楼 的回复:]
其实Java这一套，包括MVC，很多时候都是用来方便分工的。
我们在之前的项目尝试过，利用接口和MVC进行分层的专人开发，和传统的模块开发的效率对比，传统差的太多了。
当时，我们组1共5个人，一个负责人，他负责搭建项目的框架，之后，他要做的事就是定义接口。而我们要做的事很简单。就是实现接口。剩下4个人，1个人写业务逻辑，即C层，一个人写DB和DAO，即M层，2个人写界面，即V层。
……
[/Quote]
说的很对！像你们那种模式恰恰体现了接口的好处
其实Java这一套，包括MVC，很多时候都是用来方便分工的。
我们在之前的项目尝试过，利用接口和MVC进行分层的专人开发，和传统的模块开发的效率对比，传统差的太多了。
当时，我们组1共5个人，一个负责人，他负责搭建项目的框架，之后，他要做的事就是定义接口。而我们要做的事很简单。就是实现接口。剩下4个人，1个人写业务逻辑，即C层，一个人写DB和DAO，即M层，2个人写界面，即V层。
……
[/Quote]
说的很对！像你们那种模式恰恰体现了接口的好处
Eternalc 2012-08-28
- 打赏
- 举报
可以想想，这种分工下，如果没有接口，我写Service的时候，我如何去调用DAO层的？我根本不知道你实现我要的数据的方法名是什么，参数是如何定义的，返回值又是什么，那么我得去问你，我一天可能要用几十个方法，我能每个都问你吗？我今天问了你，你说XXX（String，int），回头你自己觉得不对，应该是XXX（Map），那调用的人怎么办
而有了接口，我就可以调用了，而实现接口的人，也是固定的，你根本不用管我到底要做什么用，你只管按照接口上的定义，实现内容即可。很方便，效率非常高。
至于什么接口实现的替换什么的，我只能说，这种在实际中，很少用到，就上面说的，最多也就是做一些大的平台会用到，做一个接口，返回关键数据给外部系统什么的，一般小点的项目是用不着到的。理论很丰满，现实很骨感，实现就是在我们国内，大多数的项目，接口的作用就2类
一种是平台型的，要提供外部系统数据用的
一种就是分工方便的
而有了接口，我就可以调用了，而实现接口的人，也是固定的，你根本不用管我到底要做什么用，你只管按照接口上的定义，实现内容即可。很方便，效率非常高。
至于什么接口实现的替换什么的，我只能说，这种在实际中，很少用到，就上面说的，最多也就是做一些大的平台会用到，做一个接口，返回关键数据给外部系统什么的，一般小点的项目是用不着到的。理论很丰满，现实很骨感，实现就是在我们国内，大多数的项目，接口的作用就2类
一种是平台型的，要提供外部系统数据用的
一种就是分工方便的
MyOracleX 2012-08-28
- 打赏
- 举报
[Quote=引用 2 楼 的回复:]
如果你们原来存某些数据使用XML，现在要换成SQL，怎么办
[/Quote]
既然你加上了“如果”说明这种情况也有可能不发现。即便会出现，为了解决这个问题，在项目中和这个问题没有关系的类都也要硬生生的套上一个接口。从另一个角度看，这种解决方式难道就没问题？
如果你们原来存某些数据使用XML，现在要换成SQL，怎么办
[/Quote]
既然你加上了“如果”说明这种情况也有可能不发现。即便会出现，为了解决这个问题，在项目中和这个问题没有关系的类都也要硬生生的套上一个接口。从另一个角度看，这种解决方式难道就没问题？
scbb 2012-08-28
- 打赏
- 举报
[Quote=引用 3 楼 的回复:]
引用 1 楼 的回复:
引用楼主 的回复:
相反，使用接口感觉到的只是种种不便，一直纠结于写接口，然后写实现类----因为很少有项目能在开发之前完完全全设计好接口，剩下的工作就是实现。
非常赞同啊~！！ 也许是我们设计能力不够吧。
举个例子吧。 JDBC驱动你用过吧？ JDBC其实大多是实现了sun的JDBC接口的实现类。
你发现你爽伐？ 不过是Oracle还是mysq……
[/Quote]
这点我在工作中感受和楼主一样。
也许某个web要用非常长得时间，然后要改了又改。也许好点。
目前我碰到的项目，基本一枪头做完。 过个几年也只改一点，或者增加新功能。
所以这样一个service1个借口有点点鸡肋。
当然接口写好，大家都可以并行开发，这也是个说法。
不过我们这里还是一块自己做的，从jsp service到dao 到sql，一个人做。
因为相比程序，业务更复杂。 一个人理解了业务就做整的一块也许效率更高。
楼上说的，你放眼望去中国最不缺的就是coding的人，会前台又会框架，还会DB的人多得是。。。。
欢迎讨论哦~~
引用 1 楼 的回复:
引用楼主 的回复:
相反，使用接口感觉到的只是种种不便，一直纠结于写接口，然后写实现类----因为很少有项目能在开发之前完完全全设计好接口，剩下的工作就是实现。
非常赞同啊~！！ 也许是我们设计能力不够吧。
举个例子吧。 JDBC驱动你用过吧？ JDBC其实大多是实现了sun的JDBC接口的实现类。
你发现你爽伐？ 不过是Oracle还是mysq……
[/Quote]
这点我在工作中感受和楼主一样。
也许某个web要用非常长得时间，然后要改了又改。也许好点。
目前我碰到的项目，基本一枪头做完。 过个几年也只改一点，或者增加新功能。
所以这样一个service1个借口有点点鸡肋。
当然接口写好，大家都可以并行开发，这也是个说法。
不过我们这里还是一块自己做的，从jsp service到dao 到sql，一个人做。
因为相比程序，业务更复杂。 一个人理解了业务就做整的一块也许效率更高。
楼上说的，你放眼望去中国最不缺的就是coding的人，会前台又会框架，还会DB的人多得是。。。。
欢迎讨论哦~~
加载更多回复（7）
