面向接口编程困惑 本帖最后由 MyOracleX 于 2012-08-28 09:20:17 编辑 解决方案 » 免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货 非常赞同啊~！！ 也许是我们设计能力不够吧。举个例子吧。 JDBC驱动你用过吧？ JDBC其实大多是实现了sun的JDBC接口的实现类。你发现你爽伐？ 不过是Oracle还是mysql。 只要你download个jar文件，代码都不怎要改。（URL要改的。。）那些查询，更新，删除代码，不论什么数据库，用了JDBC就写得一个样。相反各大数据库产生自己都写自己的类，方法类名都不一样。 那么我们程序员是不是要悲剧了呀。。当然上面的例子只是接口的好处1个。当然你也可以钻牛角尖，说我规定厂商们类和方法必须写的一样，或者我提供父类，抽象类给他们。嘿嘿，大家探讨下吧。 如果你们原来存某些数据使用XML，现在要换成SQL，怎么办 恩，JDBC实现可以这样理解吧：sun定义了一个JDBC接口，剩下的oracle、mysql等数据库厂商实现了JDBC这个接口，这样开发人员的工作量就减少了。可事实上很多公司的项目中一个接口AService只有一个类AServiceImpl实现它，没有别的类也实现这个接口，那么此时是不是无法显示使用接口的好处，相反增加了开发的工作量 其实Java这一套，包括MVC，很多时候都是用来方便分工的。我们在之前的项目尝试过，利用接口和MVC进行分层的专人开发，和传统的模块开发的效率对比，传统差的太多了。当时，我们组1共5个人，一个负责人，他负责搭建项目的框架，之后，他要做的事就是定义接口。而我们要做的事很简单。就是实现接口。剩下4个人，1个人写业务逻辑，即C层，一个人写DB和DAO，即M层，2个人写界面，即V层。每个人关注自己的领域即可，根本无需关注DB是如何实现的，只需要看老大定义好的接口，直接调用即可。专注自己的那个层，可以让你写出高效的代码，我让你3天，天天写SQL，你能不熟练，能不高效吗？而我们之间的黏合剂就是接口。而很多公司分工还是用最传统的做法，分模块，一人一模块，那么非常糟糕了，一个人，你要懂界面+业务+DB，另外一个人，他也要懂界面+业务+DB，这样开发的效率去哪里高？啥都会的结果就是啥都不行。曾经我们的上头一次非常糟糕的分配任务。他分配的任务不是熟悉业务的人去做业务复杂的流程，而是让熟悉业务的做一个模块，让不熟悉业务的人负责一个模块，于是乎，我们那段时间，徘徊在界面、业务、DB之间，非常的混乱。 这点我在工作中感受和楼主一样。 也许某个web要用非常长得时间，然后要改了又改。也许好点。目前我碰到的项目，基本一枪头做完。 过个几年也只改一点，或者增加新功能。所以这样一个service1个借口有点点鸡肋。 当然接口写好，大家都可以并行开发，这也是个说法。不过我们这里还是一块自己做的，从jsp service到dao 到sql，一个人做。因为相比程序，业务更复杂。 一个人理解了业务就做整的一块也许效率更高。楼上说的，你放眼望去中国最不缺的就是coding的人，会前台又会框架，还会DB的人多得是。欢迎讨论哦~~ 可以想想，这种分工下，如果没有接口，我写Service的时候，我如何去调用DAO层的？我根本不知道你实现我要的数据的方法名是什么，参数是如何定义的，返回值又是什么，那么我得去问你，我一天可能要用几十个方法，我能每个都问你吗？我今天问了你，你说XXX（String，int），回头你自己觉得不对，应该是XXX（Map），那调用的人怎么办而有了接口，我就可以调用了，而实现接口的人，也是固定的，你根本不用管我到底要做什么用，你只管按照接口上的定义，实现内容即可。很方便，效率非常高。至于什么接口实现的替换什么的，我只能说，这种在实际中，很少用到，就上面说的，最多也就是做一些大的平台会用到，做一个接口，返回关键数据给外部系统什么的，一般小点的项目是用不着到的。理论很丰满，现实很骨感，实现就是在我们国内，大多数的项目，接口的作用就2类一种是平台型的，要提供外部系统数据用的一种就是分工方便的 哈哈，以中国IT民工的开发效率。Service ServiceImpl DAO还不是一天写掉了呀。还关心个啥，你先写接口，实现类慢慢写哦，我调用接口的类可以做了。 会和高效是2码事，我会写SQL，但我写出的SQL能比DBA高效吗？有的人写的SQL，可能要查1分钟，有的人只要1秒，效率差太多。同样HQL调用，有的人是for嵌套着循环，有的人能写出相对复杂一些的HQL，实际中遇到很多了。其次是效率，实际开发中，最难的就是业务。现在5个人，如果分模块，你要5个人业务都达到一样的水平都去学习来开发快，还是其他人直接做其他的，专门有人熟悉业务的去理解新的业务块，我觉得后者要快很多。我觉得要5个啥都会，样样都半通水的，不如要5个人，各有长处的，然后用一个把他们整合在一起，这样实际开发效率要高很多。因为这样的优势，我是体会过的，体会很深。但是在公司，很多事，也不是我们说的算的，所以很多时候，对于我们而言，难免接口就是一个累赘的东西。起码在我未体会过这种分工之前，我也这么觉得。我干嘛非要一个DAO，我写一个接口，然后我自己再去实现它，我吃饱了，我还不如写一个公共的DAO，然后调用传入对应的对象调用就是了。反正我写的DAO也就是我自己调用，看不懂DAO我可以加注释。做一个接口，没啥意义。 嗯，但是哪怕就是你自己随便定义下接口，事实上，也体现了它的好处是不是，起他们调用的人，知道你的方法名，参数，注释是什么，至于你怎么实现的，要实现多久，那完全不管我的事。我只管把我自己的那层写好了就好了，对不对。而对于写DAO的人，我根本不关心你复杂的上层业务是什么。我只管写自己的高效SQL即可。而对于写View的人，我根本不关心你后台怎么处理的，我只管给你对应的参数，然后用你的返回值展示即可了。但是对于太多还在走一人一模块的，那接口的好处就被抹杀了，所以很多人觉得接口鸡肋也很正常的，毕竟我们的项目又不是jdbc，成天吃饱了换各种实现。你今天数据库SQLServer ，明天Oracle，我觉得吃饱了，你直接告诉客户，我这个数据库是oracle 就是了。 “Eternalc”的分工的确能体现接口的好处。但这个恐怕不是使用接口的唯一原因吧，除了开发效率和分工，大家再说说使用接口的其他原因，比如可扩展性等 呵呵，我有点抬杠了。我觉得Eternalc很多很好。现实中我也肯定接口的。 问题讨论讨论更清楚。 这是mvc2模式 最大的特点就是接口方便扩展 对外开往，现在都是移动互联时代了，很多网站都要有手机登陆，这时候就需要提供接口， 比如说 有些功能跨很多模块 这时候通过接口很好管理 接口这个可能那些开发java语言的感触更深吧，举个例子，java1.5的很多IO类已经被NIO重写了，但是我们用的时候还是用的以前的IO接口，实际上效率已经提升了，但是我们不需要改变我们的程序就能感受到...我觉得项目越大，改动越多，扩展性要求越高，接口的好处感受的越明显 java.sql.Exception 不支持属性 j2ee的学习 openfire 开发问题 对于同时加载了多个 webapps 的TOMCAT,可否单独重启某个 webapp 吗? quartz-jobs.xml的配置问题 jsoup append 问题 如何使用socket传送大字符串 看java 线程 碰到一个看不明白的地方 在CSDN文档上看到一篇关于EJBBMPBean的文章,觉得上面的程序有问题啊! 怎么解决 据说是缺少监听 大虾们帮忙看看 求助 java怎么操作excl导入导出oracle数据库啊
你发现你爽伐？ 不过是Oracle还是mysql。 只要你download个jar文件，代码都不怎要改。（URL要改的。。）
那些查询，更新，删除代码，不论什么数据库，用了JDBC就写得一个样。相反各大数据库产生自己都写自己的类，方法类名都不一样。 那么我们程序员是不是要悲剧了呀。。当然上面的例子只是接口的好处1个。
当然你也可以钻牛角尖，说我规定厂商们类和方法必须写的一样，或者我提供父类，抽象类给他们。
嘿嘿，大家探讨下吧。
sun定义了一个JDBC接口，剩下的oracle、mysql等数据库厂商实现了JDBC这个接口，这样开发人员的工作量就减少了。可事实上很多公司的项目中一个接口AService只有一个类AServiceImpl实现它，没有别的类也实现这个接口，那么此时是不是无法显示使用接口的好处，相反增加了开发的工作量
曾经我们的上头一次非常糟糕的分配任务。他分配的任务不是熟悉业务的人去做业务复杂的流程，而是让熟悉业务的做一个模块，让不熟悉业务的人负责一个模块，于是乎，我们那段时间，徘徊在界面、业务、DB之间，非常的混乱。
这点我在工作中感受和楼主一样。
也许某个web要用非常长得时间，然后要改了又改。也许好点。
目前我碰到的项目，基本一枪头做完。 过个几年也只改一点，或者增加新功能。
所以这样一个service1个借口有点点鸡肋。 当然接口写好，大家都可以并行开发，这也是个说法。
不过我们这里还是一块自己做的，从jsp service到dao 到sql，一个人做。
因为相比程序，业务更复杂。 一个人理解了业务就做整的一块也许效率更高。楼上说的，你放眼望去中国最不缺的就是coding的人，会前台又会框架，还会DB的人多得是。
欢迎讨论哦~~
一种是平台型的，要提供外部系统数据用的
一种就是分工方便的
哈哈，以中国IT民工的开发效率。
Service ServiceImpl DAO还不是一天写掉了呀。
还关心个啥，你先写接口，实现类慢慢写哦，我调用接口的类可以做了。
会和高效是2码事，我会写SQL，但我写出的SQL能比DBA高效吗？有的人写的SQL，可能要查1分钟，有的人只要1秒，效率差太多。
同样HQL调用，有的人是for嵌套着循环，有的人能写出相对复杂一些的HQL，实际中遇到很多了。其次是效率，实际开发中，最难的就是业务。现在5个人，如果分模块，你要5个人业务都达到一样的水平都去学习来开发快，还是其他人直接做其他的，专门有人熟悉业务的去理解新的业务块，我觉得后者要快很多。我觉得要5个啥都会，样样都半通水的，不如要5个人，各有长处的，然后用一个把他们整合在一起，这样实际开发效率要高很多。因为这样的优势，我是体会过的，体会很深。但是在公司，很多事，也不是我们说的算的，所以很多时候，对于我们而言，难免接口就是一个累赘的东西。起码在我未体会过这种分工之前，我也这么觉得。我干嘛非要一个DAO，我写一个接口，然后我自己再去实现它，我吃饱了，我还不如写一个公共的DAO，然后调用传入对应的对象调用就是了。反正我写的DAO也就是我自己调用，看不懂DAO我可以加注释。做一个接口，没啥意义。
嗯，但是哪怕就是你自己随便定义下接口，事实上，也体现了它的好处是不是，起他们调用的人，知道你的方法名，参数，注释是什么，至于你怎么实现的，要实现多久，那完全不管我的事。我只管把我自己的那层写好了就好了，对不对。
而对于写DAO的人，我根本不关心你复杂的上层业务是什么。我只管写自己的高效SQL即可。
而对于写View的人，我根本不关心你后台怎么处理的，我只管给你对应的参数，然后用你的返回值展示即可了。但是对于太多还在走一人一模块的，那接口的好处就被抹杀了，所以很多人觉得接口鸡肋也很正常的，毕竟我们的项目又不是jdbc，成天吃饱了换各种实现。你今天数据库SQLServer ，明天Oracle，我觉得吃饱了，你直接告诉客户，我这个数据库是oracle 就是了。
呵呵，我有点抬杠了。我觉得Eternalc很多很好。
现实中我也肯定接口的。 问题讨论讨论更清楚。