迭代器模式-引導篇
這兩天，比較火的并購新聞就是，網(wǎng)易考拉被阿里以20億美元收購。從此網(wǎng)易考拉不再姓“網(wǎng)”而姓“阿”了。并購后的網(wǎng)易考拉和阿里的電商系統(tǒng)進行對接。那么問題來了：在阿里有個早餐店的菜單(CakeHouseMenu)使用的事ArrayList來存放菜單的，考拉有個午餐店的菜單(DinerMenu)使用的是數(shù)組結構存放的?，F(xiàn)在考拉和阿里合并了，兩個點的菜單也要合并。
我們先來看看第一版設計：
因為馬爸爸說了，國慶之前，必須合并上線，時間緊任務中，腫么辦？那就再創(chuàng)建一個對象，使用一個菜單對象，將早餐店對象機午餐店對象作為屬性，調用的時候，直接調用各自對象的就可以。類圖如下：
顧客來了，點早餐，服務器就從菜單中調用早餐店的get方法。得到KFC早餐套餐
如果點的是午餐，就從菜單中調用午餐店的getMenuItem方法，得到快餐一份。
代碼如下：
運行ConventionalMainTest運行結果：
我們可以看到，早餐、午餐菜單也都打印出來了。正常啊，沒問題啊。
我們先來看看服務員(waitress)對象里面內容：
從上圖中，我們可以看到在服務員對象中有早餐店對象、午餐店對象、list類型的items以及數(shù)組類型的items。從運行結果上來看，是沒有問題的。但是要是過了N+X天后，馬爸爸又玩起了收購腫么辦？假設收購的是X店。X店的菜單使用的是hashTable這種類型的。
難道，我們要在waitress中在添加X店對象同時添加hashTabel類型的items嗎？好，就算收購一個，添加一個可以。
那么如果收購了M+N個店。菜單數(shù)據(jù)類型使用了W種類型。難道，每次都修改waiters這個類嗎？
這樣行是行，但是在后期維護、管理比較麻煩。而且還違背了開閉原則(對修改是封閉的，對擴展是開放的)。那么怎么辦呢？
來源：凱哥Java(kaigejava)。
凱哥個人博客：www.kaigejava.com
思考：
我們在開發(fā)的時候，針對接口開發(fā)，這樣耦合度也可以降低。我們假設兩個飯店的菜單都實現(xiàn)了一個接口。然后waiter對象只要擁有接口對象就可以。
封裝遍歷的頂級接口，迭代器類圖如下：
我們用迭代器接口來修改菜單：
說明：
CakeHouseIterator和DinerIterator兩個類是實現(xiàn)了Iterator接口的
修改兩個飯店獲取getIterator的方法。返回對應放到實現(xiàn)iterator接口的對象。
我們來看早餐店的iterator對象：
在重寫hasNext機next方法。
我們在來看看修改后的服務員對象：
這個時候，服務員對象只有iterator對象了。已經實現(xiàn)了對早餐店及午餐店的解耦。
再來看看測試類：
在服務員對象添加菜單的時候，是不知道具體添加的是早餐店的菜單還是午餐店的菜單。實現(xiàn)了解耦。
這樣做的好處：
一：類之間實現(xiàn)了松耦合
二：就算考拉修改了菜單數(shù)據(jù)結構也不影響服務員的點餐。也是實現(xiàn)耦合的一種表現(xiàn)。
不寫了，太困了。已經7號凌晨一點多了。各位看官，今日太累了，寫不不好，在迭代器總結篇好好補上。
本文作者：凱哥Java(kaigejava)
另外有需要云服務器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內外云服務器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務器、裸金屬服務器、高防服務器、香港服務器、美國服務器、虛擬主機、免備案服務器”等云主機租用服務以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應用場景需求。
重慶分公司
重慶分公司
