面向接口编程把握不好

这就象软件工程里常说的“过分设计”。你不可能从一开始就认识到所有的可能需要替换实现的类。只能从那些比较明显的开始，然后在实现过程中逐渐refactory,refine.

上面是从细的方面来说。对于大的软件架构方面，一般一开始就会对一些层次是否实现面向interface做出决定。比如service层,dao层,这些即使从现在的需求来看没有改变实现的可能性，一般来说采取面向interface的方式也是更有吸引力的，而且借助一些框架如spring之类的，可以大大减少实现面向接口编程的开销（比如它提供了通用的xml定义bean的框架，不用我们自己实现专有的xml实现，避免了factory等的应用等等）。
以上只是私人观点

对于各种大的层面，定义接口是肯定需要的，这样可以隔离不同层次，实现下层对上层的透明。显然给外界提供服务的最好提供接口。

但是进入某个层面，这些层面里面有很多协作的class，从微观角度看，这些class也是在为别的class提供某种服务。但是现在要区分这种class是为谁提供服务，如果为某个层面内部的class提供服务，就不必提供接口，如果这样的class是为别的层提供服务，那么显然应该定义接口。

形象的描述就是，在某层边际的class，需要与别的层次交互的class都需要定义接口，而处于某层次内陆地区的class就不一定要有接口了。

这是我自己想了半天总结的，不知道怎样，请各位多给我点建议。

其实哪有这么麻烦。说穿了就一个原则：如果你需要在同一个契约之下提供不同的实现，那么就声明接口；否则直接一个class就OK。

面向接口编程关键是掌握其目的：解耦；解耦有单独类之间解耦，有组与组或模块与模块之间解耦，他们之间联系依靠接口，这是面向接口编程的本义，建议研究GoF设计模式会有更深入感受。