正文

前言

本文主要是读书笔记的整理，自己总结的倒不多，做个记录

聚集（集合）的概念

如果能把多个普通类的对象聚在一起形成一个总体，这个总体就被称之为聚集(Aggregate)，举例子：

1、在任何编程语言中：数组都是最基本的聚集，在Java中，数组也是其他的 JAVA 聚集对象的设计基础。

2、在Java里，JAVA聚集对象都是实现了 java.util.Collection 接口的对象，是 JAVA 对聚集概念的直接支持。从 JDK 1.2 开始，JAVA 提供了多种现成的聚集 API，包括 Vector、ArrayList、HashSet、HashMap、Hashtable、ConcurrentHashMap 等。

回到顶部

自定义容器的封闭需求

假如因业务需要，RD 定义了专属的数据元素的聚集，还要把它提供给客户端，让其调用（不特别强调，也包括其他依赖服务）。但是有时候为了安全，RD 不想让客户端看到聚集的内部实现，只是能让她们访问就可以了，比如遍历等操作。还有的时候，客户端不需要了解具体实现，能否让客户端跳开复杂的数据结构？因为调用者们不需要了解实现方式，只要能开箱即用即可。

为了解决这个问题，那么就需要有一种策略能让客户端遍历这个聚集体的时候，无法窥破RD存储对象的方式，无需了解内部的复杂数据结构。

回到顶部

迭代器的引出——茶餐厅和煎饼铺子合并的经典案例

有两个遗留的点餐系统，包括一套餐厅点餐系统——专门提供正餐，和一个煎饼铺子点餐系统（不要纠结为啥煎饼摊也有点餐系统。。。）——专门提供早餐（除了早餐，其他时间不开放）。

现状

餐厅里有很多卖饭的窗口，它们的业务是一块单独的实现，隔壁煎饼铺的业务，也是一块单独的实现。现在有个老板想把它们收购并合并，让客户能在一个地方，一个时间段内，同时吃煎饼和餐厅的各种菜。目前餐厅内有至少两家餐馆都统一实现了 MenuItem 类——菜单子系统的菜单类。

问题

但是煎饼的菜单系统用的 ArrayList 记录菜单，而餐厅的 RD 用的是数组实现了菜单系统，双方的RD，都不愿意花费时间修改自己的实现。毕竟有很多其他服务依赖了菜单子系统，如下 MenuItem 代码：

/**
 * 餐厅的菜单都是午餐项目，煎饼的菜单，都是早餐项目，但是它们都属于菜单，即：
 * 都有菜品名称，描述，是否是素的，价格等
 * 故设计这样一个类作为菜单项目类 */public class MenuItem {
    String name;
    String description;    public MenuItem(String name,
                    String description) {        this.name = name;        this.description = description;
    }    public String getName() {        return name;
    }    public String getDescription() {        return description;
    }}

不同的餐厅使用了这个 MenuItem 类

/**
 * 煎饼窗口的菜单 */public class PancakeHouseMenu {    private List<MenuItem> menuItems; // menuItems 使用 ArrayList 存储菜单的项目，动态数组，使其很容易扩大菜单规模

    /**
     * 在构造菜单的时候，把菜单加入到 ArrayList menuItems     */
    public PancakeHouseMenu() {
        menuItems = new ArrayList<>();
        addItem("K&B's Pancake Breakfast",                "Pancakes with scrambled eggs, and toast");

        addItem("Regular Pancake Breakfast",                "Pancakes with fried eggs, sausage");
    }    public void addItem(String name, String description) {
        MenuItem menuItem = new MenuItem(name, description);
        menuItems.add(menuItem);
    }    public List<MenuItem> getMenuItems() {        return menuItems;
    }}
 ////////////////////////////////////////////////////////////////**
 * 餐厅的菜单 */public class DinerMenu {    private static final int MAX_ITEMS = 6;    private int numberOfItems = 0;    private MenuItem[] menuItems; // 使用了真正的数组实现菜单项的存储

    public DinerMenu() {
        menuItems = new MenuItem[MAX_ITEMS];
        addItem("Vegetarian BLT", "(Fakin') Bacon with lettuce & tomato on whole wheat");
        addItem("BLT", "Bacon with lettuce & tomato on whole wheat");
        addItem("Soup of the day", "Soup of the day, with a side of potato salad");
    }    public void addItem(String name, String description) {
        MenuItem menuItem = new MenuItem(name, description);        if (numberOfItems >= MAX_ITEMS) {
            System.err.println("Sorry, menu is full!  Can't add item to menu");
        } else {
            menuItems[numberOfItems] = menuItem;
            numberOfItems = numberOfItems + 1;
        }
    }    public MenuItem[] getMenuItems() {        return menuItems;
    }}

两种不同的菜单表现方式，会给客户端调用带来很多问题，假设客户端是服务员类——Waitress，下面是客户端的业务：

打印出菜单上的每一项：打印每份菜单上的所有项，必须调用 PancakeHouseMenu 和 DinerMenu 的 getMenuItem 方法，来取得它们各自的菜单项，但是两者返回类型是不一样的
只打印早餐项（PancakeHouseMenu 的菜单）或者只打印午餐项（DinerMenu 的菜单）
- 想要打印 PancakeHouseMenu 的项，我们用循环将早餐 ArrayList 内的项列出来
- 想要打印 DinerMenu 的项目，我们用循环将数组内的项一一列出来
打印所有的素食菜单项
指定项的名称，如果该项是素食的话，返回true，否则返回false

实现 Waitress 的其他方法，做法都和上面的方法类似，发现 Waitress 处理两个菜单时，总是需要写两个形式相似的循环，去遍历这些菜单，而且一旦外部菜单的数据结构变了，客户端也得跟着修改。

再有，如果还有第三家餐厅合并，而且坑爹的是，它以完全不同的实现方式实现了菜单……那怎么办？此时难道还继续写第三个循环么……

以后，这样甚至能发展到 N 个不同形式的循环……

这显然是非常不好的设计，直接导致后期系统的大量垃圾代码和日益艰巨的维护任务。

为什么出现这种结局？

封装特性	面向接口编程	代码冗余
Waitress （也就是客户端）竟然能非常清晰的，而且是必须清晰的熟悉服务端的实现，这是很不科学的	PancakeHouseMenu 和 DinerMenu 都没有面向接口编程，而直接实现了具体业务，导致扩展困难	DinerMenu和PancakeHouseMenu都有很大重复代码，没有抽象共享

封装特性

面向接口编程

代码冗余

Waitress （也就是客户端）竟然能非常清晰的，

而且是必须清晰的熟悉服务端的实现，这是很不科学的

PancakeHouseMenu 和 DinerMenu 都没有面向接口编程，

而直接实现了具体业务，导致扩展困难

DinerMenu和PancakeHouseMenu都有很大重复代码，

没有抽象共享

那么可以解决么？

解决方法

1、Waitress 要遍历早餐项，需要使用 ArrayList 的 size() 和 get() 方法

2、Waitress 遍历午餐项，需要使用数组的 length 字段和中括号

现在创建一个新的对象，将它称为迭代器（Iterator），利用它来封装“遍历集合内的每个对象的过程”，下面对其抽象、封装。

原则：只封装变化的部分

案例中变化的部分：因为不同的集合实现，导致的不同的遍历方式。将其封装即可，其实，这正是迭代器模式的应用。迭代器 Iterator，是面向接口编程，故它依赖于一个称为迭代器的接口：

/**
 * 迭代器的接口，一旦有了这个接口，就可以为给种对象集合实现迭代器：数组、列表、散列表等等 */public interface Iterator {    /**
     * 聚集中，是否还有元素     */
    boolean hasNext();    /**
     * 返回聚集中的下一个元素     */
    Object next();
}

让餐厅实现迭代器接口 —— Iterator，打造一个餐厅菜单迭代器——DinerMenuIterator

/**
 * 餐厅的迭代器 */public class DinerMenuIterator implements Iterator {    private MenuItem[] items;    private int position = 0;    public DinerMenuIterator(MenuItem[] items) {        this.items = items;
    }    public Object next() {
        MenuItem menuItem = items[position];
        position = position + 1;        return menuItem;
    }    public boolean hasNext() {        return position < items.length && items[position] != null;
    }
}

改造具体餐厅的菜单旧实现，把之前的如下代码删掉，因为它会暴露餐厅菜单的内部数据结构 menuItems

public MenuItem[] getMenuItems() {    return menuItems;
}

下面是改造之后的餐厅菜单实现，PancakeHouseMenu 实现类似。

public class DinerMenu {    private static final int MAX_ITEMS = 6;    private int numberOfItems = 0;    private MenuItem[] menuItems;    // 实现方式不变
    public DinerMenu() {
        menuItems = new MenuItem[MAX_ITEMS];
        addItem("Vegetarian BLT", "(Fakin') Bacon with lettuce & tomato on whole wheat");
        addItem("BLT", "Bacon with lettuce & tomato on whole wheat");
        addItem("Soup of the day", "Soup of the day, with a side of potato salad");
    }    // 实现方式不变
    public void addItem(String name, String description) {
        MenuItem menuItem = new MenuItem(name, description, vegetarian, price);        if (numberOfItems >= MAX_ITEMS) {
            System.err.println("Sorry, menu is full!  Can't add item to menu");
        } else {
            menuItems[numberOfItems] = menuItem;
            numberOfItems = numberOfItems + 1;
        }
    }    // 不需要 getMenuItems 方法，因为它会暴露内部实现，返回的直接是菜单的数据结构    // 这个新方法代替 getMenuItems，createIterator 返回的是迭代器接口
    public Iterator createIterator() {        return new DinerMenuIterator(menuItems);
    }}

这样写客户端的代码就不会重复两遍，如下，把迭代器的代码整合到 Waitress，改掉之前冗余的循环遍历代码，只需要传入一个迭代器作为遍历方法的参数，把遍历聚集的工作，委托给迭代器实现。既能保护内部实现，也能抽象遍历形式，精简代码。也符合了开闭原则——以后菜单的实现逻辑修改了，客户端也不用修改调用的代码。

public class Waitress {    // 服务员依赖的菜单系统
    private PancakeHouseMenu pancakeHouseMenu;    private DinerMenu dinerMenu;    public Waitress(PancakeHouseMenu pancakeHouseMenu, DinerMenu dinerMenu) {        this.pancakeHouseMenu = pancakeHouseMenu;        this.dinerMenu = dinerMenu;
    }    /**
     * 遍历全部菜单，无需在客户端里积压多个重复的循环代码，也符合了开闭原则——以后修改遍历逻辑，客户端不需要修改     */
    public void printMenu() {        // 为每个菜单系统，创建一个迭代器 Iterator
        Iterator pancakeIterator = pancakeHouseMenu.createIterator();
        Iterator dinerIterator = dinerMenu.createIterator();// 把迭代器子类型，传入        printMenu(pancakeIterator);// 把迭代器子类型，传入        printMenu(dinerIterator);
    }    /**
     * 接口的用法，向上转型     */
    private void printMenu(Iterator iterator) {        // 先判断是否还能继续迭代
        while (iterator.hasNext()) {            // Iterator 接口里 next 返回的是 Object 对象，故需要强制转换
            MenuItem menuItem = (MenuItem) iterator.next();
            System.out.print(menuItem.getName() + ", ");
            System.out.println(menuItem.getDescription());
        }
    }}
 //////public class MenuTestDrive {    public static void main(String args[]) {
        PancakeHouseMenu pancakeHouseMenu = new PancakeHouseMenu();
        DinerMenu dinerMenu = new DinerMenu();
        Waitress waitress = new Waitress(pancakeHouseMenu, dinerMenu);
        waitress.printMenu();
    }
}

到底解决了什么问题

经迭代器模式对菜单系统进行封装，使得各个餐厅的菜单系统能维持不变，磨平了实现的差别，减少了重写的工作量。

旧版代码的客户端	基于迭代器模式封装服务后，重写的客户端
遍历：需要多个代码重复度较高的循环来实现，代码冗余度很高，加大无意义的工作量	只需要增加类，去实现各个菜单系统的迭代器，客户端只需要一个循环就能搞定所有的菜单服务调用
各个菜单系统的具体实现，封装的不行，对客户端暴露了数据结构，这是没有任何必要的	菜单的具体实现被封装，对外只公开迭代器，客户端不知道，也不需要知道具体菜单的实现
客户端被捆绑到了多个菜单实现类，牵一发动全身	客户端可以只用 iterator 接口做参数，通过向上转型，摆脱多个具体实现的捆绑，实现解耦

继续发现问题

客户端 Waitress 组合了多个具体实现类，仍然会牵一发动全身，比如修改了菜单的类名，客户端就失效，也需要修改，仍然重度依赖

而且，具体菜单的实现类又有共同的方法 createIterator ，完全可以进一步抽象。

改进上述设计——充分利用 JDK 自带的迭代器

首先不再为List这样的数据结构重新实现迭代器，因为JDK 5 之后，Java 已经给我们实现好了，对于JDK 5 之后的所有集合容器，都可以采用 JDK 自带的迭代器接口——java.util,Itreator，所以我们就不用自己写，只需实现数组的迭代器即可。

1、记住：JDK 不支持为数组生成迭代器

2、java.util 包中的 Collection 接口——Java 所有的集合都实现了该接口，该接口有迭代器方法。

继续改进——抽象具体类的公共部分

可以为各个菜单实现类，提供一个公共的接口——Menu

原则：面向接口编程

有多个具体实现类的时候，要首先考虑不针对实现编程，而是面向接口编程，除非有共同的抽象方法+属性时，可以考虑抽象父类。本案例中，只需使用接口，就可以减少客户端 waittress 和具体菜单实现类之间的依赖。

import java.util.Iterator;/**
 * 菜单系统要实现的方法，抽象为接口 */public interface Menu {
    Iterator createIterator();
}
 //////////////////////////////**
 * 菜单的每项，抽象为类 */public class MenuItem {    private String name;    private String description;public MenuItem(String name,
                    String description) {        this.name = name;        this.description = description;
    }    public String getName() {        return name;
    }    public String getDescription() {        return description;
    }}
 /////////////////////////////////// 餐厅菜单系统的迭代器，不需要实现额外声明的迭代器接口，而是重写JDK的迭代器即可import java.util.Iterator;/**
 * 重写 JDK 的迭代器
 * implements java.util.Iterator; */public class DinerMenuIterator implements Iterator {    private MenuItem[] items;    private int position = 0;    public DinerMenuIterator(MenuItem[] items) {        this.items = items;
    }    // 不需要变    @Override    public Object next() {
        MenuItem menuItem = items[position];
        position = position + 1;        return menuItem;
    }    // 不需要变    @Override    public boolean hasNext() {        return position < items.length && items[position] != null;
    }    // 重新实现，最好是重写    @Override    public void remove() {        if (position <= 0) {            throw new IllegalStateException
                    ("You can't remove an item until you've done at least one next()");
        }        // 删除线性表的元素，所有元素需要往前移动一个位置
        if (items[position - 1] != null) {            for (int i = position - 1; i < (items.length - 1); i++) {
                items[i] = items[i + 1];
            }

            items[items.length - 1] = null;
        }
    }
}
 ////////////////////// 餐厅菜单系统import java.util.Iterator;/**
 * Created by wangyishuai on 2018/1/27 */public class DinerMenu implements Menu {    private static final int MAX_ITEMS = 6;    private int numberOfItems = 0;    private MenuItem[] menuItems;    // 实现方式不变
    public DinerMenu() {
        menuItems = new MenuItem[MAX_ITEMS];
        addItem("Soup of the day",                "Soup of the day, with a side of potato salad");
    }    // 实现方式不变
    public void addItem(String name, String description,                        boolean vegetarian, double price) {
        MenuItem menuItem = new MenuItem(name, description, vegetarian, price);        if (numberOfItems >= MAX_ITEMS) {
            System.err.println("Sorry, menu is full!  Can't add item to menu");
        } else {
            menuItems[numberOfItems] = menuItem;
            numberOfItems = numberOfItems + 1;
        }
    }    // 返回的是 java.util.Iterator;    @Override    public Iterator createIterator() {        return new DinerMenuIterator(menuItems);
    }}
 /////////////////////////////////////////// 煎饼，不需要再实现迭代器，因为使用的数据结构是JDK的容器，而对于JDK自带的集合容器，不需要自己实现迭代器import java.util.ArrayList;import java.util.Iterator;import java.util.List;/**
 * 对于JDK的集合容器——List，不需要RD实现迭代器 */public class PancakeHouseMenu implements Menu {    private List<MenuItem> menuItems;    public PancakeHouseMenu() {
        menuItems = new ArrayList<>();
        addItem("K&B's Pancake Breakfast", "Pancakes with scrambled eggs, and toast");
    }    public void addItem(String name, String description) {
        MenuItem menuItem = new MenuItem(name, description);
        menuItems.add(menuItem);
    }

    @Override    public Iterator createIterator() {        // 返回 JDK ArrayList 自带的迭代器 iterator() 方法
        return menuItems.iterator();
    }}
 //////////////////////////////// 客户端import java.util.Iterator;public class Waitress {    // 服务员依赖的菜单系统——通过接口解耦合
    private Menu pancakeHouseMenu;    private Menu dinerMenu;    // 修改为 Menu 接口，向上转型，解耦合
    public Waitress(Menu pancakeHouseMenu, Menu dinerMenu) {        this.pancakeHouseMenu = pancakeHouseMenu;        this.dinerMenu = dinerMenu;
    }    /**
     * 以后修改遍历逻辑，客户端不需要修改
     * // 不用修改     */
    public void printMenu() {        // 为每个菜单系统，创建迭代器        // java.util.Iterator;
        Iterator pancakeIterator = pancakeHouseMenu.createIterator();
        Iterator dinerIterator = dinerMenu.createIterator();
        printMenu(pancakeIterator);
        printMenu(dinerIterator);
    }    /**
     * 接口的用法，向上转型
     * // 不用修改
     * java.util.Iterator;     */
    private void printMenu(Iterator iterator) {        // 先判断是否还能继续迭代
        while (iterator.hasNext()) {            // Iterator 接口里 next 返回的是 Object 对象，故需要强制转换
            MenuItem menuItem = (MenuItem) iterator.next();
            System.out.print(menuItem.getName() + ", ");
            System.out.println(menuItem.getDescription());
        }
    }}public class MenuTestDrive {    public static void main(String args[]) {
        Menu pancakeHouseMenu = new PancakeHouseMenu();
        Menu dinerMenu = new DinerMenu();        // 即使具体的菜单实现类修改了名字或者环了实现类，客户端——Waitress 也不需要修改代码，解了耦合
        Waitress waitress = new Waitress(pancakeHouseMenu, dinerMenu);
        waitress.printMenu();
    }
}

针对 JDK 的迭代器重写的原则

remove 方法应不应该重写

虽然对于客户端来说，remove 方法非必须（当然业务需要的话，就必须自定义重写 remove），但是最好还是提供该方法，因为JDK的 Iterator接口里包含了该方法，如果不一起重写，可能会出问题。

如果客户端真的不需要删除元素，那么最好也重写该方法，只需要在重写的时候抛出一个自定义的（或者现成的）异常——如果有调用，就提醒客户端不能删除元素。JDK也是这样设计的，默认抛出异常 UnsupportedOperationException

线程安全问题

默认的迭代器接口是线程不安全的，如果有需要，要额外的加强线程安全。

回到顶部

迭代器模式的标准概念

迭代器模式又叫游标(Cursor)模式、Iterator模式，迭代子模式……是对象的行为模式之一，它把对容器中包含的内部对象的访问委托给外部的类，让外部的类可以使用 Iterator 按顺序进行遍历访问，而又不暴露其内部的数据结构。

Iterator Pattern (Another Name: Cursor)
Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.

脱离Java的领域，那么可以认为：迭代器模式可以顺序地访问聚集中的元素，而不必暴露聚集的内部状态（internal representation）。它把遍历的责任转移到了迭代器，而不是聚集本身，简化了聚集的接口和实现代码，也分割了责任。

回到顶部

迭代器模式的角色

Iterator（迭代器接口）：该接口必须定义实现迭代功能的最小定义方法集，比如提供hasNext()和next()方法。

ConcreteIterator（具体的迭代器实现类）：迭代器接口Iterator的实现类。可以根据具体情况加以实现。

Aggregate（聚集的接口）：定义基本功能以及提供类似Iterator iterator()的方法。

concreteAggregate（聚集接口的实现类）：容器接口的实现类。必须实现生成迭代器的方法。

回到顶部

聚集体如果不使用 Iterator 模式，会存在什么问题

聚集类承担了太多功能

如果是自定义的聚集，那么需要由聚集自己实现顺序遍历的方法——直接在聚集的类里添加遍历方法。这样，容器类承担了太多功能：

一方面需要提供添加、删除等本身应有的功能；

一方面还需要提供遍历访问功能。

不仅责任不分离，还和客户端耦合太强

暴露聚集的太多内部实现细节

如果不使用迭代器模式，那么需要客户端自己实现服务的遍历（联系餐厅和煎饼屋的合并案例），会直接暴露聚集的数据结构，往往这是不必要的，客户端不需要了解服务的具体实现，也是为了程序的安全——不暴露太多的内部细节给客户端。

遍历聚集的时候修改聚集的元素，引起聚集的状态混乱

如果使用的是 JDK 的集合类，如果直接遍历，且遍历的时候对集合修改，会有异常抛出。因为，往往容器在实现遍历的过程中，需要保存遍历状态，当遍历操作和元素的添加、删除等操作夹杂在一起，这些更新功能在遍历的时候也被调用，很容易引起集合的状态混乱和程序运行错误等。此时应该为聚集使用迭代器模式，如果是JDK的集合类，就直接使用自带的迭代器进行迭代。

记住：Java 中的 foreach 循环看起来像一个迭代器，但实际上并不是，还是要使用迭代器模式

Iterator 支持从源集合中安全地删除对象，只需在 Iterator 上调用 remove() 即可。这样做的好处是可以避免 ConcurrentModifiedException ，这个异常顾名思意：当打开 Iterator 迭代集合时，同时又在对集合进行修改。有些集合不允许在迭代时删除或添加元素，但是调用 Iterator 的remove() 方法是个安全的做法。

List<String> list = new ArrayList<>(Arrays.asList("a","b","c","d"));for(String s : list){    if(s.equals("a")){
        list.remove(s);
    }
}
 //会抛出一个ConcurrentModificationException异常,相反下面的显示正常List<String> list = new ArrayList<>(Arrays.asList("a","b","c","d"));
Iterator<String> iter = list.iterator();while(iter.hasNext()){
        String s = iter.next();        if(s.equals("a")){
            iter.remove();
    }
}// next() 必须在 remove() 之前调用。// 在 foreach 中，编译器会使 next() 在删除元素之后被调用，因此就会抛出 ConcurrentModificationException 异常

参考

1、Iterator的remove方法可保证从源集合中安全地删除对象（转）

2、正确遍历删除List中的元素方法 http://www.jb51.net/article/98763.htm

Fail Fast 问题

如果一个算法开始之后，它的运算环境发生变化，使得算法无法进行必需的调整时，这个算法就应当立即发出故障信号。这就是 Fail Fast 的含义。同理，如果聚集的元素在一个动态迭代子的迭代过程中发生变化，迭代过程会受到影响而变得不能自恰。这时候，迭代子就应立即抛出一个异常。这种迭代子就是实现了Fail Fast 功能的迭代子。

使用迭代器模式的优点

Iterator 模式就是为了有效地处理按顺序进行遍历访问的一种设计模式，简单地说，Iterator模式提供一种有效的方法，可以屏蔽聚集对象的容器类的实现细节，而能对容器内包含的对象元素按顺序进行有效的遍历访问。所以，Iterator模式的应用场景可以归纳为以下几个：

访问容器中包含的内部对象
按顺序访问

优点总结：

1，实现功能分离，简化聚集的接口。让聚集只实现本身的基本功能，把迭代功能委托给外部类实现，符合类的单一职责设计原则。

2，隐藏聚集的实现细节，符合最小知道原则。为聚集或其子容器提供了一个统一接口，一方面方便客户端调用；另一方面使得客户端不必关注迭代器的实现细节。

3，可以为聚集或其子容器实现不同的迭代器，搭配其他设计模式，比如策略模式等，可以很容易的切换。

4、客户端可以同时使用多个迭代器遍历一个聚集。

回到顶部

内部迭代器和外部迭代器

截止到此处，都是分析的外部迭代器模式——客户端来调用 next 方法，去取得下一个元素。

相反，内部迭代器是由迭代器自己控制游标，在这种情况下，必须告诉迭代器在游标移动的过程中，要做什么事情——必须将操作传给迭代器，因为内部迭代器的客户端，无法控制遍历过程，所欲内部迭代器伸缩性不强，一般不使用。

回到顶部

List 迭代的方向问题

都知道，next 方法是正向遍历，那么自然可以实现反向遍历，新加一个取得前一个元素的方法 + 一个判断游标是否已经走到了首节点的方法即可解决。

JDK也为我们做了实现：ListIterator接口，提供了一个previous方法，JDK中的任何实现了List接口的集合，都可以实现反向迭代。

回到顶部

非线性数据结构的迭代问题

澄清一个问题——迭代器模式是没有约束元素顺序的，即 next （previous）只是取出元素，并不是强制元素取出的先后顺序等价于元素的某种排序。通俗的说，不论是线性结构还是非线性的，甚至是包含重复元素的结构，除非有特殊业务需求，都能对其实现迭代器模式。

不可幻想：迭代的顺序就等价于集合中元素的某种有意义的排序，两者没有必然关系，谨记以避免做出错误判断，除非有自定义的顺序约束。

回到顶部

单一职责设计原则和迭代器模式

设计原则：一个类只有一个引起变化的原因。如果有一个类具有两个改变的原因，那么这会使得将来该类的变化机率上升，而当它真的改变时，你的设计中同时又有两个方面将会受到影响。

高内聚 > 单一职责原则

内聚：用来度量一个类或者模块紧密的达到了单一职责的目的（or 责任）。当一个类或者一个模块被设计为只支持一组相关的功能的时候，就说它具有高内聚的特性，反之就是低内聚的。

高内聚是一个比单一职责更普遍的概念，即遵守了高内聚的类，也同样具有单一职责。

迭代器模式就遵循了单一职责原则

其实前面的分析已经很全面，迭代器模式，分离了聚集的迭代的责任，有效的契合了单一职责设计原则。

回到顶部

扩展案例：合并咖啡厅的菜单系统

为其合并后的系统，增加咖啡厅的菜单，供应晚餐。下面是咖啡厅的菜单系统实现：

import java.util.HashMap;import java.util.Map;/**
 * 原始的咖啡厅菜单实现类 */public class CafeMenu {    /**
     * 菜单使用了hash表存储，和现有的两个菜单系统实现不一样     */
    private Map<String, MenuItem> menuItems = new HashMap<>();    public CafeMenu() {
        addItem("Veggie Burger and Air Fries", "Veggie burger on a whole wheat bun, lettuce, tomato, and fries");
    }    public void addItem(String name, String description) {
        MenuItem menuItem = new MenuItem(name, description);
        menuItems.put(menuItem.getName(), menuItem);
    }    public Map<String, MenuItem> getItems() {        return menuItems;
    }
}
 //////////////////////////////////////////////////public class MenuItem {    private String name;    private String description;public MenuItem(String name,
                    String description) {        this.name = name;        this.description = description;
    }    public String getName() {        return name;
    }    public String getDescription() {        return description;
    }}

将咖啡厅菜单系统合并到现有的系统：

public interface Menu {
    Iterator createIterator();
}
 //////////////////////// 咖啡厅菜单系统import java.util.HashMap;import java.util.Iterator;import java.util.Map;/**
 * 合并之后的咖啡厅菜单实现类
 * hash表也实现了JDK的迭代器，不需要RD自己实现 */public class CafeMenu implements Menu {    /**
     * 菜单使用了hash表存储，和现有的两个菜单系统实现不一样
     * 实现不变     */
    private Map<String, MenuItem> menuItems = new HashMap<>();    // 实现不变
    public CafeMenu() {
        addItem("Veggie Burger and Air Fries",                "Veggie burger on a whole wheat bun, lettuce, tomato, and fries");
    }    // 实现不变
    public void addItem(String name, String description) {
        MenuItem menuItem = new MenuItem(name, description);
        menuItems.put(menuItem.getName(), menuItem);
    }    /**
     * hash表支持JDK自带的迭代器 java.util.Iterator;     */
    @Override    public Iterator createIterator() {        // 返回 java.util.Iterator; 只需要取得 hash 表的 value 集合即可
        return menuItems.values().iterator();
    }
}
 //////////////////////// 客户端 Waitressimport java.util.Iterator;public class Waitress {    private Menu pancakeHouseMenu;    private Menu dinerMenu;    // 需要增加 cafeMenu
    private Menu cafeMenu;    /**
     * 如果，太多的参数，可以使用建造者模式优化构造器
     * 需要增加 cafeMenu 参数     */
    public Waitress(Menu pancakeHouseMenu, Menu dinerMenu, Menu cafeMenu) {        this.pancakeHouseMenu = pancakeHouseMenu;        this.dinerMenu = dinerMenu;        this.cafeMenu = cafeMenu;
    }    /**
     * 需要增加 cafeMenu 的迭代器     */
    public void printMenu() {
        Iterator pancakeIterator = pancakeHouseMenu.createIterator();
        Iterator dinerIterator = dinerMenu.createIterator();
        Iterator cafeIterator = cafeMenu.createIterator();
        printMenu(pancakeIterator);
        printMenu(dinerIterator);
        printMenu(cafeIterator);
    }    /**
     * 无需修改     */
    private void printMenu(Iterator iterator) {        while (iterator.hasNext()) {
            MenuItem menuItem = (MenuItem) iterator.next();
            System.out.print(menuItem.getName() + ", ");
            System.out.print(menuItem.getPrice() + " -- ");
            System.out.println(menuItem.getDescription());
        }
    }}
 //////////////////////// 测试public class MenuTestDrive {    public static void main(String args[]) {
        Menu pancakeHouseMenu = new PancakeHouseMenu();
        Menu dinerMenu = new DinerMenu();
        Menu cafeMenu = new CafeMenu();

        Waitress waitress = new Waitress(pancakeHouseMenu, dinerMenu, cafeMenu);
        waitress.printMenu();
    }
}

继续发现系统的问题——客户端违反了开闭原则

合并咖啡厅的过程中，发现每次合并新菜单，都要打开客户端，修改代码……客户端实现很丑陋，违反了开闭原则。

虽然我们抽象了菜单，让其在客户端解耦，并且为菜单系统分别实现了迭代器，让迭代责任分离，对客户端隐藏了具体实现，使用同一的迭代器接口，解耦了迭代动作。但是，仍然将菜单处理分成独立的对象看待，导致每次扩展，都需要修改客户端——客户端需要反复写：调用printMenue的代码，代码冗余严重，而且每次都要给构造器增加新参数。

需要一种更好的办法——集中管理菜单，使其使用一个迭代器即可应付菜单的扩展

解决方案：抽象客户端各个独立的菜单系统，只需保留一个迭代器

使用现成的 ArrayList 类实现：

import java.util.Iterator;import java.util.List;public class Waitress1 {    /**
     * 把各个菜单系统集中到一个list，充分利用list的迭代器
     * 只需要一个类就搞定，不再每次都add一个菜单类了     */
    private List<Menu> menus;    public Waitress1(List<Menu> menus) {        this.menus = menus;
    }    public void printMenu() {        // 取得list的迭代器，直接使用一个迭代器，就能遍历所有菜单，不需要在修改
        Iterator menuIterator = menus.iterator();        while (menuIterator.hasNext()) {
            Menu menu = (Menu) menuIterator.next();
            printMenu(menu.createIterator());
        }
    }    // 代码不需要变
    void printMenu(Iterator iterator) {        while (iterator.hasNext()) {
            MenuItem menuItem = (MenuItem) iterator.next();
            System.out.print(menuItem.getName() + ", ");
            System.out.print(menuItem.getPrice() + " -- ");
            System.out.println(menuItem.getDescription());
        }
    }
}

基于迭代器模式实现的菜单系统无法实现树状菜单（无法扩展子菜单）

现在希望能够加上一份餐后甜点“子菜单”作为晚餐的饭后补充。如果我们能让甜点菜单变成餐厅菜单集合的一个子元素，就可以完美的解决。但是根据现在的实现，根本做不到。因为饭后甜点子菜单的实现基于数组——不变的，类型不同，无法扩展。生产环境中，这样的系统非常复杂，更加困难。

解决方案——树

1、需要某种树形结构，可以容纳菜单、子菜单和菜单项。

2、需要确定能够在每个菜单的各个项目之间游走，而且至少要像现在用迭代器一样方便。

3、需要能够更有弹性地在菜单项之间游走。比方说：可能只需要遍历甜点菜单，或者可以遍历餐厅的整个菜单。

此时，需要一种新的设计模式来解决这个案例的难题——组合模式，参看：优雅的处理树状结构——组合模式总结

作者：dashuai的博客

原文出处：https://www.cnblogs.com/kubixuesheng/p/5183739.html

遍历“容器”的优雅方法——总结迭代器模式

前言

聚集（集合）的概念

自定义容器的封闭需求

迭代器的引出——茶餐厅和煎饼铺子合并的经典案例

现状

问题

为什么出现这种结局？

解决方法

原则：只封装变化的部分

到底解决了什么问题

继续发现问题

改进上述设计——充分利用 JDK 自带的迭代器

继续改进——抽象具体类的公共部分

原则：面向接口编程

针对 JDK 的迭代器重写的原则

remove 方法应不应该重写

线程安全问题

迭代器模式的标准概念

迭代器模式的角色

聚集体如果不使用 Iterator 模式，会存在什么问题

聚集类承担了太多功能

暴露聚集的太多内部实现细节

遍历聚集的时候修改聚集的元素，引起聚集的状态混乱

Fail Fast 问题

使用迭代器模式的优点

内部迭代器和外部迭代器

List 迭代的方向问题

非线性数据结构的迭代问题

单一职责设计原则和迭代器模式

高内聚 > 单一职责原则

迭代器模式就遵循了单一职责原则

扩展案例：合并咖啡厅的菜单系统

继续发现系统的问题——客户端违反了开闭原则

解决方案：抽象客户端各个独立的菜单系统，只需保留一个迭代器

基于迭代器模式实现的菜单系统无法实现树状菜单（无法扩展子菜单）

解决方案——树