面向對象設計里有一點大家已基本形成共識，就是面向接口編程，我想大多數人對這個是沒有什么覺得需要懷疑的。
問題是在實際的項目開發中我們是怎么體現的呢？ 難道就是每一個實現都提供一個接口就了事了？反過來說，你有時候有沒有覺得接口是多余的事？ 又或者，你僅僅是覺得現在類似spring這樣的框架已習慣用接口這種方式而心存當然。
設計模式解析里提到了面向對象設計考慮的幾個視角，
一個是概念層，一個是規約層，一個是實現層。我如果沒有猜錯的話，實際上我們大多數人的眼睛一直是盯著實現層的，而這正是面向對象設計所極力避免的，即你不要在一開始就關注這些細節，你要關注的是規約（接口）.
對于實際項目開發來說，如果我們把實現的過程分為多個階段的話我們不妨這么劃分，第一階段，根據client端的需要去設計我們的規約(interface),在這個階段任何實現都沒有，所有的任務就是定義接口所需要的職責，以及所需要的一些po,vo;第二階段，實現前面定義的規約。
而以前我是怎么做的呢？ 我是交叉作的，即假模假樣的定義一個接口（其實我心里在想這個東西有屁用）,然后定義了一個方法，然后就立即去實現這個方法，再然后我又定義一個方法，繼續去實現，我現在終于想通了，這樣好累，效率很低，最重要的是，這不屬于真正的設計。
現在我是怎么做的呢？比如一個list.jsp里需要查詢，列表，然后看明細信息，然后增加信息，我會第一步在接口里定義完(這個過程會有整體設計的意識),毫不關心底層實現(數據庫、事務)，我的目標就是"我想要這個功能，我想要那個功能"，至于那個功能怎么實現在第一階段我認為那不是我的事情(盡管這個事情最終還是由我來做) .大家看這個過程和前面的過程有什么本質的不同呢？ 就是分層的概念更加明顯，你的工作更有層次，每次都有先設計再實現的步驟，而前面那個過程很容易就讓你不知不覺地陷入純實現的陷阱中。
一點感想，歡迎大家拍磚。
原帖地址：
http://m.tkk7.com/alex/archive/2007/03/12/103185.html