设计模式之迭代器模式 引导篇
- 设计模式
- 时间：2019-09-07 08:08
- 6424人已阅读
🔔🔔🔔好消息!好消息!🔔🔔🔔
有需要的朋友👉:联系凯哥
迭代器模式-引导篇
这两天，比较火的并购新闻就是，网易考拉被阿里以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号凌晨一点多了。各位看官，今日太累了，写不不好，在迭代器总结篇好好不上
上一篇： 设计模式之模板模式总结篇
下一篇： 搜狐号自媒体搬运技巧，搜狐号怎么开通收益