5-Iterators: decoupling algorithms from containers
In the process, he realized that iterators are central to the use of algorithms, because they decouple the algorithms from the specific type of containe...只看这个，不是很好理解。
找了两个资料，感觉是比较好的例子：
http://www.jdon.com/jivejdon/thread/34664
JAVA COLLECTION类都提供Iterator模式来迭代的取数据，比如ArrayList最终实现Iterable接口，但是
(一)
for(int i=0,i<size;i++){
a.get(i);
......
}
（二）
Iterator i = a.inerator();
while(i.hasNext()){
......
}
1和2都能遍历list实例a的所有元素，没看出用iterator有什么优势。
起先我的想法就是Iterator提供了List的一个不可变视图，如果你想把List发布给一个方法查看而又不希望这个方法能修改它，则发给给该方法一个List的不可更改视图，但是这个想法有几个问题：
（1）Iterator并非不可改，有remove方法
（2）如果是发布不可变试图的话完全可以用Collections.unmodifyList(a);
（3）如果仅仅是发布不可变视图的话也未必要是Iterator这个形式，试想一下，一个方法的参数是Iterator将是多么晦涩难理解的，我也没见过这个用的。
我的第二个想法是Iterable接口是所有Collection对象都必实现的，也许在List里体现不出优势，在其他集合类里能体现出来，List实现Iterable只是List作为集合类所顺理成章实现的。
到底Iterator的优势在哪里
其中一个评论比较有总结性，这应该就是面向接口编程+遵守规范的优越性！
为什么使用iterator，就是因为用***.iterator 来隐藏***的内部实现。
<2>
Iterator模式的几种用法：
http://www.jdon.com/jivejdon/thread/32038
Iterator模式的几种用法
在网络上看帖子时发现不少模式的初学者对Iterator模式的理解仅仅停留在从类库的容器类取得Iterator来遍历容器中的内容的程度。
因此在这里写几个例子，来加深大家对Iterator模式的理解。
对容器中元素的访问涉及到3个方面。
1．容器的类型
2．检索容器内元素的方法
3．对元素的操作
比如说我们有一个表示书店的book_store类。里面保存了各种各样的book类的实例。
book类有name和type两种属性。表示书的名字和类别。
因此book_store类内部会用一个容器来保存book的实例。比如list。
class book
{
public:
string name;
string type;
};
class book_store
{
private:
list<book> m_books;
};
我们现在有这样一个简单的应用，那就是输出所有的书名到屏幕。
那么我们来看一下在引入Iterator模式前有那几种实现方法，各有什么缺点。
1．给book_store类增加一个print_book_name的函数。来实现这个功能。
这样做的缺点有两个：
（1）．将输入输出逻辑和业务对象绑定在一起，导致了今后系统难以变更。
（2）．输出逻辑和内部实现绑定。
比如现在要把输出到屏幕改成输出到log文件的话，那么就需要修改print_book_name了。
2．给book_store类增加一个get_list函数。然后写一个print_book类来负责打印书名的列表。这是一个初学者常用的方式。表面上看来似乎两个类各担其责，一个表示业务对象一个负责打印。
如果需要打印到log文件的话，只要新增加一个log_book类，book_store和print_book都不受影响。解决了上面的这个问题。
这样做的缺点是：
（1）．把book_store类的内部实现给暴露出来了，违反了封装的原则。
如果现在把内部容器类型从list换成了vector的话，就要修改输出逻辑了。也就是说，要同时改写print_book类和log_book类。
3．增加一个list和vector类共同的基类/接口，比如I_container。然后给book_store类增加一个get_books函数，返回I_container。
这在一定程度上解决了上面的问题。但是并不彻底。应为还是暴露了内部的实现，只不过从list上升到了I_container。
· 如果现在系统发生了变化，book_store不再在本地保存books了，而是需要通过网络取得的话，print_book和log_book就无法对应了。
· 另一个限制是，我需要一个新的机能，那就是打印所有type为”烹饪书”的机能的话，就需要一个print_cook_book类了，而这里边的格式化代码和输出代码和print_book是相同的。重复代码是维护的噩梦。
接下来我们看一下Iterator模式如何解决以上的这些问题。
首先，我们引入一个I_iterator的Interface。
然后创建一个I_iterator的实现类all_book_iterator。这个类可以迭代book_store中的所有book。
接下来创建一个print_book类，从I_iterator中取得每一个book，然后打印到屏幕。
下面我们看一下如何对应上面的这些需求变更。
1．要求输出到log文件
追加一个log_book类，其他都类都不需要改变。
2．将内部容器从list变成vector。
修改iterator中的相关代码。Iterator的使用者不会受到影响。
3．从网络取得数据。
修改iterator中的相关代码。Iterator的使用者不会受到影响。
4．按照type检索
在iterator中添加一个type的属性，或者是构造一个新的type_search_iterator。
在iterator中把不符合检索条件的book过滤掉。
5．按照某一特定顺序输出book名到屏幕，或是log文件。
实现一个按该顺序输出的iterator。
6．以同样的方式打印cd_store。
实现对应于cd_store的iterator。
可见，iterator模式在各种iterator中封装了检索元素的方法。
将容器和对容器中元素的操作完全隔开。
大大增加了代码的可重用性。