HeadFirst 设计模式学习笔记9--迭代器模式

1.本节的一个话题引子是一个餐厅,它提供早餐和午餐,但是在订制菜单的时候,早餐(Pancake)和午餐(Dinner)的实现却造成了一些麻烦。订制早餐的菜单是用ArrayList这样一个数据池来维护的。但是订制午餐的菜单则是一个标准数组进行维护。那么在设计订餐程序来遍历这两个不同的数据结构形成的菜单的时候,就会比较麻烦,毕竟返回的数据类型不是一样的。(不知道我说清楚了没,参阅英文版原书P321)

2.对于这样的迭代场景,我们就可以使用所谓迭代器模式。它依赖于一个名为迭代器的接口,然后让所有相关的部分(在这个例子就是两个菜单的迭代器)实现该迭代器。提供了一种方法顺序访问一个聚合对象的各个元素,同时又不暴露其内部的表示。具体的,我们先加入一个迭代器:

然后我们根据早餐和午餐具体的数据结构来实现这个接口:

 

通过上述实现接口的模式,我们把游走的任务放在迭代器上,而不是具体聚合上,这样既简化了聚合的接口和实现,也让责任各得其所。对于早餐和午餐的菜单,我们做如下的设计:

早餐:

  

午餐:

注意加粗的部分,我们加入了一个迭代器的工厂方法。此时,我们现在的服务生就可以从容的处理早餐和晚餐了:

我们下两个单试一试:

3.这样看上去代码是增加了不少,但是对于两个本来写好的类(PancakeHouseMenu和DinerMenu),我们只在其中加入了createIterator这个方法,系统的耦合性很低。此时女招待这个类就不需要知道菜单具体的实现了,并且实现迭代器后我们只需一个循环就可以遍历了。

 

4.其实,Java中就有迭代器,我们将PancakeHouseMenu和DinerMenu所扩展的接口换成java.util的迭代器接口即可,连ArrayList也有一个返回一个迭代器的iterator方法。这样可以进一步减少依赖。首先,我们不需要去创建Iterator接口,直接使用JAVA中的迭代器接口来构造DinerMenuIterator:

注意:要是不想提供remove方法,那要怎么办呢?我们可以抛出一个UnsupportedOperationException异常表示不支持这样的方法

而PancakeHouseMenu 则不需要再实现,因为ArrayList直接有返回迭代器的相应方法。

我们现在开始实现菜单,等等!!

我们发现在两个菜单中有一个共同的方法createIterator,那么在这我们又有一个新的改进——可以通过面向接口编程,使二者统一起来:

早餐:

晚餐:

我们针对这个实现,来创建的女招待代码就变得更加松耦合:

这样我们通过接口抽象完成了迭代器和菜单的松耦合。但需要注意的是,这个线程不安全。当然,有人会问是不是可以实现向后移动,比如pervious(),那么这时你还必须实现一个方法hasPervious()来验证是不是已经到顶端。Java中有一个ListIterator可以供参考。

 

5.最后我们思考一个问题:那我们为什么不在这两个聚合(早餐菜单和晚餐菜单)的内部实现迭代器功能的相关方法呢?我们可以分析一下这个问题如果答案是“可以”的话,将会带来什么。若这个集合改变的话,我们要修改这个类;若遍历的方法改变的话,我们要修改这个类——我们至少有两个引起类变化的原因。这会导致代码的重构效率大大降低。

由此我们引出一个设计原则:单一原则——一个类应该只有一个引起变化的原因,类的每个职责都有改变的潜在区域,一旦超过职责就意味着超过“一个改变”的区域。这个原则极难遵守,因为我们的大脑总习惯自然地把很多东西聚在一起。我们经常说“高内聚”,其实真正的含义在于——当一个模块或一个类被设计为只支持一组相关的功能时,我们称其为高内聚;反之,当被设计为支持一组不相关的功能时,我们说其低内聚。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值