The Iterator design pattern solves problems like:
How can the elements of an aggregate object be accessed and traversed
without exposing its underlying representation?
See Applicability section for all problems Iterator can solve. See Solution section for how Iterator solves the problems.

• One way to solve this problem is to extend the aggregate interface with operations for access and traversal.
  For example, traversing front-to-back: next(),hasNext().
• This commits the aggregate object to particular access and traversal operations and makes it impossible to add new operations later without having to change the aggregate interface.
  For example, traversing back-to-front: previous(),hasPrivious().
  "But you probably don't want to bloat the List [Aggregate] interface with operations for different traversals, even if you could anticipate the ones you will need." [GoF, p257]
• That's the kind of approach to avoid if we want to define new access and traversal operations without having to change the aggregate interface.
• For example, an aggregate object like a list, set, or other kind of collection.
  It should be possible to access and traverse the elements of a collection in different ways without knowing (depending on) its representation (data structures). See Sample Code / Example 2.