왜 LinkedList를 통해 Queue Interface를 선언 하는가?(class 아님 주의)

 

혹시나 Collection Framework 자료구조 중의 하나인, Queue에 대해서 모른다면,

먼저 Queue에 관한 게시물을 보고 오자.

 

2025.03.30 - [IT] - Queue 인터페이스

---

Queue Interface를 구현하는 클래스

Queue를 사용할 때는 주로 다음과 같이 선언한다.

Queue<String> queue = new LinkedList<>();

여기서 왜 갑자기 LinkedList가 나왔을까?

 

일단 Queue는 클래스가 아니다. Interface 이므로 바로 선언하여, 직접 객체를 생성할 수가 없다.

 

그래서 인터페이스를 구현한 클래스의 객체를 생성하고,  인터페이스 타입을 참조하는 방식으로 선언한다.

---

Queue와 LinkedList, Deque의 관계

//Queue Interface
public interface Queue<E> extends Collection<E> { 
    // 메서드 선언 (offer, poll, peek 등)
}

//Deque와 Queue의 관계
public interface Deque<E> extends Queue<E> {
}

//LinkedList 선언구조
public class LinkedList<E> extends AbstractSequentialList<E> implements List<E>, Deque<E>, Cloneable, Serializable {
    // Queue 인터페이스 메서드 구현
}

1. Queue Interface는 Collection을 상속한다.

2. Deque Interface는 Queue Interface를 상속한다.

3. LinkedList class는 Deque Interface를 구현(implements)한다.

 

 

Deque<E>는 Queue<E>를 상속하는 인터페이스이므로,
Deque를 구현한 클래스는 자동으로 Queue도 구현하게 된다.

 

그리고 클래스 선언시,

업캐스팅(Upcasting) 을 사용하여 Queue<String> 타입의 변수에 저장한다.(Upcasting == 객체 형변환)

즉, LinkedList의 내부 동작 방식은 유지하면서, Queue 인터페이스의 기능(메서드)만 사용하도록 제한하는 방식으로 선언

 

결과적으로 LinkedList는 Queue도 구현한 것과 같은 효과로 선언한다.

---

 

추가로 배열을 표현하는 ArrayList가 아닌, LinkedList로 Queue를 구현한 이유는 

 

데이터의 추가/삭제가 자주 발생하는 Queue의 구조상, LinkedList로 구현하는 것이 적합하기 때문이다.

 

ArrayList로 구현시,

head쪽의 항목 삭제 후, head +1 ~ tail 까지 배열들의 데이터를 한칸씩 땡겨야 하는 작업이 추가로 필요하다. 

 

하지만 LinkedList는 연결된 삭제된 항목데이터와 연결된 Node만 삭제해주면 되므로, 

데이터의 추가/삭제가 자주발생하는 Queue 구조에 적합하다.