设计模式之迭代器模式 引导篇

迭代器模式-引导篇

这两天，比较火的并购新闻就是，网易考拉被阿里以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)

思考：

我们在开发的时候，针对接口开发，这样耦合度也可以降低。我们假设两个饭店的菜单都实现了一个接口。然后waiter对象只要拥有接口对象就可以。

封装遍历的顶级接口，迭代器类图如下：

我们用迭代器接口来修改菜单：

说明：

CakeHouseIterator和DinerIterator两个类是实现了Iterator接口的

修改两个饭店获取getIterator的方法。返回对应放到实现iterator接口的对象。

我们来看早餐店的iterator对象：

在重写hasNext机next方法。

我们在来看看修改后的服务员对象：

这个时候，服务员对象只有iterator对象了。已经实现了对早餐店及午餐店的解耦。

再来看看测试类：

在服务员对象添加菜单的时候，是不知道具体添加的是早餐店的菜单还是午餐店的菜单。实现了解耦。

这样做的好处：

一：类之间实现了松耦合

二：就算考拉修改了菜单数据结构也不影响服务员的点餐。也是实现耦合的一种表现。

不写了，太困了。已经7号凌晨一点多了。各位看官，今日太累了，写不不好，在迭代器总结篇好好补上。

本文作者：凯哥Java(kaigejava)