참고: JAVA 언어로 배우는 디자인 패턴 입문
For 문과 같이 i 를 하나씩 증가시키면서 배열 Arr의 요소 전체를 처음부터 차례대로 검색하게 됩니다.
여기에서 사용되고 있는 변수 i의 기능을 추상화 해서 일반화한 것을 iterator패턴 이라고 합니다.
StarUML을 이용해 그린 클래스 다이어그램의 동그란 모양은 <
// 집합체를 나타내는 인터페이스
public interface Aggregate {
public abstract Iterator iterator();
}
public interface Iterator {
public abstract boolean hasNext();
public abstract Object next();
}
// 서가를 나타내는 클래스
public class BookShelf implements Aggregate {
private Book[] books;
private int last = 0;
. . . 중략 . . .
@Override
public Iterator iterator() {
return new BookShelfIterator(this);
}
}
// 서가를 검색하는 클래스
public class BookShelfIterator implements Iterator {
private BookShelf bookShelf;
private int index;
public BookShelfIterator(BookShelf bookShelf) {
this.bookShelf = bookShelf;
this.index = 0;
}
@Override
public boolean hasNext() {
if(index < bookShelf> return true;
}else {
return false;
}
}
@Override
public Object next() {
Book book = bookShelf.getBookAt(index);
index++;
return book;
}
}
Q. 왜 Iterator 패턴 같은 조금은 번거로운 패턴을 사용할까요?
Q. 배열이라면 for문을 이용해서 빙글빙글 돌리면 좋을 텐데, 왜 집합체의 외부에 Iterator 역할 같은 것을 만들어야 할까요? Iterator it = bookShelf.iterator();
while( it.hasnext() ) {
Book book = (Book) it.next();
System.out.println(book.getName());
}
여기에서 사용되고 있는 것은 hasNext()와 next()라는 Iterator의 메소드뿐입니다. BookSelf의 구현에서 사용되고 있는 메소드는 호출되고 있지 않습니다. 결국 위 코드의 while 루프는 BookSelf의 구현에는 의존하지 않습니다.
Aggregate 인터페이스나 Iterator 인터페이스를 사용하지 않고, 갑자기 ConcreteAggregate 역할이나 ConcreteIterator 역할을 사용해서 프로그래밍을 하기 쉽습니다. 모든 문제를 구체적인 클래스만으로 해결하려는 욕심이 앞서기 때문입니다.
그러나 구체적인 클래스만 사용하면 클래스 간의 결합이 강해져서, 부품으로 재이용하는 일이 어렵습니다. 결합을 약하게 해서 부품으로 재이용하기 쉽도록 하기 위해 추상 클래스나 인터페이스를 도입합니다.
추가로, '하나씩 나열하는 구조가 Aggregate 역할의 외부에 놓여있다.' 라는 것은 Iterator 패턴의 특징 중 하나입니다. 이 특징으로 인해 하나의 ConcreteAggregate 역할에 대해서 복수의 ConcreteIterator 역할을 만들 수 있습니다.
가입하기
