深入浅出设计模式之的迭代器模式.ppt

迭代器模式 本章内容 迭代器的引入 迭代器模式 迭代器模式的举例 迭代器模式的理解 迭代器模式的应用 迭代器模式的引入 数据结构介绍了很多容器性数据结构 链表 二叉树 向量 这些容器性数据结构包含多个元素，元素之间的逻辑关系不尽相同。 迭代器模式的引入 对于容器性数据结构，有时需要访问其中的每一个元素。由于每一个种数据结构的存储不同，访问每一个元素有差别 链表 二叉树 向量 链表的遍历 Object temp = head; while( temp != null){ read temp.value(); temp = temp.next(); } 向量的遍历 int current = 0; while(current vector.size()){ return vector.get(current); current ++; } 二叉树的遍历（先序） if( root !=null) stack.push(root) while(!stack.isEmpty()){ BinaryTree old = stack.pop(); Object result = old.value(); if(!old.right().isEmpty()) 压入右孩子 if(!old.left().isEmpty()) 压入左孩子 } 例如常见的电视，可以定义一个 遥控器的，每个工厂生产的电视机都有配套的遥控器，电视的频道为Item，每个遥控器都会有遍历的功能，用以遍历所有的频道。 请大家举例： 存在的问题 用户需要了解每一种数据结构的内部元素结构的细节，这显然是不好的。 我们能不能统一所有容器性数据结构的遍历呢？ 我们可以定义一个遍历所有数据结构的统一的接口。 迭代器（Iterator）模式，又叫做游标（Cursor）模式。GOF给出的定义为： 提供一种方法访问一个容器（container）对象中各个元素，而又不需暴露该对象的内部细节。 定义可见，迭代器模式是为容器而生。很明显，对容器对象的访问必然涉及到遍历算法。你可以一股脑的将遍历方法塞到容器对象中去；或者根本不去提供什么遍历算法，让使用容器的人自己去实现去吧。这两种情况好像都能够解决问题。　 　然而在前一种情况，容器承受了过多的功能，它不仅要负责自己“容器”内的元素维护（添加、删除等等），而且还要提供遍历自身的接口；而且由于遍历状态保存的问题，不能对同一个容器对象同时进行多个遍历。第二种方式倒是省事，却又将容器的内部细节暴露无遗。 迭代器模式由以下角色组成： 1) 迭代器角色（Iterator）：迭代器角色负责定义访问和遍历元素的接口。 2) 具体迭代器角色（Concrete Iterator）：具体迭代器角色要实现迭代器接口，并要记录遍历中的当前位置。 3) 容器角色（Container）：容器角色负责提供创建具体迭代器角色的接口。 4) 具体容器角色（Concrete Container）：具体容器角色实现创建具体迭代器角色的接口——这个具体迭代器角色于该容器的结构相关。 Iterator：迭代器定义访问和遍历元素的接口。 ConcreteIterator(Controller)：具体迭代器实现迭代器接口，对该聚合遍历时跟踪当前位置。 Aggregate（Televation）:聚合定义了创建相应迭代器对象的接口。 ConcreteAggregate(HaierTV):具体聚合实现创建相应迭代器的接口，该操作返回ConcreteIterator的一个适当的实例。 协作关系：ConcreteIterator跟踪聚合中的当前对象，并能够计算出待遍历的后继对象。 迭代器模式在客户与容器之间加入了迭代器角色。迭代器角色的加入，就可以很好的避免容器内部细节的暴露，而且也使得设计符合“单一职责原则”。　　 单一责任 一个类应该只有一个引起变化的原因 管理自己的聚合 遍历自己的元素 内聚性：衡量一个类或模块紧密达到单一目的或责任的程度。 高内聚 低内聚 高内聚易于维护 注意，在迭代器模式中，具体迭代器角色和具体容器角色是耦合在一起的——遍历算法是与容器的内部细节紧密相关的。为了使客户程序从与具体迭代器角色耦合的困境中脱离出来，避免具体迭代器角色的更换给客户程序带来的修改，迭代器模式抽象了具体迭代器角色，使得客户程序更具一般性和重用性。这被称为多态迭代。 //迭代器角色，仅仅定义了遍历接口public interface Iterator {　boolean hasNext();　Object next();　void remove();}