（三）迭代器模式

假设有个学生类Student，教室类Classroom，教室类中有学生类的数组型的私有变量

public class Student{}
public class Classroom{
	private Student[] students;
}

如果我们将他们new出来，然后组合在一起，如果我们只有教室类，这时想要遍历学生
那么只要new教室类，然后get学生数组，然后for循环遍历学生即可

好，假设我们的业务是这样的，上面已经开发好了，但此时业务变了，我不想用数组来存放学生了
我改用List封装学生，那整个教室类都要改吧

但改了教室类还不算完，进行遍历的代码也需要改，因为此时从教室get的会是一个数组，但我们已经改成List了
这是理想化的业务小的情况，一旦业务大了，逻辑多，这里要改的可就不是一点了

所以显而易见的，我们需要封装一种迭代的机制，效果是：具体要遍历的类，随便怎么改都行，我外面的迭代业务始终不用改
其实思想就是把“迭代”这一步进行抽象，封装了出来，也就是解耦了~

改造办法：
先定义一个迭代器接口，只需要两个方法，判断是否有下一个元素，和获取下一个元素

public interface Iterator {
	public abstract boolean hasNext();
	public abstract Object next();
}

然后写迭代器实现，将教室注入进去，专门迭代教室中的数据，并且默认新建此类时，是从0开始迭代

public class ClassroomIterator implements Iterator {
	private Classroom classroom;
	private int index = 0;

	public boolean hasNext() {
		if(index < classroom.getLength()){
			return true;
		} else {
			return false;
		}
	}
	
	public Object next() {
		Student student = classroom.getStudent(index);
		index++;
		return student;
	}
}

再定义一个工具接口，用于连接迭代类和迭代器，可以返回我们上面定义的迭代器实现

public interface Aggregate {
	public abstract Iterator iterator();
}

学生类不变，在写教室类的时候，实现工具类，最后可以用工具接口得到迭代器，把自己传进去迭代自己，这代码写的厉害。。。

public class Classroom implements Aggregate {
	private Student[] students;
	private int last = 0;
	
	public Classroom(int size) {
		this.students = new Student[size];
	}

	public Student getStudent(int index) {
		return students[index];
	}

	public void addStudent(Student student) {
		this,student[last] = student;
		last++;
	}

	public int getLength() {
		return last;
	}
	
	public Iterator iterator() {
		return new ClassroomIterator(this);
	}
}

具体使用，就不用for循环了：

Iterator iterator = classroom.iterator();
while(iterator.hasNext()) {
	Student student = (Student) iterator.next();
}

这样，如果我们将Classroom类中拼的学生，不用数组，而用其他方法拼装
会发现业务迭代不用改~

综上，迭代器其实就是：A中拼装了B，此时要迭代B，则用A封装迭代的逻辑在肚子里
然后外部写两个接口，一个作为中间工具接口，让A实现，返回迭代器接口
第二个，也就是迭代器接口，让迭代器实现去实现，主要实现hasNext和next方法

实际在业务中，是面向A的迭代器接口去编程，实际上要迭代的A，内部自己怎么迭代的，业务不关心！