对于接口越来越迷茫

看到上面众多讨论项目角色任务的言论，我想提醒一下，
此贴是讨论什么时候用接口，接口的实际应用场景，而不是讨论该什么人用，什么人不该用。
－－－－－－－－－－－－－－－－－－－
同意这些应用场景
1、通用DAO接口；
2、收发Email接口；
3、数据导入、导出接口；
4、Web Service交互封装接口；
5、动态表数据保存逻辑封装接口；
6、JMS封装接口；
7、服务器端推送封装接口；
。。。。。希望大家继续补充

架构师不用写文档和分析需求
在我个人的理解看来貌似你说的这个架构师，在一些地方叫做 高级程序员，也叫高级码农

你这么说也可以，软件架构师就是一个优雅点的别称，其实质还是打工的码农，不过软件架构师这个码农不用在流水线上完成一环一环的业务模块，不用自己去拧一个个的螺丝钉。
软件架构师只需要去设计软件底层结构、技术性模块封装，说白了，软件架构师这个码农的任务是：
1、给流水线码农定义一些工作动作和工作规范：比如拧螺丝应该向右旋转，不能向左旋转；3号轴承应该装在C型槽上等等；
2、为流水线码农设计一堆工具：比如流水线码农用的板子、改锥、锤子等等，流水线工人直接拿来就可以用，不用工人自己再去制造锤子、改锥；

而接口的设计，恰恰就是“设计工作动作和定义工作规范”，这个是软件架构师的主要任务。

架构要干的事多了去了



这是编程规范,还有个流程单元叫review:这个现在也基本不用架构参与




有个工种叫做api设计师,还有些小团队叫通用开发组,



还有种高科技组织叫 QA ,掌管一切规范和流程,而制定流程和规范的需求来源于一线开发人员

我觉得你说的跟我遇到的比较一致

名字叫什么都行，总的一句话就是：
接口设计不是流水线码农的工作！

回到楼主的问题，我的回答是：
如果你要设计软件架构，那么你应该大方地使用接口；
如果你只是在流水线上完成业务模块的开发，那么你不用设计接口，也不应该设计接口。







换一个表述就是：
1、软件架构层：大方使用接口，做到“对外暴露的全是接口”，“让普通使用者接触到的架构层代码全部是接口”
2、软件应用层：接口能不用就不用，一切以简单明了为主旨。

分清楚了软件架构层 和 普通应用层，“接口什么时候使用”的问题自然就清晰了。

server和server直接的交互太少了，还有项目直接的耦合度不够。当你在继续做大的时候就发现了。

你这个图,自己做的？同意你的观点，我在想一个接口只有一个实现类，一个servier层的方法中只有一行调用dao层的方法，这样方法有意思吗

上面那两个图是我做的，下面这个漫画肯定不是我做的，是西乔美女的作品。

我认为，业务的烦杂,能过分层很难来解决,
如crud这种，我现在直接在action层搞定，复杂的业务，建个server类 的方法来解决

没必要action->IServer->serviceImpl->IDao->daoImple， 累不累呀，代码分开都不知道找哪个类