面向对象设计里有一点大家已基本形成共识，就是面向接口编程，我想大多数人对这个是没有什么觉得需要怀疑的。
问题是在实际的项目开发中我们是怎么体现的呢？ 难道就是每一个实现都提供一个接口就了事了？反过来说，你有时候有没有觉得接口是多余的事？ 又或者，你仅仅是觉得现在类似spring这样的框架已习惯用接口这种方式而心存当然。
设计模式解析里提到了面向对象设计考虑的几个视角，
一个是概念层，一个是规约层，一个是实现层。我如果没有猜错的话，实际上我们大多数人的眼睛一直是盯着实现层的，而这正是面向对象设计所极力避免的，即你不要在一开始就关注这些细节，你要关注的是规约（接口）.
对于实际项目开发来说，如果我们把实现的过程分为多个阶段的话我们不妨这么划分，第一阶段，根据client端的需要去设计我们的规约(interface),在这个阶段任何实现都没有，所有的任务就是定义接口所需要的职责，以及所需要的一些po,vo;第二阶段，实现前面定义的规约。
而以前我是怎么做的呢？ 我是交叉作的，即假模假样的定义一个接口（其实我心里在想这个东西有屁用）,然后定义了一个方法，然后就立即去实现这个方法，再然后我又定义一个方法，继续去实现，我现在终于想通了，这样好累，效率很低，最重要的是，这不属于真正的设计。
现在我是怎么做的呢？比如一个list.jsp里需要查询，列表，然后看明细信息，然后增加信息，我会第一步在接口里定义完(这个过程会有整体设计的意识),毫不关心底层实现(数据库、事务)，我的目标就是"我想要这个功能，我想要那个功能"，至于那个功能怎么实现在第一阶段我认为那不是我的事情(尽管这个事情最终还是由我来做) .大家看这个过程和前面的过程有什么本质的不同呢？ 就是分层的概念更加明显，你的工作更有层次，每次都有先设计再实现的步骤，而前面那个过程很容易就让你不知不觉地陷入纯实现的陷阱中。
一点感想，欢迎大家拍砖。
原帖地址：
http://www.blogjava.net/alex/archive/2007/03/12/103185.html