对于接口越来越迷茫

适当使用接口还是有好处的,当然由于没有设计经验,滥用的也不少,这些是很多人总结出来的经验,总的来说,没有什么坏处!!

我感觉就是方便调用的人同时你也能规定一些必须实现的方法

不要为未来做设计，如何将来有变更，再重构。
只为当前做设计。简单、敏捷才是王道。

对接口算是新手吧，以前有接触过，但是后来一直觉得不好用，非常繁琐，就一直不用，直到上个项目开发到一半换人了，遗留了接口就硬着头皮写，现在又要开新的项目了，写顺手了，但是还是对接口迷茫，看了上面的回复感觉有点眉目了，大概这东西需要自己去慢慢琢磨吧。

天朝的国情用接口就是个错误，做项目是给客户做的，不是给自己做的，在需求频繁变化的前提下使用接口就是给自己找麻烦。。。

建议楼主学习设计模式，就比如抽象工厂模式，你一看就明白了，java面向对象，看起来简单，真的理解真的不简单，设计模式大部分都是多态的灵活使用，完全弄明白设计模式的人，我觉得才勉强算得上面向对象了。

完全同意！我基本不做业务级的接口，只做系统级的接口。只用struts2，spring不用，hibernate更不用，这样写系统更高效，更灵活，维护更方面，上手更容易，系统启动速度更快。我认为Spring，Hibernate，JBPM甚至Hadhoop都把问题复杂化了，因为这些框架做得太通用了，而且更多的是考虑到国外较为成熟的IT环境，结果对我们java程序员来说就是把问题复杂化了。其实看一下别的语言，哪个像j2ee这么多框架的，像spring这样用xml去配置类关系的？像hibernate这样为写一个sql搞得这么麻烦的？我更推荐轻使用量级的东西，因为业务层面最关心的只有四点：质量，功能，性能，成本。

1 接口可以继承
2 各实现类之间可以继承或者注入某些抽象出来的Service接口做成员变量


综上2点发现，老抛的话是对的，业务越复杂，越能发现，接口的重要性，而且接口的数量明显不够，并非横向填充接口数量，而是业务过程中某些巨大接口的功能需要更多的接口抽象更多的功能定义

举例，业务是，登录，发帖，找到讨论接口的帖子，回帖，退出
写一接口，名字是 访问并登录并发帖并找到讨论接口的帖子并回帖并退出Service
看看这接口名字，你就知道为什么你觉得接口没必要用，换了我我也觉得是没必要
这接口强大的，我要想写个登录以后发个站内信就退出，这接口还真约束了我，TNND
回头再看看业务的分析，每个逗号都可以抽象为一个接口，老抛说的接口数量不够，就这意思

讲我的一点理解，在企业里，资深的架构师设计好一套架子之后，一般需要大量的码农做一些service，dao之类的技术含量较低的工作，而整个项目的接口设计好了，码农们一般就写写实现，然后比较资深的调用接口，做复杂的业务逻辑，这样分工合作，比较高效

感觉接口不错啊 我现在就在用，很方便的