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

迭代器模式-引導篇

這兩天，比較火的并購新聞就是，網(wǎng)易考拉被阿里以20億美元收購。從此網(wǎng)易考拉不再姓“網(wǎng)”而姓“阿”了。并購后的網(wǎng)易考拉和阿里的電商系統(tǒng)進行對接。那么問題來了：在阿里有個早餐店的菜單(CakeHouseMenu)使用的事ArrayList來存放菜單的，考拉有個午餐店的菜單(DinerMenu)使用的是數(shù)組結構存放的。現(xiàn)在考拉和阿里合并了，兩個點的菜單也要合并。

我們先來看看第一版設計：

因為馬爸爸說了，國慶之前，必須合并上線，時間緊任務中，腫么辦？那就再創(chuàng)建一個對象，使用一個菜單對象，將早餐店對象機午餐店對象作為屬性，調用的時候，直接調用各自對象的就可以。類圖如下：

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

如果點的是午餐，就從菜單中調用午餐店的getMenuItem方法，得到快餐一份。

代碼如下：

運行ConventionalMainTest運行結果：

我們可以看到，早餐、午餐菜單也都打印出來了。正常啊，沒問題啊。

我們先來看看服務員(waitress)對象里面內(nèi)容：

從上圖中，我們可以看到在服務員對象中有早餐店對象、午餐店對象、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對象了。已經(jīng)實現(xiàn)了對早餐店及午餐店的解耦。

再來看看測試類：

在服務員對象添加菜單的時候，是不知道具體添加的是早餐店的菜單還是午餐店的菜單。實現(xiàn)了解耦。

這樣做的好處：

一：類之間實現(xiàn)了松耦合

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

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

本文作者：凱哥Java(kaigejava)