对于接口越来越迷茫

接口定义的是规范，注意的是输入、输出。

系统与系统间的接口、模块与模块间的接口、类与类之间的接口都是如此。

接口实际上是定义了标准，隐蔽自身的实现细节。

我把接口理解为契约，就是规范，你不遵守就会吃亏 哈哈

我把接口理解为契约，就是规范，你不遵守就会吃亏 哈哈

楼主，我这么跟你说，好的架构体现在接口和切面上。切面暂且不谈。
先说接口，假如有一个系统，方方面面的功能都抽成了接口。这些接口就是整个系统的骨架。
每个接口中定义的函数以及函数的返回值类型等等。
现在系统开发完毕，并且完全遵照这些个接口来实现。
OK，有一个模块需要扩展一些，比如在原来的查询结果上进行一些筛选和过滤。
A接口有AImpl实现,其函数Girl getGirl（）要过滤掉非洲和泰国的妹子。这时候怎么办呢？
一种办法是去看原来的源码，在里面改一下。这时候第二个人就需要改第一个人遗留的代码。
(这里不说利用接口实现动态代理完成事务控制等等)
可是，第三个人再来改呢？最后这些代码被改的谁也看不懂了。
另外一种办法是重新写个A接口的实现AImpl2，并且该实现类持有AImpl类。这样AImpl2的Girl getGirl()函数内部
调用AImpl的getGirl()，将其结果进行删选就足以。丝毫不必关心AImpl的代码。

接口可以让我们只关心传入参数和返回结果。
只有控制整个项目脉络的人才懂得接口的重要性。上面的第二种情况如果持续递增，会累积出来哪个模块需要该重新写个实现了。
假设A接口的实现因为需求改变而一直衍生和传递调用，必定有损性能。
这个时候一看A接口的实现类有好多，很清晰的知道这个模块需要重写了。而新人接手时，只需要根据需求完成接口里定义好的函数就可以了。
其它的代码调用仍旧是用A接口类型接收，而不必去改动其他依赖代码。

接口的意义只有那些去定义接口的人才明白，而不是为了定义接口而写接口。

废这么多话，不知道楼主能看懂么。

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