목차
개요
내용
요약
다른 객체들을 가지고 있는 객체(aggregate object)에서 내부 구현을 몰라도 그 안에 있는 객체를 순서대로 접근할 수 있게 해주자
예시
리스트와 같은 자료구조들은 그 안에 있는 요소들을 순회할 수 있는 방법을 제공해줘야 합니다. 또한 요구에 따라 다양한 방식으로 순회할 수 있는 방법을 제공해줄 수도 있어야 합니다. 그렇다면 수많은 요구를 가정하고 이 모든 케이스에 대한 메소드를 리스트 인터페이스에서 제공해줘야 할까요? 이렇게 함으로써 리스트 인터페이스가 비대해지면 사용하기 까다로워질 것입니다. 이럴 때 이터레이터 패턴을 사용할 수 있습니다.

리스트 이터레이터 클래스를 객체화하려면 순회 대상이 되는 리스트 클래스를 줘야하는데요. 이렇게 순회 방법을 리스트 인터페이스와 분리함으로써 다양한 순회 방법을 편리하게 제공해줄 수 있습니다. 예를 들어, 특정 조건을 만족하는 요소만 순회하고 싶다면 FilteredListIterator 클래스를 정의하면 되겠죠.
다만 이터레이트가 순회 대상이 되는 클래스를 반드시 알아야하기 때문에 아래와 같은 연관관계가 생깁니다.

이 때, 일반적인 방법으로 리스트 이터레이터를 생성하려면 그에 상응하는 리스트 클래스가 필요하겠죠. 이 연결을 끊을 수 있는 방법은 리스트 클래스에서 이터레이터를 생성하는 부분을 담당하는 것입니다. 이는 팩토리 클래스의 한 예입니다.
구조

이야깃거리
언제 써야 할까?
- 자료구조의 내부 구현을 노출시키지 않으면서 요소를 순회할 수 있게 하고 싶을 때
- 여러 방법의 순회 방법을 일관된 인터페이스로 제공하고 싶을 때
장단점
- (Pros) 순회 방법과 자료구조 클래스를 디커플링해줍니다. 기존 코드의 수정없이 새로운 순회 방법을 쉽게 추가할 수 있습니다.
- (Cons) 직접 자료구조 클래스를 접근하는 것보다 성능이 떨어질 수 있습니다.
Case Study
Case 1. Java Iteartor , C++ Iterator, . . .
많은 프로그래밍 언어들은 자신들의 자료구조 프레임워크에 이터레이터 패턴을 적용했습니다.
출처
GoF Design Patterns
'Design Patterns' 카테고리의 다른 글
[Design Patterns] Memento (0) | 2024.06.06 |
---|---|
[Design Patterns] Mediator (0) | 2024.05.13 |
[Design Patterns] Interpreter (0) | 2024.04.21 |
[Design Patterns] Command (0) | 2024.03.31 |
[Design Patterns] Chain of Responsibility (0) | 2024.03.31 |