7

Why java.util.Iterator interface has method remove()?

Certainly sometimes this method is necessary and all have become accustomed to its presence. But in fact the main and only objective of the iterator is just to provide access container elements. And when someone wants to create his own implementation for this interface, and cannot or does not want for any reason to provide the ability to remove an element, then he is forced to throw UnsupportedOperationException. And throwing of that exception usually indicates a not too well thought out architecture or some flaws in design.

Really I don't understand the reasons for such a decision. And I guess it would be more correctly separate a specific subinterface to support the optional method:

diagram

Any reasoned versions why remove() is part of the Iterator? Is not this example of a direct violation of the single responsibility principle from SOLID?

janhartmann
  • 14,713
  • 15
  • 82
  • 138
kapandron
  • 3,546
  • 2
  • 25
  • 38
  • 1
    Actually, the "iterator without remove-semantics" which you propose here is equivalent to the legacy [`Enumeration`](http://docs.oracle.com/javase/8/docs/api/java/util/Enumeration.html) interface, which was replaced by `Iterator` in Java 1.2. – Mick Mnemonic Oct 16 '15 at 00:01
  • 1
    What is the other vector of change besides "A new type of underlying collection is introduced"? If you think of SRP as "doing too many things" instead of "having too many reasons to change" you're going to eventually run into some insane normal form where every method in your program has its own interface. – Affe Oct 16 '15 at 00:12

3 Answers3

6

In addition to fancy technical answers ... please consider the timeline too. The "single responsibility principle" was coined by Robert Martin at some point in the middle/late 90es.

The Java iterator interface came into existence with Java 1.2; so around 1998.

It is very much possible that the folks at Sun had never heard of this concept while working on the early releases of Java.

Of course, many smart people have the same ideas without reading a book about it ... so a good designer might have implemented "SRP" like without knowing about "SRP" - but it also requires a high degree of awareness to unveil all the big and small violations of this rule ...

GhostCat
  • 137,827
  • 25
  • 176
  • 248
  • "Agile software development: principles, patterns, and practices" by [Uncle Bob](https://en.wikipedia.org/wiki/Robert_Cecil_Martin) was actually published in 2002. – Mick Mnemonic Oct 16 '15 at 00:20
  • @MickMnemonic I know. But when you carefully study the wikipedia article on SRP ... you will find that the book you are mentioning was based on some articles - and those were written starting 1995 if I am not mistaken! – GhostCat Oct 16 '15 at 12:59
  • The point is not the terminology. The question is whether that is the good solution. From the point of view of common sense and design best practice, and not according to any particular classification or abstract definitions. – kapandron Oct 16 '15 at 23:10
3

This design decision is explained in the Java Collections API Design FAQ. Specifically, see the first question on why collections don't support immutability and instead require optional operations. The short answer is that they didn't want "an explosion" in the number of interfaces.

jaco0646
  • 15,303
  • 7
  • 59
  • 83
2

There seems to be a mix-up of semantics here. Robert C. Martin defines Single Responsibility as a "single reason to change" (SRP.pdf), not as "doing only a single thing". SRP is very much related with cohesion: a software module should only contain things that are functionally related to each other.

With these things in mind, I don't think that having the remove method included in Iterator violates the SRP. Removing an element is often something you might want to do while iterating over the elements; the operations are essentially cohesive. Also, enabling the removal of elements through Iterator makes the Iterable interface (which was added in Java 5) much more powerful. This feature is utilized in e.g. many of the methods in Guava's Iterables utility class.

More info on the history of the term in this excellent article by Uncle Bob himself.

Mick Mnemonic
  • 7,808
  • 2
  • 26
  • 30
  • The issue is not tied semantic forms. Depart from the specific names of principles. That's not the point. I should not have focused on that. I'm interested in evaluation of this decision and its sense. After all, the iterator must not to provide remove operation by its primary purpose and the classic definition. – kapandron Oct 16 '15 at 23:18