Iterator Design Pattern [Behavioral]
Tags: blog, designpattern, designpatterns, programming
Published: 2019-03-12 16:18:24

---
title: Iterator Design Pattern [Behavioral]
published: true
tags: blog,Design Pattern,Design Patterns,programming
canonical_url: https://itscoderslife.wordpress.com/2019/03/08/iterator-design-pattern-behavioral/
---

 **Why?** To traverse through containers of objects.

There are different structures that let us store data in a structured format. A data structure should provide a way to step through its elements. We could come up with different solutions to access their elements sequentially. As a result, the interface of these data structures will be cluttered with operations for different traversers, and these operations would vary from type to type, which in turn makes them hard to use and maintain.

The iterator pattern addresses this problem. It provides a standard interface for traversing different types of aggregate objects. The iterator encapsulates the access and traversal logic in a separate type; thus, it removes these responsibilities from the data structure. So we don’t have to expose any of the details of the underlying data structure to iterate to its elements.

- Provides sequential access to the elements of an aggregate object.
- Encapsulates the operations for different traversals into a dedicated iterator type.
- Does not expose the internal structure of the traversed object.
- The iterator must keep track of the traversed elements.
- Calling its _next_ method returns the current element, and it advances one step in the sequence.
- The iterator pattern is one of the most frequently used ones.

> The iterator provides sequential access to the elements of a container without exposing its underlying details. It removes the operations for different traverses from the data structure itself.

Now, let’s take a look at the design of the iterator pattern. In most languages, all built-in collection types, the array, the set, and the dictionary, conform to a sequence interface/protocol. Our custom types must also adopt that interface if we need to iterate through their elements.

The Iterator Protocol provides a unified interface for accessing the items in sequence one at a time. The _next_ method advances to the next element in the sequence and returns it. Actually, we’re using the given type’s iterator whenever we rely on the for-in loop to iterate through its items.

Example: Stack, Queue, LinkedList, Arrays etc all have iterators.

Here’s a straightforward example of iterating through the elements of an array. The compiler generates the following code. It first creates an iterator by calling the array’s make Iterator method. Then, the while loop calls the iterator _next_. The loop exits when the _next_ method does not return a valid value. Knowing these details is important when implementing custom iterators. Our _next_ method implementation must also return nil or an invalid value to signal the end of the sequence; otherwise, the loop will continue forever.

Always consider the performance impact of your iterator implementation. The next method must not perform slow or computationally-intensive operations.