5-Iterators: decoupling algorithms from containers
In the process,he realized that iterators are central to the use of algorithms, because they decouplethe algorithms from the specific type of containe...只看这个，不是很好理解。
找了两个资料，感觉是比较好的例子：
<1>
Iterator模式的疑问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中封装了检索元素的方法。
将容器和对容器中元素的操作完全隔开。
大大增加了代码的可重用性。
