Question

In C#, the IEnumerator interface defines a way to traverse a collection and look at the elements. I think this is tremendously useful because if you pass IEnumerable<T> to a method, it’s not going to modify the original source.

However, in Java, Iterator defines the remove operation to (optionally!) allow deleting elements. There’s no advantage in passing Iterable<T> to a method because that method can still modify the original collection.

remove‘s optionalness is an example of the refused bequest smell, but ignoring that (already discussed here) I’d be interested in the design decisions that prompted a remove event to be implemented on the interface.

What are the design decisions that led to remove being added to Iterator?

To put another way, what is the C# design decision that explicitly doesn’t have remove defined on IEnumerator?

Answer 1

Iterator is able to remove elements during iteration. You cannot iterate collection using iterator and remove elements from target collection using remove() method of that collection. You will get ConcurrentModificationException on next call of Iterator.next() because iterator cannot know how exactly the collection was changed and cannot know how to continue to iterate.

When you are using remove() of iterator it knows how the collection was changed. Moreover actually you cannot remove any element of collection but only the current one. This simplifies continuation of iterating.

Concerning to advantages of passing iterator or Iterable: you can always use Collection.unmodifireableSet() or Collection.unmodifireableList() to prevent modification of your collection.