JAVA 컬렉션 자료구조

 

 

 

컬렉션 자료구조

 

 

Java 컬렉션 프레임워크 핵심 정리 (ArrayList vs HashSet + Iterator + equals/hashCode)

0) 컬렉션이 왜 필요해?

자바에서 “여러 개의 객체”를 담는 방법은 크게 2가지가 있어:

• 배열(Array): 크기 고정, 기능 적음
• 컬렉션(Collection Framework): 크기 가변, 기능 풍부(추가/삭제/검색/중복처리/정렬 등)

컬렉션의 대표 라인:

• List: 순서 O, 중복 O → 대표: ArrayList
• Set: 순서 X(보장 안 함), 중복 X → 대표: HashSet

1) List 인터페이스 & ArrayList

1-1. ArrayList 특징

• 저장 순서가 유지됨
• 중복 저장 가능
• get(i)처럼 인덱스로 접근 가능
• 대신 중간 삽입/삭제가 많으면 느려질 수 있음(뒤 요소들이 당겨지거나 밀림)

---

2) 회원관리 예제: MemberArrayList

2-1. 필드와 생성자

한 줄씩 쉽게 해설

• private ArrayList<Member> arrayList;
  → “Member 객체들을 담을 ‘박스(리스트)’를 준비해둘게”
• arrayList = new ArrayList<Member>();
  → “박스를 실제로 만든다(메모리에 생성)”

2-2. 회원 추가: addMember()

2-3. 전체 회원 출력: showAllMember() + 향상된 for문

 

중요 포인트

• for (Member member : arrayList) 는 향상된 for문(= for-each)
  → “리스트의 처음부터 끝까지 하나씩 꺼내서 member 변수에 담아 반복”
• System.out.println(member)
  → 여기서 member는 객체니까, 내부적으로 member.toString()이 호출됨
  → 그래서 Member 클래스의 toString() 구현이 출력 모양을 결정해.

✅ 향상된 for문 문법

 

for (타입 변수 : 컬렉션/배열) {

// 반복 실행문

}

 

⚠️ 주의: 향상된 for문 돌면서 add/remove로 컬렉션을 수정하면 보통 위험(아래 Iterator에서 설명)

 

2-4. 회원 삭제: removeMember(int memberId) (인덱스 기반)

스샷에 나온 형태는 이거야:

 

한 줄씩 핵심만 “왜?” 중심으로 해설

• for (int i=0; i<arrayList.size(); i++)
  → ArrayList는 순서/인덱스가 있으니까 0번부터 끝까지 훑어서 찾는 방식
• arrayList.get(i)
  → i번째 회원 꺼냄
• if (tempId == memberId)
  → “찾는 id면”
• arrayList.remove(i)
  → i번째 요소 삭제 (삭제되면 뒤가 한 칸씩 당겨짐)
• return true
  → “삭제 성공”을 즉시 종료로 알려줌
• 끝까지 못 찾으면 안내문 출력 후 false

2-5. (과제) 특정 위치에 회원 추가: insertMember(member, index)

스샷 힌트: public void insertMember(Member member, int index)

ArrayList는 이미 기능이 있어:

 

add(index, element) → 해당 위치에 끼워넣고, 뒤 요소들은 한 칸씩 밀림

 

3) ArrayList 테스트 코드: MemberArrayListTest

• 회원 생성 → 리스트에 추가 → 전체 출력 → 한 명 삭제 → 다시 출력” 흐름 검증용

---

4) Set 인터페이스 & HashSet

4-1. HashSet 특징

• 중복 불가
• 순서 보장 안 됨 (출력 순서가 매번 같을 필요 없음)
• 내부적으로 “해시(hash)” 구조를 활용해서 평균적으로 빠름

4-2. 문자열 HashSet 예제 (중복 자동 제거)

왜 "소준형"이 한 번만 남을까?

• String은 이미 equals()와 hashCode()가 “문자열 내용 기준”으로 잘 구현되어 있음
• 그래서 HashSet이 “같은 값”으로 판단하고 중복 삽입을 막음

---

5) 사용자 정의 객체를 HashSet에 넣을 때 핵심: equals() + hashCode()

5-1. HashSet이 중복을 판단하는 방식 (진짜 중요)

HashSet은 새 객체를 넣을 때 대충 이런 순서로 검사해:

1. hashCode()로 “들어갈 칸(버킷)”을 먼저 찾고
2. 같은 칸에 이미 누가 있으면 equals()로 “진짜 같은지” 최종 비교

✅ 따라서 규칙:

• equals를 재정의하면 hashCode도 반드시 같이 재정의해야 함
• (둘이 기준이 다르면 HashSet에서 중복이 뚫리거나 검색이 실패할 수 있음)

---

5-2. Member 클래스 예시 (스샷 내용)

한 줄씩 감 잡기

• hashCode()는 “빠른 분류용 번호표”
  • 여기선 memberId가 곧 “회원의 고유 식별자”니까 그대로 반환
• equals(Object obj)의 매개변수가 Object인 이유
  • 자바의 모든 클래스가 Object의 equals를 “오버라이드”하는 구조라서 시그니처가 고정
• instanceof Member로 타입 확인 후 캐스팅
  • 안전하게 Member끼리만 비교하려고
• memberId가 같으면 같은 회원(true)
  • 즉, 이름이 달라도 id만 같으면 “같은 회원”으로 취급

---

6) HashSet으로 회원관리: MemberHashSet

스샷 흐름: HashSet<Member>로 관리하니까 “중복 회원 id”가 들어오면 막히게 만들고 싶은 거야.

6-1. 기본 구조

6-2. 삭제가 왜 Iterator로 바뀌나?

Set(특히 HashSet)은 인덱스가 없어 → get(i) 같은 게 없음
그래서 “전체를 순회하면서 조건을 찾는 방식”이 필요함.

그때 쓰는 도구가 Iterator(반복자)

✅ Iterator 핵심 3개:

• hasNext() : 다음 요소 있냐?
• next() : 다음 요소 하나 꺼내라
• remove() : “방금 next()로 꺼낸 그 요소”를 안전하게 삭제

---

6-3. removeMember(Iterator 버전) — 안전한 정석 코드

스샷에는 hashSet.remove(member) 형태가 있었는데, 실무/정석은 **iterator.remove()**가 더 안전해.
(컬렉션을 순회 중에 컬렉션을 직접 수정하면 ConcurrentModificationException 위험이 있어서)

7) HashSet 테스트: “id 중복이면 추가가 안 돼야 한다”

• equals/hashCode를 memberId 기준으로 해놨으면,
  • 1003은 이미 존재 → 두 번째 추가는 실패(중복으로 판단)

⚠️ 그리고 HashSet은 순서가 보장되지 않아서 출력 순서가 바뀔 수 있음
“입력한 순서대로 출력”이 목표면 → LinkedHashSet을 써야 해.

---

8) 실습 문제: StudentTest (HashSet<Student>)

스샷 요구사항:

• new Student("100","차은재")
• new Student("100","윤아름")
  → 학번이 같으면 중복으로 처리되어 한 명만 남아야 함

8-1. Student 클래스 구현 예시 (핵심: equals/hashCode 학번 기준)

✅ 포인트

• 중복 기준 = studentId
• 출력 형태 = toString()이 결정

⚠️ HashSet 출력 순서가 고정이 아니라서
“100,200,300 순서가 꼭 필요”하면:

• HashSet → LinkedHashSet으로 바꿔서 입력 순서 유지 권장

---

9) 한 장 요약 

• ArrayList(List)
  • 순서 O, 중복 O, 인덱스 O
  • 삭제/삽입 시 요소 이동 발생
• HashSet(Set)
  • 순서 X(보장 안 함), 중복 X, 인덱스 X
  • 중복 판단은 hashCode() → equals() 순서로 함
  • 사용자 정의 객체는 equals/hashCode 둘 다 재정의 필수
• Iterator
  • Set처럼 인덱스 없는 컬렉션 순회/삭제에 필수
  • 순회 중 삭제는 iterator.remove()가 정석

 

응 연아야, 지금 말한 흐름이 거의 정답이고, 딱 한 문장만 정확히 고치면 완벽해져.

---

1) “HashSet에 넣을 때 Student가 오버라이드한 hashCode/equals를 쓴다” → ✅ 맞아

set.add(student) 할 때 HashSet은 Student 객체의 메소드를 이렇게 사용해:

1. student.hashCode()
   → 어느 칸(버킷)에 넣을지 결정
2. 같은 칸에 이미 뭔가 있으면 student.equals(existing)
   → 중복인지 판단

그래서 네 말:

“Student 객체에서는 오버라이드로 새롭게 정의한 hashCode/equals로 판단하게 만들었다”

✅ 맞아.

---

2) “그때 toString도 판단에 쓰나?” → ❌ 아니야 (여기만 수정!)

중요:

• 중복 판단에는 hashCode() + equals()만 사용
• toString()은 중복 판단과 무관
• toString()은 출력할 때만 사용

즉,
✅ “판단은 hashCode/equals, 출력은 toString”
이렇게 역할이 분리돼 있어.

---

3) “toString을 쓰면 String으로 저장된 객체를 출력할 때…” → 개념만 정리하면 ✅

여기서 표현이 살짝 헷갈린 부분:

(A) HashSet에 Student를 넣은 경우

• Set 안에는 Student 객체가 저장돼 (String으로 저장되는 게 아님)
• 출력할 때만:
  • System.out.println(set) → set.toString() 호출
  • 그 내부에서 각 원소에 대해 student.toString() 호출
  • 그래서 우리가 정의한 형식 "학번: 이름" 으로 보이는 거야

✅ 결론: 객체 저장은 객체 그대로 / 출력만 toString() 결과

✅ 정리

• toString()이 “저장되어 있는” 게 아니라,
• 객체가 출력될 때마다 println()이 그 순간 toString()을 호출해서 문자열을 만들어 출력하는 거야.

예시로 느낌 잡기