设计模式之Iterator模式

在之前一篇文章《Java设计模式之六大设计原则》中说到了，设计模式是为了增强代码的可复用性，可拓展性，可维护性，灵活性。也说到几个设计模式的理论知识。这篇文章中主要讲一下Iterator设计模式，贯穿一种面向接口编程的思想，并且印证设计原则。

       我们以一个书架的遍历为例子来讲解说明。现在，我希望定义一个简单的书架，这个书架上可以放书，还需要能遍历这个书架。我们先来看看传统的设计思想。如果按普通的面向实现的编程思想，这很简单。首先，定义一个书架BookShelf类，在这个类中有一个数组books，用于存放书籍。还有一个用于添加书籍的方法appendBook方法，在这个方法中把添加进来的书籍存放到数组中。再有一个getBooks方法返回存放书籍的对象books数组，然后就可以去for循环遍历这个books数组，或者提同一个getBookAt方法直接根据下标来获取书籍，这就达到了我们的目的。这儿就不再写这种代码了，有兴趣的朋友可以自己写一份出来，跟下面的示例代码进行比较。

       然而我今天讲的并不是这么简单的用这种面向实现的方式去实现，因为种编码方式写出来的代码可维护性，灵活性，可复用性很差。因为数组是定长的，不灵活，如果有一天，突然不能用数组去存放书籍了，而是用List集合存放书籍，那可以想一下，我们需要改哪些东西。首先我们需要改书架BookShelf这个类，然后还要更改BookShelf的调用者，这种方式绝对不可取。为什么不可取，我们来看一看瞧一瞧。

      我们先来看看另一种设计思想，再看代码，然后再来说为啥这样用不好。
      首先我们来看，这儿的书架BookShelf类有两个功能。第一，存放书籍。第二，遍历书籍。为了单一职责法则，我想把书架的功能细化，那我就要将遍历书籍这个功能独立出来，用一个迭代器去实现这个功能，并且增加接口来实现。将传统的面向实现过程编程转变为面向接口和抽象编程。这样就弱化了类之间的耦合性，增强了代码的复用性，可维护性和灵活性。
      我们再来看看具体实现，首先我需要定义一个Iterator接口，实现该接口的类用于迭代书架。该接口很简单，有两个个抽象方法，hasNext方法和next方法，用于判断是否还有下一个元素，返回下一个函数。

/**
 * Created by PICO-USER on 2017/3/8.
 */

public interface Iterator {

    public abstract boolean hasNext();

    public abstract Object next();

}

 接着定义一个Aggregate接口，实现该接口的类，可以返回一个Iterator迭代器。iterator方法返回一个迭代器。

/**
 * Created by PICO-USER on 2017/3/8.
 */

public interface Aggregate {