Iterator vs Visitor, Pull vs Push
名词界定
Iterator Pattern也叫做Generator, Sequence, Stream等。Java里面有Iterator Interface，大家应该比较熟悉，不再赘述。
完整的具有Visitor和Visited (Visitable) 两个部分的Visitor Pattern的使用并不广泛。
简单的只有Visitor部分的Simple Visitor Pattern比较常见，比如Callback, Interceptor, Filter，Functor, Selector, Extractor等，都可以看作是Simple Visitor Pattern。
它们都只有Visitor部分，而没有Visited部分。或者说他们的Visitor需要处理的Visited Object通常只有一种通用数据类型，所以不需要专门提出来一个Visited Interface -- accept(visitor)。
这种情况和Observer Pattern很相似。不过这也不奇怪，很多Design Pattern都是非常类似的，有的几乎只有名字不同。
为了避免不必要的口舌之争后，这么说吧，Visitor和Observer的侧重点不同。
Visitor一般来说是Visit一个集合，通常在一个遍历算法中密集完成，获取的信息（Node Object）之间一般都有密切关联，比如父子关系，兄弟关系。
而Observer Patten则是监听一个长期运行的系统，零零散散地不定期地运行，获取的信息之间不存在密切联系，或者说，没什么关系。比如订阅的报纸到了，订购的牛奶到了。
费了半天口舌，澄清各种可能的误会，我们继续Iterator vs Visitor之旅。
Iterator Pattern和Simple Visitor Pattern处理的问题领域几乎是重合的。它们面对的共同问题模型的组成部分如下：
(1)有一个算法Algorithm，通常是遍历算法（Traversal）。而且通常是复杂的数据结构，Tree、Graph等结构的遍历算法。
(2)算法的使用者，需要和算法的每一步遇到的Node Object进行交流。
所不同的是，
Iterator是一种主动模型，Pull模型，Ask and Get。Iterator听候用户的调遣。
Vistor是一种被动模型，Push模型，Plugin / callback模型，Push and Pray and Wait。Visitor听候算法的调遣。
Iterator相当于算法公司的一名业务人员，代表公司和用户打交道。用户并不需要深入到算法公司内部。
而Visitor相当于用户派出的代表，深入到算法公司内部，由算法公司安排访问行程。
Iterator的典型使用方法是：
iterator = traversal.getIterator();
item = iterator.next();
do some thing with item
Vistor的典型使用方法是
visitor = new Visitor(){
.. visit(item) { do something with item }
};
traversal.traverse(visitor);
一个典型的例子是StAX和SAX和两种操作XML的方式。
（参见http://www.xmlpull.org/，关于StAX的典型用法，网上有些经典文章，本文不再赘述。请使用StAX XMLPull XML等关键字进行搜索）
StAX就是一个典型的Pull Model, Iterator Pattern。
而SAX是Push Model, Simple Visitor Pattern (Event Listener)。（如果较真，你当然可以把它叫做Oberver Pattern）。
另外一个有趣的例子是DOM Traversal。
W3的DOM Level 2规范定义了DOM Traversal。
http://www.w3.org/TR/2000/REC-DOM-Level-2-Traversal-Range-20001113/traversal.html
DocumentTraversal, TreeWalker, NodeIterator, NodeFilter。
DOM Traversal主要是一个Iterator Pattern，TreeWalker, NodeIterator都是Iterator；但DOM Traversal同时也是一个简单的Visitor Pattern —— NodeFiter可以作为简单的Visitor被注入到Traversal算法里面，对遇到的每个Node进行过滤。
不过，这个NodeFiter的method name比较有意思，叫做accept。而我们知道Visitor Pattern的Visited Object具有一个accept方法。不过，不要误会。这个NodeFilter仍然是一个Visitor。这里的Accept的意思就是Intercept, Filter。
用法是这样。
NodeIterator iterator = DocumentTraversal.createNodeIterator(…NodeFilter …)
按照我的设想，这个API设计，还可以有另外的思路。把Filter加在Iterator身上，而不是加在Traversal算法身上。因为Iterator Pattern很容易地做到这一点。
NodeIterator iterator = New FilteredIterator(
DocumentTraversal().createNodeIterator() , … NodeFilter …);
这样，DOM Traversal就是一个纯粹的Iterater Pattern了。
特性比较
Iterator属于问答模式，或者说消费者/生产者模式。
如果消费者不问不要，生产者就不答不给。Iterator的使用者完全掌握了主动权，是控制舞步节奏的领舞者，随时可以中止这场问答游戏。
Iterator的用法本身就是Lazy的，一问一答，遍历算法停在那里恭候Iterator使用者的调遣。
Visitor则完全是被动的，Visitor的提供者/使用者把Visitor扔到Traversal算法里面，然后运行算法，同时祈祷并等候算法的完成（Push and Wait），完全失去了控制权，只能等待算法整个完成或者中止，才能重新拿到控制权。
Vistor的用法很难做到Lazy，算法必须提供一些机制，接受Visitor每一步调用发出的指令，进行相应的策略选择。
换句话说，Visitor Pattern里面的算法必须做出相应的Lazy支持，而且Visitor必需积累前面步骤的状态，然后判断这次调用中发出什么样的指令。
比如，有这样一个需求：遍历一棵树，搜集到前5个名字是Apple的Node。然后返回这5个Node。假设树遍历算法已经有了。
这时候采用Iterator Pattern视线起来很容易。不再多说。
Visitor Pattern则需要：
Vistor使用一个集合来保存每次遇到的名字是Apple的Node，每次都判断是否已经找到了5个，如果已经找到，那么发出一个Stop Signal给算法。
如果遍历算法不接受这种指令怎么办？
只好等待算法完成。或者实在等不及，预计到后面还有上万个Node需要遍历，那么就干脆
throw new RuntimeException(), throw new Throwable()。
也许算法并没有聪明到捕获这些Exception。那么这个Trick就成功了。外面使用一个Try Catch捕获这个Exception。不过，这是Very Very Bad Smell。
Iterator的应用场景是这样：
我在商品定购目录上看到一个公司有我感兴趣的产品系列。于是我打电话给该公司，要求派一个销售代表来。销售代表上门之后，从包里拿出一个一个的产品给你看，我看了几个，没什么满意的，于是打了个哈欠说，今天就先到这里吧，下次再说。打发了销售代表，我就转身去做自己的事情了。
我的地盘，我做主。这就是Iterator Pattern的理念。
Vistior的应用场景是这样：
我在商品定购目录上看到一个公司有我感兴趣的产品系列。于是我上门拜访该公司，公司给我安排了一场产品性能展示，我看了几个之后，没有什么满意的，于是我说，我肚子疼，想先回去了。遇到好心的公司代表，当然说，身体要紧，慢走。遇到固执的公司代表，一定会说，对不起，我们公司有自己的工作流程，完成产品演示之前，产品厅的门锁是打不开的。我只好勃然大怒，吵吵嚷嚷（throw exception），期待能够杀出重围，这时候，假设该公司的保安系统反映比较灵敏（try catch every visitor exception），就会有几个保安跑过来，把我按在椅子上继续听讲。
入乡随俗，客随主便。别人的地盘，别人做主。这就是Visitor Pattern的理念。
Iterator Pattern的优势当然不仅如此。这只是个特殊的例子。
更常见的是，Iterator Pattern能够支持基于Iterator的很多算法。
比如，Functional Programming的Map, Reduce, Filter等函数都是接受一个Iterator (Sequence, List, Stream等)。Map, Filter等函数还可以组合成一个新的Iterator。这个组合可以一直下去。
当然，Visitor也是可以组合的。但是限制严格，缺乏扩展性。
比如这样一个需求：
有T1和T2两棵树。首先遍历T1的10个Node，如果发现Apple，那么摘下来，然后继续遍历，如果10步都没有发现Apple，那么切换到T2；遍历T2的规则也是如此，10步之内发现目标，就继续，否则就切换到T1。
Iterator Pattern实现起来很简单。相当于我是买方，情势是买方市场，我可以让两个公司的销售代表同时到我的公司来，我可以同时接待他们，让他们各自按顺序展示自己的产品。
Visitor Pattern怎么做？情势是卖方市场，我巴巴地跑上门去，看T1公司的产品展示，看了10个之后说，请送我到T2公司的产品展示现场，我看10个之后，再回来。
一个用户可以同时使用多个算法的Iterator；但是用户的一个Visitor只能同时进入一个算法。
这就是两者核心理念的不同。
实现难度
读者说了，Iterator这么方便，你就使用Iterator好了，说这么多干什么。
如果别人提供了Iterator，我当然会使用。
现在的问题是，假设你是算法公司的成员。你是提供Visitor Pattern的API，还是Iterator Pattern的API？
Visitor Pattern的实现比较简单。自己知道自己公司的内部组织结构，一个一个的遍历，并传递给Visitor就行了。
Iterator Pattern的实现难度，可以说，那是相当的大。
内部数据结构简单的数组、链表好说，做一个类似于Closure, Context, Continuation的保存了当前调用步骤（数组索引，或者当前指针）和调用环境（内部数据集）的结构，返回给用户就可以了。用户每次调用iterator.next，iterator就把索引或指针向后移动一下。
如果是内部数据复杂的Tree, Graph结构，就相当复杂了。比如是遍历一棵树，而且这棵树的Node里面没有Parent引用，那么Iterator必须自己维护一个栈把前面的所有的Parent Node都保存起来。当用户调用iterator.next的时候，iterator就必须检查自己当前的状态，如果所有的Child Node都走完了，那么就要返回到上面的Parent，继续检查。
而在Visitor Pattern里面，这个算法的实现简直是小菜一碟，只要一个简单的递归就够了。计算机会自动帮你分配和管理运行栈，保存前面的Parent Node，执行返回的时候，这个Parent Node又自动交还给你。
Coroutine
有没有简单的方法来实现Iterator Pattern API呢？如同实现Visitor Pattern API那样容易？
幸福得象花儿一样。简单得像Visitor一样。能不能那样？
聪明的人们把目光转向了Coroutine。
Coroutine本来是一个通用的概念。表示几个协同工作的程序。
比如，消费者/生产者，你走几步，我走几步；下棋对弈，你一步我一步。
由于协同工作的程序通常只有2个，而且这两个程序交换的数据通常只有一个。于是人们就很容易想到用Coroutine来实现Iterator。
这里面Iterator就是Coroutine里面的生产者Producer角色，数据提供者。所以，也叫做Generator。
每次Iterator程序就是等在那里，一旦用户（消费者Consumer角色）调用了iterator.next, Iterator就继续向下执行一步，然后把当前遇到的内部数据的Node放到一个消费者用户能够看到的公用的缓冲区（比如，直接放到消费者线程栈里面的局部变量）里面，然后自己就停下来（wait）。然后消费者用户就从缓冲区里面获得了那个Node。
这样Iterator就可以自顾自地进行递归运算，不需要自己管理一个栈，而是迫使计算机帮助它分配和管理运行栈。于是就实现了幸福得像花儿一样，简单得像Visitor一样的梦想。
比如，这样一段代码，遍历一棵二叉树。
public class TreeWalker : Coroutine {
private TreeNode _tree;
public TreeWalker(TreeNode tree) { _tree = tree; }
protected override Execute() {
Walk(_tree);
}
private void Walk(TreeNode tree) {
if (tree != null) {
Walk(tree.Left);
Yield(tree);
Walk(tree.Right);
}
}
}
其中的Yield指令是关键。意思是，首先把当前Node甩到用户的数据空间，然后自己暂停运行（类似于java的thread yield方法或者object.wait方法），把自己当前运行的线程挂起来，这样虚拟机就为自己保存了当前的运行栈（context）。
有人说，这不就是continuation吗？
对。只是Coroutine这里多了一个产生并传递数据的动作。
实现原理如果用Java Thread表示大概就是这样。当然下面的代码只是一个示意。网上有具体的Java Coroutine实现，具体代码我也没有看过，想来实现原理大致如此。
public class TreeIterator implements Iterator{
TreeWalker walker;
// start the walker thread ..
Object next(){
walker.notify();
// wait for a while so that walker can continue run
return walker.currentNode;
}
}
class TreeWalker implements Runnable{
TreeNode currentNode;
TreeWarker(root){
currentNode = root;
}
void run(){
walk(curentNode);
}
private void Walk(TreeNode tree) {
if (tree != null) {
Walk(tree.Left);
currentNode = tree;
this.wait();
Walk(tree.Right);
}
}
}
我们看到，Iterator本身是一个Thread，用户也是一个Thread。Iterator Thread把数据传递给User Thread。
说实话，我宁可自己维护一个Stack，也不愿意引入Coroutine这类Thread Control的方式来实现Iterator。
总结
千言万语一句话。
Iterator是好的，但不是免费的。
发表于 @ 2006年07月14日 08:35:00|评论(loading...)|编辑