3

So I heard today that returning a iterator is a better solution (low coupling/loose coupling), than returning a arraylist.

I have an arraylist of items, I have a getter for this arraylist, and was wondering why is getting a iterator a better solution then getting a arrayList in java?

Is it because iterator can be converted to different collections if needed? or is there more benefits I am not aware of?

CookieMonster
  • 241
  • 1
  • 9
  • 26
  • also the iterator --at least if used right-- won't tempt you to modify the arraylist while you're iterating over its content, because that arraylist is not involved in the code for processing its elements. – Mike 'Pomax' Kamermans Jun 02 '16 at 19:32
  • 1
    Because you can use different collection implementations to get the iterator, but _all_ collection implementations have iterators. – Louis Wasserman Jun 02 '16 at 19:33
  • @Mike'Pomax'Kamermans: You can *totally* mutate the collection if you wanted to with its iterator. It at least guarantees that you won't *add* more elements, but if you wanted a truly read-only list, `Collections.unmodifiableList()` would be better to return. – Makoto Jun 02 '16 at 19:39
  • Not wrong but I guess what you heard is partially because someone read about the [iterator pattern](https://en.wikipedia.org/wiki/Iterator_pattern) and understood it as "better then list". – zapl Jun 02 '16 at 19:39
  • Mind that there are cases where one prefers to return the concrete type, to give the calling method (or the programmer) certain hints about how to use that instance. For example when one returns one of Guavas [immutable collection classes](https://github.com/google/guava/wiki/ImmutableCollectionsExplained). The calling method should "know", that he can't call certain modifying methods, without getting an exception. Sure, that can also be explained in the JavaDoc, but using that as the return type makes sure, that this won't be missed. – Tom Jun 02 '16 at 20:18
  • @makoto absolutely, hence the "tempt". – Mike 'Pomax' Kamermans Jun 03 '16 at 00:11

3 Answers3

2

Purely from the perspective of loose or tight coupling between the two classes, it's not any different - I'll get some disagreement to that initially, but I'll explain why below. It's a different question if there are better choices for other reasons, but coupling isn't actually one of them.

From an interface perspective, you have class A with a reference to class B that has the collection. B returns the arraylist, meaning it returns java.util.ArrayList (a 3rd-class independent of A or B). If you return an java.util.Iterator, you also have a 3rd class independent of A or B. In neither case does A require more or less knowledge of the inner workings of B, so the coupling remains the same.

However, per comments/other answers, there are other reasons you would potentially prefer to return either a Collection (without specifying the actual implementation) or an Iterator. If you're creating a public API, the choice is important. If you're doing so internal to your own code, use whatever choice is easiest for the caller.

If it's just a class exercise, answer that iterators are looser coupling because they probably don't correctly make the distinction.

user1676075
  • 3,056
  • 1
  • 19
  • 26
2

If you decide some point in time that you dont want to use Arraylist but rather List or anything else , you don't have to change the relying code ..

Tamim Addari
  • 7,591
  • 9
  • 40
  • 59
0

Perhaps a Stream factory would be a better choice. The big win of only exposing collections via Stream is that it better en‐capsulates your domain model’s data structure. It’s impossible for any use of your domain classes to affect the inner workings of your List or Set simply by exposing a Stream. Also read this Should I return a Collection or a Stream?

Community
  • 1
  • 1
Sergey Bulavkin
  • 2,325
  • 2
  • 17
  • 26