JAVA : 상속

상속

상속관계에서는 상위 클래스가 하위 클래스보다 일반적인 개념이고, 하위 클래스는 상위 클래스보다 구체적인 클래스가 됩니다

 

 

메소드 오버로드 vs 메소드 오버라이딩

 

메소드 오버라이딩 

상위클래스에 정의한 메소드가 하위 클래스에서 구현할 내용과 맞지 않을 경우에 하위클래스에서 이 메소드를 재정의할 수 있습니다. 이를 메소드 오버라이딩 이라고 합니다.

▪오버라이딩을 하려면 반환형, 메소드 이름, 매개변수개수, 자료형이 반드시 같아야 합니다

 

 

다형성(polymorphism)

상위클래스에서 공통 부분의 메소드를 제공하고, 하위클래스에서는 그에 기반한 추가 요소를 덧붙여 구현하면 코드 양도 줄어들고 유지보수도 편리합니다. ▪ 다형성에 의해 각 클래스의 여러 가지 구현을 실행할 수 있으므로 프로그램을 쉽게 확장할 수 있습니다. (하나의 객체가 여러 가지 타입을 가질 수 있는 것을 다형성이라 하며, 반대로 한가지 형태만 가지는 성질을 단형성이라 합니다.)

 

EX) 상속을 받았다는 전제 하에서, VIPCustomer는 Customer형일수도있지만, VIPCustomer일수도 있다.

VIPCustomer customerYeon = new VIPCustomer(); 도  가능. 

 

 

추상클래스

추상클래스

1) 추상클래스(abstract class)란? ✅ 추상클래스의 핵심 특징 2개

1. 객체 생성 불가
   • new Computer() ❌
   • 이유: 아직 “완성품”이 아니라서.
2. 추상 메서드(abstract method)를 가질 수 있음
   • 추상 메서드는 선언만 있고 구현(몸통 {})이 없음
   • “이 기능은 하위 클래스가 꼭 만들어라!” 강제 규칙

2) computer는 추상클래

 

• display() / typing() 은 추상 메서드
  • “컴퓨터라면 화면 출력(display)과 타이핑(typing)은 있어야 하는데,
    구체적으로 어떻게 할지는 종류마다 다르니까 자식이 구현해!”
• turnOn() / turnOff() 는 구현된 메서드
  • 컴퓨터든 노트북이든 공통이니까 여기서 기본 동작 제공

✅ 즉, Computer는
공통 기능(전원 on/off)은 제공 + 반드시 필요한 기능(display/typing)은 구현을 강제 하는 “뼈대”야.

 

3) 왜 DeskTop은 일반 클래스고 NoteBook은 추상 클래스야?

(1) DeskTop은 “추상 메서드 2개를 전부 구현”했음 → 완성품 ✅

• display() + typing() 둘 다 구현했으니 이제 객체 생성 가능
• new DeskTop() ✅

---

(2) NoteBook은 “추상 메서드 2개 중 1개만 구현”했음 → 아직 반제품 ❗

 

• Computer가 요구한 추상메서드가 2개였지? (display, typing)
• NoteBook이 display()만 구현하고 typing()은 안 했어.
• 그러면 NoteBook은 아직 “완성품”이 아니므로 자기 자신도 추상클래스가 되어야 함
• 그래서 abstract class NoteBook 이 되는 거야.

(3) MyNoteBook이 최종 완성품 ✅

 

• NoteBook이 못 끝낸 typing()을 MyNoteBook이 구현해서
• 이제 추상 메서드가 전부 구현 완료
• 그래서 new MyNoteBook() ✅ 가능

 

4) 왜 new Computer(), new NoteBook()이 안 되는지 (너의 테스트 코드)

✅ 중요한 포인트

• Computer c2 = new DeskTop(); 처럼 타입은 부모(Computer)로 잡고
• 실제 객체는 자식(DeskTop / MyNoteBook) 으로 만들 수 있어.
• 이게 바로 다형성이고, 추상클래스의 가장 큰 존재 이유 중 하나야.

 

5) 추상클래스를 왜 쓰는가? (진짜 이유)

✅ 3가지 이유만 기억하면 돼

1. 공통 코드 재사용
   • turnOn(), turnOff() 같은 건 부모에서 한 번만 구현
2. 규칙 강제
   • “컴퓨터라면 display, typing은 무조건 구현해라”
   • 이 강제가 없으면 어떤 클래스는 typing을 빼먹고도 컴파일이 될 수 있음
3. 다형성 설계
   • Computer 타입 하나로 DeskTop, MyNoteBook을 똑같이 다루게 만들기

→ 똑같은 코드로 데스크탑/노트북이 각각 자기 방식으로 동작

 

 

Java 추상클래스 + final + 템플릿 메서드 패턴: Player Level 시스템으로 이해하기

게임에서 “레벨”이 바뀌면 가능한 행동이 달라진다.

• 초보자: 달리기(run) 가능
• 중급자: 달리기(run) + 점프(jump) 가능
• 고급자: 달리기(run) + 점프(jump) + 회전(turn) 가능

하지만 중요한 건,

레벨이 달라도 “플레이 흐름(go)” 자체는 항상 일정하다는 점이다.

예를 들어 go(count)는 항상 아래 시나리오를 따른다:

1. run 1번
2. jump를 count번
3. turn 1번

이처럼 실행 순서(시나리오)는 고정하고,
각 행동의 내용만 레벨에 따라 바꾸는 방식이 바로 템플릿 메서드 패턴이다.

---

1) 전체 구조 한 눈에 보기

핵심 클래스 관계

• PlayerLevel : 레벨들의 공통 규칙(추상클래스)
• BeginnerLevel / AdvancedLevel / SuperLevel : 레벨별 구현체
• Player : 현재 레벨을 들고 있고, 레벨을 교체할 수 있음
• PlayBoard : 실행 테스트(레벨 업하면서 play)

---

2) “템플릿 메서드”란?

템플릿 메서드는

“전체 실행 순서는 고정해두고(final), 내부 단계(추상 메서드)만 하위 클래스에서 구현하게 하는 메서드”다.

즉,

• go()는 “흐름/시나리오”를 정의한다. → 바꾸면 안 됨 → final
• run/jump/turn은 레벨마다 달라지는 동작이다. → 하위 클래스가 구현

---

3) BeginnerLevel 코드가 의미하는 것

너가 올린 초보자 레벨은 다음을 구현한다:

 

포인트

• 초보자는 run은 가능
• jump/turn은 “기능이 없음” 메시지로 대체
• 레벨 안내 메시지를 출력

✅ 즉, “기능을 못 하면 예외로 죽이는 게 아니라 안내 메시지로 처리”하는 설계다.

---

4) Player 클래스: “레벨을 갈아끼우는 본체”

 

여기서 중요한 점 2개

(1) Player는 “레벨 행동”을 직접 구현하지 않는다

• run/jump/turn을 Player가 직접 갖고 있으면 레벨이 늘어날 때마다 Player가 비대해진다.
• 그래서 레벨별 동작은 PlayerLevel 하위 클래스에 위임한다.

(2) upgradeLevel()로 “행동 세트”를 통째로 교체

• 레벨이 바뀐다는 건, Player가 들고 있는 level 객체가 바뀐다는 의미
• 즉, 내부 전략(동작 규칙)을 갈아끼우는 방식이라서
  • 설계 관점에서는 Strategy/State 패턴 느낌도 함께 가진다.

---

5) PlayBoard(실행 코드) 흐름 해석

 

실행 시나리오

1. Player 생성 → 기본 레벨 BeginnerLevel 세팅
2. BeginnerLevel로 go(1) 실행
3. AdvancedLevel로 교체 → go(2) 실행
4. SuperLevel로 교체 → go(3) 실행

✅ Player는 play(count)만 호출하지만
실제 행동(출력)은 “현재 level 객체”가 결정한다.
→ 이것이 **다형성(polymorphism)**의 핵심이다.

---

6) go(count)가 왜 “final”이어야 할까?

go()는 “게임 규칙(시나리오)” 그 자체다.

예를 들어 누군가가 고급 레벨에서 go()를 마음대로 바꾸면?

• run을 안 하고 jump부터 한다거나
• turn을 빼먹거나
• jump 횟수 규칙을 바꿔버리면

게임의 레벨 시스템 규칙이 깨진다.

그래서 보통 PlayerLevel에서

• go()는 final로 고정
• run/jump/turn만 바꾸게 설계한다

결론: “순서(룰)는 고정, 내용(행동)은 변경” 구조가 템플릿 메서드 패턴이다.

---

7) 이 설계의 장점

✅ 1) 확장에 강함

새 레벨 MasterLevel을 추가하려면?

• PlayerLevel을 상속받아 run/jump/turn/showLevelMessage만 구현하면 끝
• Player 코드는 바꿀 필요 없음

✅ 2) 중복 제거

모든 레벨에서 “go 흐름”을 똑같이 쓰니까

• run → jump(count번) → turn
  이 시나리오를 한 곳에만 둔다.

✅ 3) 규칙 강제

레벨 클래스는 반드시 run/jump/turn을 구현하게 된다.
(추상메서드 강제)

---

8) 이 예제가 동시에 보여주는 개념 요약

• 추상클래스(abstract class): 공통 규칙(메서드 시그니처) 강제 + 일부 공통 구현 제공
• 다형성(Polymorphism): level.go() 호출해도 실제 동작은 레벨 객체가 결정
• final 메서드: 실행 순서(룰)를 하위 클래스가 못 바꾸게 막음
• 템플릿 메서드 패턴: “고정된 실행 순서 + 변경 가능한 단계 메서드”