以下是我現階段對迭代器模式的理解
當我們要創建一個集合對象，例如List，Set，Map等，用於存儲另外一個對象時，我們很大機率會有遍歷這個集合對象的需求。這個時候我們經常會很簡單的想到，直接創建實例集合對象，然後用for循環去遍歷這個對象。但當你這樣去做的時候，你會發現，當你需要遍歷這個集合對象的時候，你必須依賴於該集合對象裏的方法。
這裏我用書架對象，和書對象，舉例說明。
以上代碼分別創建了，書對象，和書架對象。
其中書架對象以數組的方式，實現對書對象的存儲。
下面是調用者。我要查閱書架裏所有書的名稱：
觀察可發現，我在調用的時候，直接依賴了書架實例裏面的兩個方法，getLength()和getBookAt(int index)。
這樣的缺點可以想象，如果隨着圖書的增多，或者其他原因。我書架需要改造。也就是說我的bookShelf實體類其中的屬性，或者方法，可能會發生變化。這樣當我改造bookShelf類中的方法或者屬性的時候，我就會非常的擔心，甚至可以說不敢去做改動。因爲我這個類中的方法，都被其他的類直接引用着呢，我一改，其他調用者就很難保證自己不需要跟着做改動。
爲了解決這種問題。我們的迭代器模式就登場了，先看一下登場角色：
1.Iterator(迭代器)
該角色負責定義按順序逐個遍歷元素的接口(api)。在將要展示的代碼中，由Iterator接口扮演這個角色，他定義了hasNext和next兩個方法。其中，hasNext方法用於判斷是否存在下一個元素，next方法則用於獲取該元素。
2.ConcreteIterator(具體的迭代器)
該角色負責實現Iterator角色所定義的接口(api)。在將要展示的代碼中，由BookShelfIterator類扮演這個角色。該角色中，包含了遍歷集合所必須的信息。在示例中，BookShelf類的實例保存在bookShelf字段中，被指向的書的下標保存在index字段中。
3.Aggregate(集合)
這個集合你可以理解爲Connection，該角色負責定義創建Iterator角色的接口(api)。這個接口(api)是一個方法，會創建出"按順序訪問保存在我內部元素的人"。在示例中，由Aggregate接口扮演這個角色，他裏面定義了Iterator方法。
4.ConcreteAggregate(具體的集合)
這個你可以理解爲ArrayList，HashSet等具體的集合類，該角色負責實現Aggregate角色所定義的接口(api)。他會創建出具體的Iterator角色，即ConcreteIterator角色。在示例中，由bookShelf類扮演這個角色，他實現了iterator方法。
先把整個的結構截圖發一下
1.集合
2.迭代器
3.Book類
4.具體集合類BookShelf
5.具體的迭代器BookShelfIterator類
6.調用者Main類
到此所有的展示代碼就展示完了。
回過頭來。還記得我們要解決的問題嗎？
我們要查詢書架中書的名稱。但是之前我們在查詢過程中。嚴重的依賴了書架本身的一些方法。如果書架被改造等發生，他的調用者是會受影響的。
通過以上方式的設計模式。解決了對書架類依賴的硬編碼。這樣編寫BookShelf的開發人員決定放棄用數組來管理書本，而是用java.util.Vector取而代之時，不管BookShelf如何變化，只要BookShelf的iterator方法能正確的返回Iterator的實例(也就是說，返回的Iterator類的實例沒有問題，hasNext和next方法都可以正常工作)，即使不對上面的while循環做任何修改，代碼都可以正常工作。
好好理解一下，爲什麼Iterator方法的返回值不是BookShelfIterator類型而是Iterator類型，他表明了，這段程序就是要使用Iterator的方法進行編程，而不是BookShelfIterator的方法。
