[Class-13] 제네릭 / 컬렉션

자바 [JAVA] - Comparable 과 Comparator의 이해

자바 [JAVA] - Comparable 과 Comparator의 이해

 

선생님 블로그. 

이해할 때 까지 읽는다.

 

 

 

◆ 제네릭 이전 코드의 문제점: "타입 안전성의 붕괴"

제네릭 코드는  아무거나 다 담을 수 있는 장점이 될 수 있지만, 동시에 "무엇이 담겨 있는지 확인할 방법이 없다"는 치명적인 약점이 있다.

1. 프로그래머의 실수 시나리오

 

// 제네릭이 없는 List (Object를 저장함)
List list = new ArrayList();

// 프로그래머는 당연히 Human 객체만 들어있을 것이라 가정하고 코드를 짬
list.add(new Human("이무진", 25));
list.add(new Human("이창섭", 30));

// 실수 발생: 실수로 Human 객체가 아닌 String 문자열을 넣어버림
list.add("임재현"); 

2. 컴파일러의 태도

• 컴파일 과정: 컴파일러는 list.add("임재현"); 구문을 볼 때 "어, ArrayList는 Object를 담는 곳이네? 문자열(String)도 Object의 자식이니까 허용!"이라고 판단.
• 결과: 오류(Error)가 전혀 발생하지 않는다. 컴파일러는 프로그래머가 실수로 다른 타입을 넣었는지 전혀 알지 못함

3. 런타임(실행 시)의 재앙

문제는 데이터를 꺼낼 때 발생한다. 프로그래머는 리스트에 Human만 있다고 믿고 강제 형변환(Casting)을 시도.

 

for (int i = 0; i < list.size(); i++) {
    // 💡 프로그래머: "여긴 다 Human 객체야!"
    Human h = (Human) list.get(i); 
    System.out.println(h.getName());
}

• 결과: 리스트에 들어있던 String 객체를 Human으로 강제 형변환하려는 순간, ClassCastException이라는 런타임 오류가 발생하며 프로그램이 그 자리에서 강제 종료.

◆ 핵심 차이점: "컴파일 vs 런타임"

구분	제네릭 이전 (Object 관리)	제네릭 이후 (<Human> 명시)
타입 확인 시점	런타임 (프로그램 실행 중)	컴파일 (코드 작성 및 빌드 중)
오류 발견	실행 중에 터져서 프로그램 멈춤	코드를 짜는 중에 빨간 줄로 경고함
안전성	매우 낮음 (실수 방지 불가)	매우 높음 (실수 즉시 수정 가능)

◆ 제네릭이 해결하는 방식 (실수 원천 차단)

만약 List<Human> list = new ArrayList<>();라고 제네릭을 명시했다면 어떤 일이 생길까.

 

List<Human> list = new ArrayList<>();
list.add(new Human("이무진", 25));

// ❌ 컴파일러의 강력한 제재
// "Human 타입만 들어올 수 있는데, 왜 String을 넣으려 해?"
list.add("임재현"); // 🚩 여기서 즉시 컴파일 에러 발생!

요약하자면:

 제네릭은 컴파일러가 "작성한 코드가 타입 측면에서 완벽한지 미리 검사"하게 함으로써, 프로그래머의 사소한 실수(다른 타입 입력)를 즉시 수정 가능한 상태로 잡아주는 것

자바 컬렉션 프레임워크는 데이터를 효율적으로 관리하려고 만든 '데이터 보관소' 모음임. 상황에 따라 골라 쓸 수 있게 도구들이 정리되어 있음.

1. 컬렉션 프레임워크 핵심

자바에서 데이터를 담는 인터페이스들이야. 크게 세 가지(Set, List, Queue)와 독립적인 Map이 있음. 다들 제네릭(<E>)을 써서 원하는 자료형만 딱 담을 수 있게 구현되어 있음.

2. Set 인터페이스와 HashSet

Set은 '중복 없는 주머니'라고 생각하면 됨.

• 순서 없음: 넣은 순서대로 나오지 않음.
• 중복 불가: 같은 데이터를 또 넣으려고 하면 거부함.

Java

 

Set<String> set = new HashSet<>();
set.add("Toy");
set.add("Box");
set.add("Robot");
set.add("Box"); // 이미 있어서 추가 안 됨
// 결과적으로 데이터는 3개만 남음

3. "그렇다면 동일 인스턴스의 기준은?"

Set이 중복을 판별하려면 '이게 같은 데이터인지' 알아야 함.

• 기본 클래스(String 등): 자바가 이미 같은지 비교하는 법을 알고 있어서 문제없음.
• 직접 만든 클래스(Human 등): 자바가 모름. 그래서 우리가 직접 equals()랑 hashCode()를 재정의해서 알려줘야 함.

1. hashCode(): 데이터를 담을 때 해시값(주소표) 생성.
2. equals(): 해시값이 같을 때, 실제 내용물이 같은지 1:1 비교.

 

1. 해시 알고리즘의 핵심 개념

해시(Hash) 알고리즘은 데이터를 빠르게 찾기 위해 데이터를 분류해 놓는 기술

쉽게 말해 '도서관의 분류 체계'와 비슷

• 분류 대상: 3, 5, 7, 12, 25, 31
• 분류 규칙(해시 함수): num % 3 (숫자를 3으로 나눈 나머지)

데이터를 3으로 나눈 나머지에 따라 방(연산결과)을 0, 1, 2번으로 나눴음.

• 연산결과 0: 3(3%3=0), 12(12%3=0)
• 연산결과 1: 7(7%3=1), 25(25%3=1), 31(31%3=1)
• 연산결과 2: 5(5%3=2)

2. 왜 이렇게 분류함? (속도 때문)

만약 데이터를 섞어놓고 "25가 있니?"라고 물어보면, 무식하게 하나씩 다 뒤져야 함. 하지만 위처럼 분류를 해놓으면?

• "25 찾으려면? 25 % 3 = 1이니까 연산결과 1번 방만 뒤지면 됨."
• 나머지 0번 방과 2번 방은 아예 쳐다볼 필요도 없음. 이게 탐색 속도가 미친 듯이 빨라지는 이유임.

3. 자바의 hashCode() 메서드

자바의 Object 클래스에 있는 hashCode()는 바로 이 역할을 함.

• 우리가 HashSet에 객체를 넣으면, 자바는 그 객체의 hashCode()를 호출해서 "이 녀석은 몇 번 바구니에 담을까?"를 결정함.
• 그리고 나서 equals()를 호출해 "혹시 이 바구니에 똑같은 내용물 가진 놈이 이미 있나?"를 확인해서 중복을 걸러내는 것임.

요약하자면:

1. hashCode(): 데이터를 담을 바구니 주소를 정하는 '분류 알고리즘'
2. equals(): 바구니 안에서 진짜 같은지 확인하는 '검증 알고리즘'