滥用接口的项目组成员,如何说服！
目前在公司带一个团队进行一套系统的开发，一个兄弟乱用接口，还理直气壮地说现在都讲究“面向接口编程”，无语，例：我们系统是采用Hibernate + Spring mvc去开发的，一个功能模块基本包括Entity , DAO , Service，这个兄弟为了面向接口编程，所有的Service都写了一个接口，在去实现这个接口，比如：一个城市管理，非要写一个ICityService的接口
interface ICityService{
List<CityEntity> query(....);
CityEntity edit(String id);
void del(String id);
.......
}
在去实现这样一个接口，后边开发的什么国家管理阿，港口管理阿，都是这样一堆接口，还说，这样是为了维护方便，以后如果要改只需要重新实现接口就好了，不需要改以前的代码。
本人非常反感这么去开发，为了设计而设计，为了接口而接口，导致我如果要加一个方法，必须先修改接口，在去修改实现，这不是脱裤子放屁吗。个人认为接口一定是为了解决一个共性问题，来提高系统的灵活性和可维护性，而非解决这样的问题，但是你又不能说程序有错误。请各位帮我想想，该如何说服这个个性比较倔强的兄弟。当然如果有赞同这种做法的人，谈谈你们的观点。 --------------------编程问答-------------------- 修改接口,在去修改实现好像不费劲吧，他爱写你就让他写去呗。 --------------------编程问答-------------------- 不写接口，你怎么用spring注入？怎么用AOP？ --------------------编程问答-------------------- 这没什么吧，反正都是他自己捣鼓，就不要去管了，能完成你预定的目标就行了。 --------------------编程问答-------------------- LEADER不合格，鉴定完毕！ --------------------编程问答--------------------
这么可以没有。
制定项目开发规范。。。。。 --------------------编程问答--------------------
这个可以没有 呵呵
LZ可以让他看看敏捷软件开发、原则、模式与实践
这属于过度设计
如果真的有需要才会用到接口
因为一般service 不需要多态
所以接口也没什么用 --------------------编程问答--------------------
正因为是Service，事务一般都是放在这层管理的，难道不是用AOP么
而且以后要检查某个模块的性能问题，只需要配一个切面就可以了。
还有输出LOG，异常处理，很多很多的用法，方便的很。
我们做几百人月的大项目，这种接口是强制必须加的。 --------------------编程问答-------------------- 对于大项目的应用，接口是必须的，这样可以并行开发，前后台分离，每人专注自己的部分
同时接口开发还能迫使大家遵守一定的规约，这样一个service，就可以很容易的被应用到不同的地方
反过来，当用不同service的时候，我们不用去详细的看service怎么写的，这不是我们关心的东西，我们只要调用然后告诉我结果。 --------------------编程问答-------------------- 嗯，这种接口是要的撒 --------------------编程问答-------------------- 麻烦是麻烦了点 但是大家都遵守的话 就好了 --------------------编程问答-------------------- 如果是多人合作的项目，用接口还是好的选择，但如果2-3个人在开发，可能会造成滥用接口。 --------------------编程问答-------------------- Service？为什么不用接口来做？ --------------------编程问答-------------------- 按楼主高见什么叫不乱用呢？你说别人为了接口而接口，你总得有个理由吧？
“导致我如果要加一个方法，必须先修改接口”，这不是用不用接口的问题，是开头没设计好，或者确实需求变化而引起接口变化。就算不用接口，用类，难道就不用加方法了？再退一步，类都不用，难道就不用加函数了？ --------------------编程问答-------------------- 补充：
个人认为是否用接口（抽象类）的原则之一在于：是否要对外屏蔽实现的变化。如果楼主纯粹是因为修改时要多改一个地方才发这样的牢骚，我觉得就是楼主的问题了。另外建议用好UML工具的代码生成。 --------------------编程问答-------------------- 这是一个纠结的问题，还是机器好 哥不和人打交道 --------------------编程问答--------------------
--------------------编程问答--------------------
很好 很强大
--------------------编程问答--------------------
--------------------编程问答--------------------
--------------------编程问答--------------------
我还没见过谁在借口定义好了然后随便去接口里加方法的，而且是任意的。接口不是设计有问题就是整个模块划分设计有问题。 --------------------编程问答-------------------- 组件使用接口已经等于告诉，这个组件就提供了这么多功能。
如果想有就用不想用的话那就让组件实现者都加另外一个接口
支持你定制的方法。要想你这样在定好的接口上乱加东西，那么
你想过没有别的程序要是在使用这个接口那不乱套了。 --------------------编程问答--------------------
顶6楼 --------------------编程问答-------------------- service接口是肯定需要的，不过根据项目大小，可以考虑是否订制dao接口。
要说乱字，还谈不上吧 --------------------编程问答-------------------- 接口是组件跟外部的一种契约，契约定好了才会去实现组件的。
违背契约来使用组件是“不道德的”。设计接口不存在滥用的
问题，因为现在很多软件的开发都必须分块进行的，上层调用
不会去关心下层的实现的，只关心提供的接口。在开发的过程
中对于系统的划分上，使用过程式的开发来思维来规划组件那才
是导致问题的原因。 --------------------编程问答-------------------- 呵呵 有人居然认为使用接口是为了多态，真是莫名其妙！ --------------------编程问答-------------------- 很难的样子啊 --------------------编程问答-------------------- --------------------编程问答-------------------- --------------------编程问答--------------------
使用接口最主要的目的的确是为了多态 --------------------编程问答--------------------
那请问这个实现了接口的组件存在还有价值吗？ --------------------编程问答-------------------- 呵呵！让他定义吧！ --------------------编程问答-------------------- 切确的来说组件实现了功能，而功能对外发布是通过接口完成。
要搞清楚实现了功能的组件基本上不存在需要继承的必要了。
除非是这个组件功能不能满足需要，这个问题是组件的规划问题了，
不是组件的接口的问题。 --------------------编程问答-------------------- 你让他身上插满接口,到时候,喝水一个,吃饭一个,大小便一个,反正一个功能一个,试试,方便不 --------------------编程问答-------------------- 到底怎么个滥用法阿 --------------------编程问答-------------------- 在一个功能独立的组件这层看接口是组件对外发布其功能，
接口不是提供外部定制组件行为而存在的。
--------------------编程问答-------------------- 这个问题确实好难解决。
现在许多项目不论大小都在Service层和Dao层都加了一层接口，说实话，其实我也有些疑虑，真的都有必要吗？如果一个接口需要多套实现类来支撑系统，则这个接口是必须的，反之我也觉得可以不用。
就好像接口Set，如果注入HashSet，则只需要查询快；如果哪天需要排序，则注入TreeSet。（当然，更新的效率就降低了），用哪个根据项目需要决定。
可是，业务层真的需要那么多实现方案吗（都需要注入不同的Set吗？）？对大部分项目来说，其实未必需要。
所以，在一个具体项目中用不用一个设计方案，还是要仔细评估一下是不是真的理解这个方案，而不是形而上学和跟风...
所以，总的来说，我还是支持楼主，用实例说服他（或则让他举个真正有用的实例），如果还不行，就@#￥#%@%#￥%他。因为团队的一致性远比一个人个人能力发挥要重要...
楼下继续......
--------------------编程问答-------------------- 楼主说的也没错，接口就是用于共性的，没有共性就没有接口存在的必要，确实就是过渡设计。
如果仅仅为了调用的统一，模块的分离，建立函数原型就可以了。
其实接口编程并不麻烦，如果你这个组员确实能够做到全局的接口规划(就是说接口不是边做边定义并且定义的接口不会改来改去)，就应该听取他的建议和他讨论一下利弊(也许在某些时候你会改变主意的)。组长要做的一个关键事情就是全体人员在架构层次上编程模式的统一，这个是最重要的。 --------------------编程问答-------------------- --------------------编程问答-------------------- 是项目大小问题，一些规范只有在更大的项目中才能显示出作用。接口没什么罪过，好用就用，不好用就不用。 --------------------编程问答-------------------- 这样的兄弟，只要不当Leader，那将是多么好的一个同志呀，严格执行规范，不怕自己麻烦。
LZ不要企图说服他，而是支持他使用接口，而且希望他能给出更合理的设计，比如把城市、港口、国家的共性进一步抽象，提取共通的东西，而不是只有一层ICity接口。
其实改正过度设计的最好方法，就是让设计者自己体味其设计的过度。
btw，LZ的公司厉害呀，做国家管理......这得多大的一个系统呀！ --------------------编程问答-------------------- 哪位兄弟做法是正确的。
如果换用你的那种架构，要作分布式就要动手改程序了。
我是搞.net 的，估计java的情况也差不多的了。
一个站点只能使用一个CPU核心，不信写个死循环，看看CPU占用。
做好了接口，搞分布式的时候可以把负载分到各个CPU核心，各个服务器里面，是很方便的。
改改配置文件里面的相关service的地址就得了。 --------------------编程问答-------------------- 每个人的做事方法不一样 --------------------编程问答--------------------
多态是类的特性，不是接口的特性。这个提法本身就是错误的。 --------------------编程问答-------------------- 发现这里有些人一提到接口，首先想到的是hibernate、service、dao、注入，我想问下，如果没了hibernate这些，就不需要接口了？
这是不是搞java的程序员的思维定势呢？ --------------------编程问答-------------------- --------------------编程问答-------------------- 还是需要的。 --------------------编程问答-------------------- 制定项目规范，项目组成员按规范完成任务。 --------------------编程问答-------------------- 楼主好像对接口理解有偏差。。。。无语 --------------------编程问答-------------------- 接口是规范，大家定义好的，商量好的。应该遵守 --------------------编程问答--------------------
--------------------编程问答--------------------
还是有一个公共的借口好啊，让每个模块的借口来继承这个公共接口，如果模块有个性的东西，就在模块接口中添加，如果没有就不用理会了。这样既维护了公共接口的统一，又实现了模块的个性 --------------------编程问答-------------------- 大项目要接口。lz的项目用spring，最好就用接口注入 --------------------编程问答-------------------- 看了大家的评论，学到了很多东西，收获良多。 --------------------编程问答-------------------- 对修改关闭，对扩展开放。如果使用这种设计模式，接口中提供的功能要经过良好的设计，不能随便改动。如果改动很频繁，说明接口设计很差了。导致不断的扩充， --------------------编程问答-------------------- --------------------编程问答-------------------- 扣奖金好了 --------------------编程问答-------------------- 我也觉得没有这个必要
我当初这些参数 直接放到了一个PramBiz 里面 省事 --------------------编程问答-------------------- 这样开发也没什么问题啊
只要不是技术问题，都不是问题
看你说的好些只是觉得麻烦而已，懒惰的程序员是产品的杀手。 --------------------编程问答-------------------- 大棒加糖果 --------------------编程问答--------------------
顶44楼。有很多家伙就是为了模式而去模式不是为了应用而去模式。
开来CSDN上有星星的都是胡混的，懂得不多，还老是固执己见。 --------------------编程问答-------------------- 如果楼主非要执意纠正，那么8楼提到的接口的用途，就可以作为一个好的说辞。
不过在这个问题上得过且过似乎是个可行的选择，能按时完成任务，不出错，这样写也没什么。 --------------------编程问答-------------------- 无语了。。。开了吧。。。 --------------------编程问答-------------------- 学习了一下
我看了一下 其实吧 不管是支持哪一边的
都没有说service用接口有不好的效果。
唯一不好的地方可能就是麻烦点。。
所以说至少没有坏处 也就多点代码 --------------------编程问答-------------------- --------------------编程问答-------------------- --------------------编程问答-------------------- 接口是规范，大家定义好的，商量好的。应该遵守 --------------------编程问答-------------------- 可以先定义好项目规范文档，刚开始就说好，后面要大家去遵守问题应该不大 --------------------编程问答-------------------- 首先分析LZ的感觉是不用接口还是用接口过多不好？
我看LZ的意思应该是适当的使用接口，而不是滥用接口。
LZ有这样的问题存在的话，应该说LZ的项目组的架构是存在问题的，按一般的开发流程而言，接口应该由架构师来确定的，只有架构师是了解整个后台系统的，他能确定哪些地方使用而哪些不需要。
如果LZ要说服程序员的话，应该从接口的本质去说，而不是像提出问题的那样。
LZ可以考虑下接口的本质是什么以及我们为什么要使用接口
其实像LZ举的例子，的确是过度使用接口了。可以把所有的Del,query,modifed的操作定义为一个接口，具体的实现呢看后台的设计了，加参数或配置什么的。
--------------------编程问答-------------------- --------------------编程问答--------------------
我也是 --------------------编程问答-------------------- 内容存入剪贴板
--------------------编程问答-------------------- 大家说的都还有道理。 --------------------编程问答-------------------- 一头雾水啊,学习 --------------------编程问答-------------------- 我认为接口是要的，但是不要随便写接口，找到共性，再写一个接口。这样可以简易代码，灵活程序。 --------------------编程问答-------------------- 我是来赚积分的，顺道把帖子顶上去 --------------------编程问答-------------------- 编程规范而已,我觉得不涉及设计模式,要不你规范他,或者被他规范... --------------------编程问答-------------------- 爱咋地咋地 --------------------编程问答-------------------- 接口是要的
只是楼主的同事的接口设计的过于羸弱，不够稳定..
从另外一方面来说楼主的项目管理架构能力有待加强，难道你们在开始这个项目前没有项目开发规范吗，没有同意的架构吗？
各自为战，最后和在一起就是浆糊... --------------------编程问答-------------------- --------------------编程问答-------------------- 平添耦合性 --------------------编程问答-------------------- 如果您说不出他的错误，您就要看看自己是不是错了。
或者用泛型接口:
interface IService<Entity>{
List<Entity> query(....);
Entity edit(String id);
void del(String id);
.......
}
--------------------编程问答--------------------
看得一头雾水大家都好像没说这样有什么不好，只是有点麻烦
如果不注意设计，那么能不能就这个例子说说实际的设计方式
比如：
现在的方式是一个城市管理，非要写一个ICityService的接口
在来个国家管理，写一个接口
再来个xxx,再写一个接口
如果不这样设计，请提供一个设计的方式，对比下撒
要不然真是一头雾水，等待学习中呢
--------------------编程问答-------------------- interface IService<Entity>{
List<Entity> query(....);
Entity edit(String id);
void del(String id);
.......
}
--------------------编程问答-------------------- 我曾经也以为接口是必须的。时间长了才明白，面向接口编程是一句最大的谎言。
类的public方法本身就是接口、就是契约，为什么我们要增加一个复杂度呢。
如果是说为了AOP而接口，那纯属语言实现问题，换种编程语言吧。
现在的接口感觉就像C++的头文件，我还是喜欢DRY原则。
支持楼主！ --------------------编程问答-------------------- 接口这样用我到可以接受,
我无法接受的是直接在asp.cs页面吧所有业务弄完或者直接一个sql语句就到dal访问数据库完事的设计 --------------------编程问答-------------------- --------------------编程问答-------------------- 软件工程 欺骗很多. 当今理论一大堆, 没见开发速度 如何迅猛.
想起一位大师的话,大意是说 他所认为的 唯一有效的 软件复用 只有 函数库, 仅此而已.
那些所谓 为了以后扩展容易的人, 你们真的确定以后 扩展的时候 节约了时间? 有相似的2个项目 进行过对比了吗? --------------------编程问答-------------------- lz既然使用spring，我觉得就应该注入接口 --------------------编程问答--------------------
顶你！ --------------------编程问答-------------------- 关于接口的问题，我也一直觉得很矛盾，有的地方需要有的地方不需要。
自己总感觉这个度拿捏得不好。
我现在的观点是，如果是供外部调用的，你来提供服务，那么最好使用接口。
这样对外提供的方法统一，但是前提的一定要充分的验证你的接口定义的稳定性。
对内自己的实现是自己的事，不需要外界关心。达到这个目的，也就可以了。
还有关于有人提出的城市管理，国家管理，地区管理之类的，我觉得完全可以抽象出同一个接口
然后这三类管理类实现这一个接口就可以了。
因为这三类业务实体的管理貌似都是大同小异的。
比如 国家、城市、地区的添加
你可以写出一个接口方法 public void add(Object entity);
查询也是 public List<Object> queryForList(Object param);
我觉得这样也就减少了接口的个数
但是这样做的前提是你确实分清楚了，这三类业务实体的管理，确实在很多行为上都是类似的。
共性的操作比较多，才可以这么做
菜鸟愚见，请大家批评 --------------------编程问答-------------------- 那些接口的支持者们，你们具体分析过吗，你们见过项目有N个接口，结果大部分接口各自就
一个实现类，根本就没有起到接口的意义，你们觉得这样的实现是不是很牛逼，很有水平。
把代码搞复杂就现的你们很有水平。不少人就会照样画葫芦，不用接口害怕被说没水平。装B的烧饼！
人家用接口把系统做的容易扩展易于维护，他们用就是不知道为啥要用接口，就是照搬！ --------------------编程问答-------------------- 不懂。。 --------------------编程问答-------------------- 分什么项目吧。
有的项目定义接口还是必要的。 --------------------编程问答-------------------- 新手上路，老鸟避让。 --------------------编程问答-------------------- --------------------编程问答-------------------- --------------------编程问答-------------------- 接口是为了扩展好。。。
依赖小。。。。 高内聚低偶合。。。 --------------------编程问答--------------------
这是因为你没能体会出类和接口在设计上的语义区别
在OOP中，类的语义是一样事物，而接口的语义是表示拥有一种能力。因此现代OOP中类只能单根继承，但是接口可以实现多个（表示拥有多种能力）
这也是我说这里有些人一谈到接口，就首先想到AOP、注入的原因。这些人用接口，或者判断是否需要用接口，并不是从需求设计的角度出发的，自然得不到正确结论。如果有需要的话，哪怕100个接口也要用，没需要的话，1个也嫌多。 --------------------编程问答--------------------
+1 --------------------编程问答--------------------
补充：Java , Java相关
