查詢列表需查詢其它系統的資料拼裝的重構案例

目前在專案中有兩個版本並行，乙個a版本，乙個b版本，由於a版本並未完全下線，而且a版本是基於業務狀態流的，b版本是基於activiti的，並且資料結構是經過重新設計的，也有乙個申請的入口，那麼我們需要在b版本的每乙個環節的待辦列表尾部查詢到a版本的申請單資料並進行處理。

程式設計師拿到這個需求後理所當然的認為，我在每個節點的查詢的時候進行處理，並且成功的實現了功能。

當我進行**qc的時候我的內心是崩潰的，因為我的原來設計的待辦中根據待辦編碼的列表進行配置的（下次有機會寫一下這個設計），所以我把**一看，裡面增加了許多的**，裡面有根據不同待辦編碼的進行判斷，由於涉及到資訊保安，下面偽**代替.

if(環節1)
私有方法1
else if (環節2)
私有方法1
......
end if

基於上面的分析，做出如下分析，物件導向的介面重點是分析出介面，也就是他們通的東西，其實這個介面就是要做下面幾件事情。

根據不同的待辦編碼分發（通過spring的工廠模式）到不同的介面實現中，將職責分開，達到設計中的平均分配智慧型的效果。

介面其實就是相同的地方抽象並定義出來，實現就是針對抽象的實現，這就是中國人所說的求同存異。