对于接口越来越迷茫

首先，关于downpour说的“远程调用慢”，这个情景确实跟用不用接口没什么关系，如果一定要有点关系，那就是写一个远程调用的接口，开发阶段使用本地虚拟环境作为接口实现类，这样访问快，开发快；正式部署阶段，换上调用实际远程地址的接口实现类。

然后关于你说的接口无用论，我想说的是，接口用于不用，可以用两句话笼统地概括出来：
对于软件架构师：接口是大用特用，理论上软件架构师暴露给架构应用者的代码，应该全部是接口；
对于普通流水线码农：接口能不用就不用，因为你不够资格，也不需要，接口定义是架构师的工作，码农没有能力定义接口、约束实现。
=================================================================================
接口这任务，从流水线码农身上摘掉以后，码农自己也轻松了很多。

在我们团队，普通组员一个接口都不用写，他们写了我也会让他们删除，因为接口是架构师的任务，他们没有能力定义一个具有约束力的接口。

我们的团队成员，使用通用dao，完成一个页面的开发，只需要建三个文件：
1、视图文件；
2、控制器类；
3、Service类
仅此而已，组员省心省力，不用去写任何配置文件，因为一切都基于命名约定：约定优于配置。
==================================================================================
simple is better，简单就是美
谁的孩子谁抱走，流水线码农不能揽架构师的活，架构师也不该把自己的任务仍给流水线码农。

在我们公司，架构师跟流水线码农界限分得非常清楚，架构师闲的时候可以做点流水线码农的活，但是流水线码农绝对不可以干架构师的任务。
==================================================================================
战斗机设计师只应该设计图纸，不应该去拧螺丝钉；
战斗机组装工人更不可能去设计战斗机图纸，他只可以拧螺丝钉。

我这么说并不是看不起流水线码农，只是实事求是而已，我相信每个流水线码农，在经验丰富，创新能力、独立解决问题的能力提高以后，都有潜力成为架构师。

软件架构设计的六大原则

1.“开-闭”原则(OCP)
Software entities should be open for extension, but closed for modification.
对扩展开放，对修改封闭。

2.里氏代换原则(LSP)
凡是基类适用的地方，子类一定适用。

3.依赖倒转原则(DIP)
要依赖抽象，不要依赖具体。

4.迪米特法则(LoD)
一个对象应该对其他对象有尽可能少的了解。

5.接口隔离原则(ISP)
使用多个专门的接口比适用单一的接口要好。

6.合成/聚合复用原则(CARP)
要尽量使用合成/聚合，尽量不要使用继承。

http://softbeta.iteye.com/blog/1185581

怎么说呢，我的情况比较复杂。其实我想表达的意思是切换实现在实际应用中为我们带来的好处。这和是否强制使用接口并没有关系。我对于这个问题的态度一向比较开放，解决问题可以使用多种方式，接口是其中的一种比较廉价而简单额方式而已。



这个倒真不是在玩自己。我们目前自己做项目的时候有专门的Mock目录来切换生产环境上的某些实现。这主要是由于有的时候某些依赖并不由我们team负责，在一切都未知的情况下，使用接口而不是具体的实现类来进行模拟，可以保证未来我们无需做任何配置上的切换和代码切换。这些切换的工作都会在deploy的时候自动完成。

只能说，在需要的时候用上接口才是正道。单纯说为了使用接口而使用接口，毫无意义可言，只会增加工作量。

你这么说，其实等于是没说。
因为：问题的关键是：什么时候是“需要接口？什么时候是“不需要接口？”
我认为这个问题不应该由普通的流水线码农来回答，何时需要接口、何时不需要接口是软件架构师的任务，对于流水线码农来说，他只有两件事可做：

1、直接使用普通类；
2、创建架构师定义接口的实现类；

普通码农，对于代码只有这两种事情可做。

而具体到我，我留给流水线程序员的余地更小，我的团队成员对于代码，只有一件事可做，那就是：
继承架构师定义的父类

前面的回复没看,直接回答楼主的疑惑

接口不是用来给你修改代码的用的

接口是用来给你扩展功能用的

你只是修改代码,当然用不用接口无所谓
尤其是修改api的时候,接口还会给你带来困难

java所谓的灵活 是包括两部分的

1 是修改的灵活

2 是扩展的灵活

kentbeck在书中说过
    灵活的价值是程序可以改动的更容易。而不是换一个


而接口服务的 是扩展的灵活

但是接口对于减少修改的代价,也是有很大价值的

如何改动的更容易,有个核心

就是:将 影响范围缩到最小，变化只在指定的局部区域作用

在项目中大量使用接口的附加好处,就是能将变化锁定在局部区域.

不论你是要修改,还是要扩展,都会变得简单和直接,易于定位

所以 如何使用抽象才是 一个相对需要经验的能力

他要求我们:

1 不要创建没有价值的抽象
2 不要在没有需求的时候过度考虑 变化和扩展性

这位大侠一口一个“普通码农”
印证了您的照片，指点江山啊

软件开发一定要分清各自的任务，架构师和普通流水线码农有本质的区别，任务不可混淆，这是我工作中得出的最重要一条教训：“绝对不能够由流水线程序员定义全局约束性接口”。

另外：
我这么说并不是看不起流水线码农，只是实事求是而已，我相信每个流水线码农，在经验丰富，创新能力、独立解决问题的能力提高以后，都有潜力成为架构师。

你不要不懂装懂,虚心点

流水线程序员？ 形容的挺贴切，但是不用考虑团队成员的主动性吗？
只做这个，怎么提升团队整体水平