DEV ℧ Developer Diary

[EffectiveJava] item58 - 전통적인 for 문보다는 for-each 문을 사용하라

Item45에서 정리 했듯이, 스트림이 제격인 작업이 있고 반복문이 제격인 작업이있다.

이번에는 반복문(전통적인 for문)이 제격인 경우에 대해 정리해보도록 하자.

전통적인 for 문

다음은 컬렉션과 배열을 순회하는 전통적인 for문의 예시이다.

컬렉션 순회하기 - 더 나은 방법이 있다.

for (Iterator<Element> i = c.iterator(); i.hasNext();) {
    Element e = i.next();
    ... /** e로 무언가를 한다. */
}

배열 순회하기 - 더 나은 방법이 있다.

for (int i = 0; i < a.length; i++) {
    ... /** a[i]로 무언가를 한다. */
}

반복자와 인덱스 변수는 모두 코드를 지저분하게 할 뿐 우리에게 진짜 필요한건 원소들이다. 1회 반복에서 반복자는 세번, 인덱스는 네번 등장하여 변수를 잘못 사용할 틈새가 넓어진다.

향상된 for 문

이상의 문제는 for-each 문을 사용하면 모두 해결된다. for-each 문의 정식 이름은 ‘향상된 for 문(enhanced for statement)’이다. 반복자와 인덱스 변수를 사용하지 않으니 코드가 깔끔해지고 오류가 날 일도 없다.

컬렉션과 배열을 순회하는 올바른 관용구

for (Element e : elements) {
    ... /** e로 무언가를 한다. */
}

여기서 콜론(:)은 “안의(in)”라고 읽으면 된다. 따라서 이 반복문은 “elements 안의 각 원소 e에 대해” 라고 읽는다.

반복 대상이 컬렉션이든 배열이든 for-each 문을 사용해도 속도는 그대로다. for-each 문이 만들어 내는 코드는 사람이 손으로 최적화한 것과 사실상 같기 때문이다.

전통적인 for문 사용시 실수

아래는 전통적인 for문을 사용할 때 발생할 수 있는 실수이다. 한번 버그를 찾아보도록 하자.

enum Suit { CLUB, DIAMOND, HEART, SPADE }
enum Rank { ACE, DEUCE, THREE, FOUR, FIVE, SIX, SEVEN, EIGHT, NINE, TEN, JACK, QUEEN, KING }

...

static Collection<Suit> suits = Arrays.asList(Suit.values());
static Collection<Rank> ranks = Arrays.asList(Rank.values());

List<Card> deck = new ArrayList<>();
for (Iterator<Suit> i = suits.iterator(); i.haxNext(); )
    for (Iterator<Rank> j = ranks.iterator(); j.haxNext(); )
        deck.add(new Card(i.next(), j.next()));

여기서 문제는 바깥 컬렉션(suits)의 반복자에서 next가 너무 많이 불린다는 것이다.

마지막줄의 i.next()를 주목하자. 이 next()는 ‘숫자(Suit) 하나당’ 한 번씩만 불려야 하는데, 안쪽 반복문에서 호출되는 바람에 ‘카드(Rank) 하나당’ 한 번씩 불리고 있다.

그래서 숫자가 바닥나면 반복문에서 NoSuchElementException을 던진다.

두번째 예를 들어보자. 주사위를 굴렸을 때 나올 수 있는 모든 경우의 수를 출력하는 코드이다. 아래의 코드에도 버그가 있다.

enum FACE { ONE, TWO, THREE, FOUR, FIVE, SIX }
...
Collection<Face> faces = EnumSet.allOf(Face.class);

for (Iterator<Face> i = faces.iterator(); i.hasNext(); )
    for (Iterator<Face> j = faces.iterator(); j.hasNext(); )
        System.out.println(i.next() + " " + j.next());

이 프로그램도 같은 버그지만 결과는 다르게 나타난다. 예외를 던지지는 않지만 가능한 조합을 (“ONE ONE”부터 “SIX SIX” 까지) 36개의 모든 조합이 아닌 단 여섯 쌍만 출력하고 끝나버린다.

이 문제를 해결하려면 바깥 반복문에 바깥 원소를 저장하는 변수를 하나 출력해야 한다.

for (Iterator<Suit> i = suits.iterator(); i.haxNext(); )
    Suit suit = i.next();
    for (Iterator<Rank> j = ranks.iterator(); j.haxNext(); )
        deck.add(new Card(suit, j.next()));

for-each 문을 중첩하는 것으로 이 문제는 간단히 해결된다. 코드도 놀랄 만큼 간결해진다.

for (Suit suit : suits)
    for (Rank rank : ranks)
        deck.add(new Card(suit, rank));

for-each를 사용할 수 없는 상황

하지만 for-each를 사용할 수 없는 상황도 세 가지 존재한다.

  • 파괴적인 필터링(destructive filtering) : 컬렉션을 순회하면서 선택된 원소를 제거해야 한다면 반복자 remove 메서드를 호출해야 한다. 자바 8부터는 Collection의 removeIf 메서드를 사용해 컬렉션을 명시적으로 순회하는 일을 피할 수 있다.
  • 변형(transforming) : 리스트나 배열을 순회하면서 그 원소의 값 일부 혹은 전체를 교체해야 한다면 리스트의 반복자나 배열의 인덱스를 사용해야 한다.
  • 병렬 반복(parallel iteration) : 여러 컬렉션을 병렬로 순회해야 한다면 각각의 반복자와 인덱스 변수를 사용해 엄격하고 명시적으로 제어해야 한다.

세 가지 상황 중 하나에 속할 때는 일반적인 for 문을 사용하되 이번 아이템에서 언급한 문제들을 경계하면 된다.

Iterable 인터페이스

for-each 문은 컬렉션과 배열을 물론 Iterable 인터페이스를 구현한 객체라면 무엇이든 순회 할 수 있다.

public interface Iterable<E> {
    /** 이 객체의 원소들을 순회하는 반복자를 반환한다. */
    Iterator<E> iterator();
}

Iterable을 처음부터 직접 구현하기는 까다롭지만, 원소들의 묶음을 표현하는 타입을 작성해야 한다면 Iterable을 구현하는 쪽으로 고민해보기 바란다.
해당 타입에서 Collection 인터페이스는 구현하지 않기로 했더라도 말이다.