設計模式之迭代器模式 引導篇

迭代器模式-引導篇

這兩天，比較火的併購新聞就是，網易考拉被阿里以20億美圓收購。今後網易考拉再也不姓「網」而姓「阿」了。併購後的網易考拉和阿里的電商系統進行對接。那麼問題來了：在阿里有個早餐店的菜單(CakeHouseMenu)使用的事ArrayList來存放菜單的，考拉有個午飯店的菜單(DinerMenu)使用的是數組結構存放的。如今考拉和阿里合併了，兩個點的菜單也要合併。

咱們先來看看初版設計：

由於馬爸爸說了，國慶以前，必須合併上線，時間緊任務中，腫麼辦？那就再建立一個對象，使用一個菜單對象，將早餐店對象機午飯店對象做爲屬性，調用的時候，直接調用各自對象的就能夠。類圖以下：

顧客來了，點早餐，服務器就從菜單中調用早餐店的get方法。獲得KFC早餐套餐

若是點的是午飯，就從菜單中調用午飯店的getMenuItem方法，獲得快餐一份。

代碼以下：

運行ConventionalMainTest運行結果：

咱們能夠看到，早餐、午飯菜單也都打印出來了。正常啊，沒問題啊。

咱們先來看看服務員(waitress)對象裏面內容：

從上圖中，咱們能夠看到在服務員對象中有早餐店對象、午飯店對象、list類型的items以及數組類型的items。從運行結果上來看，是沒有問題的。可是要是過了N+X天后，馬爸爸又玩起了收購腫麼辦？假設收購的是X店。X店的菜單使用的是hashTable這種類型的。

難道，咱們要在waitress中在添加X店對象同時添加hashTabel類型的items嗎？好，就算收購一個，添加一個能夠。

那麼若是收購了M+N個店。菜單數據類型使用了W種類型。難道，每次都修改waiters這個類嗎？

這樣行是行，可是在後期維護、管理比較麻煩。並且還違背了開閉原則(對修改是封閉的，對擴展是開放的)。那麼怎麼辦呢？

來源：凱哥Java(kaigejava)。

凱哥我的博客：www.kaigejava.com

思考：

咱們在開發的時候，針對接口開發，這樣耦合度也能夠下降。咱們假設兩個飯店的菜單都實現了一個接口。而後waiter對象只要擁有接口對象就能夠。

封裝遍歷的頂級接口，迭代器類圖以下：

咱們用迭代器接口來修改菜單：

說明：

CakeHouseIterator和DinerIterator兩個類是實現了Iterator接口的

修改兩個飯店獲取getIterator的方法。返回對應放到實現iterator接口的對象。

咱們來看早餐店的iterator對象：

在重寫hasNext機next方法。

咱們在來看看修改後的服務員對象：

這個時候，服務員對象只有iterator對象了。已經實現了對早餐店及午飯店的解耦。

再來看看測試類：

在服務員對象添加菜單的時候，是不知道具體添加的是早餐店的菜單仍是午飯店的菜單。實現瞭解耦。

這樣作的好處：

一：類之間實現了鬆耦合

二：就算考拉修改了菜單數據結構也不影響服務員的點餐。也是實現耦合的一種表現。

不寫了，太困了。已經7號凌晨一點多了。各位看官，今日太累了，寫不很差，在迭代器總結篇好好補上。

本文做者：凱哥Java(kaigejava)