티스토리 뷰
아이템 45에서 이야기했듯, 스트림이 제격인 작업이 있고 반복이 제격인 작업이 있습니다.
다음은 전통적인 for 문으로 컬렉션을 순회하는 코드입니다.
for (Iterator<Element> i = c.iterator(); i.hasNext(); ) {
Element e = i.next();
}
그리고 다음은 전통적인 for 문으로 배열을 순회하는 코드입니다.
for (int i = 0; i < a.length; i++) {
... // a[i]로 무언가를 한다.
}
이 관용구들은 while 문보다는 낫지만(아이템 57) 가장 좋은 방법은 아닙니다.
반복자와 인덱스 변수는 모두 코드를 지저분하게 할 뿐 우리에게 진짜 필요한 건 원소들뿐입니다.
더군다나 이처럼 쓰이는 요소 종류가 늘어나면 오류가 생길 가능성이 높아집니다.
1회 반복에서 반복자는 세 번 등장하며, 인덱스는 네 번이나 등장하여 변수를 잘못 사용할 틈새가 넓어집니다.
혹시라도 잘못된 변수를 사용했을 때 컴파일러가 잡아주리라는 보장도 없습니다.
마지막으로, 컬렉션이냐 배열이냐에 따라 코드 형태가 상당히 달라지므로 주의해야 합니다.
이상의 문제는 for-each 문을 사용하면 모두 해결됩니다.
참고로 for-each 문의 정식 이름은 '향상된 for 문(enhanced for statement)'입니다.
반복자와 인덱스 변수를 사용하지 않으니 코드가 깔끔해지고 오류가 날 일도 없습니다.
하나의 관용구로 컬렉션과 배열을 모두 처리할 수 있어서 어떤 컨테이너를 다루는지는 신경 쓰지 않아도 됩니다.
for (Element e : elements) {
// ...
}
여기서 콜론(:)은 "안의(in)"라고 읽으면 됩니다.
따라서 이 반복문은 "elements 안의 각 원소 e에 대해"라고 읽습니다.
반복 대상이 컬렉션이든 배열이든, for-each 문을 사용해도 속도는 그대로입니다.
for-each 문이 만들어내는 코드는 사람이 손으로 최적화한 것과 사실상 같기 때문입니다.
컬렉션을 중첩해 순회해야 한다면 for-each 문의 이점이 더욱 커집니다.
다음 코드에서 버그를 찾아봅시다.
반복문을 중첩할 때 흔히 저지르는 실수가 담겨 있습니다.
enum Suit { CLUB, DIAMOND, HEATRT, 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.hasNext();)
for (Iterator<Rank> j = ranks.iterator(); j.hasNext();)
deck.add(new Card(i.next(), j.next()));
여기 문제는 바깥 컬렉션(suits)의 반복자에서 next 메서드가 너무 많이 불린다는 것입니다.
마지막의 i.next()를 주목합시다.
이 next()는 '숫자(Suit) 하나당' 하나만 불려야 하는데, 안쪽 반복문에서 호출되는 바람에 '카드(Rank) 하나당' 한 번씩 불리고 있습니다.
그래서 숫자가 바닥나면 반복문에서 NoSuchElementException을 던집니다.
정말 운이 나빠서 바깥 컬렉션의 크기가 안쪽 컬렉션 크기의 배수라면 이 반복문은 예외를 던지지 않고 종료합니다.
물론 우리가 원하는 일을 수행하지 않은 채 말입니다.
이 문제를 해결하려면 바깥 반복문에 바깥 원소를 저장하는 변수를 하나 추가해야 합니다.
for (Iterator<Suit> i = suits.iterator(); i.hasNext();) {
Suit suit = i.next();
for (Iterator<Rank> j = ranks.iterator(); j.hasNext();)
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 문을 사용할 수 없는 상황이 세 가지 존재합니다.
파괴적인 필터링
- 컬렉션을 순회하면서 선택된 원소를 제거해야 한다면 반복자의 remove 메서드를 호출해야 합니다.
- 자바 8부터는 Collection의 removeIf 메서드를 사용해 컬렉션을 명시적으로 순회하는 일을 피할 수 있습니다.
변형
- 리스트나 배열을 순회하면서 그 원소의 값 일부 혹은 전체를 교체해야 한다면 리스트의 반복자나 배열의 인덱스를 사용해야 합니다.
병렬 반복
- 여러 컬렉션을 병렬로 순회해야 한다면 각각의 반복자와 인덱스 변수를 사용해 엄격하고 명시적으로 제어해야 합니다.
for-each 문은 컬렉션과 배열은 물론 Iterable 인터페이스를 구현한 객체라면 무엇이든 순회할 수 있습니다.
Iterable 인터페이스는 다음과 같이 메서드가 단 하나뿐입니다.
public interface Iterable<E> {
// 이 객체의 원소들을 순회하는 반복자를 반환한다.
Iterable<E> iterator();
}
Iterable을 처음부터 직접 구현하기는 까다롭지만, 원소들의 묶음을 표현하는 타입을 작성해야 한다면 Iterable을 구현하는 쪽으로 고민해보길 바랍니다.
해당 타입에서 Collection 인터페이스는 구현하지 않기로 했더라도 말입니다.
Iterable을 구현해두면 그 타입을 사용하는 프로그래머가 for-each 문을 사용할 때마다 감사할 것입니다.
정리
- 전통적인 for 문과 비교했을 때 for-each 문은 명료하고, 유연하고, 버그를 예방해준다.
- 성능 저하도 없다.
- 가능한 모든 곳에서 for 문이 아닌 for-each 문을 사용하자.
'JAVA > 이펙티브 자바' 카테고리의 다른 글
아이템[60]. 정확한 답이 필요하다면 float와 double은 피하라 (2) | 2022.05.08 |
---|---|
아이템[59]. 라이브러리를 익히고 사용하라 (0) | 2022.05.08 |
아이템[57]. 지역변수의 범위를 최소화하라 (0) | 2022.05.08 |
아이템[56]. 공개된 API 요소에는 항상 문서화 주석을 작성하라 (0) | 2022.05.07 |
아이템[55]. 옵셔널 반환은 신중히 하라 (0) | 2022.05.07 |
- Total
- Today
- Yesterday
- 이펙티브 자바
- Spring Boot
- Java
- AWS
- Effective Java
- programmers
- C++
- Spring
- Kotlin
- 객체지향
- 알고리즘
- 프로그래머스
- 디자인패턴
- MSA
- kkoon9
- BAEKJOON
- 클린 아키텍처
- 이팩티브 자바
- kotest
- BOJ
- Olympiad
- 디자인 패턴
- JPA
- 테라폼
- 백준
- 클린 코드
- node.js
- 코테
- 정규표현식
- Algorithm
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |