polymorphism

다형성 학습 저장소. 지금은 매개변수에 의한 다형성과 두 다형성의 만남 두 장이 들어 있다.

개념을 글로 읽고 넘기지 않기 위해, 컴파일러가 실제로 무엇을 막고 무엇을 허용하는지를 테스트로 박아둔다. "이론상 이렇다"가 아니라 "돌려보면 이렇다"가 남는 것이 목표다.

Java 21 / Gradle / JUnit 5. 테스트 51개, 전부 통과.

./gradlew test

어디부터 읽나

패키지마다 README가 하나씩 있다. 코드보다 먼저 읽으라고 쓴 것이다.

---

매개변수에 의한 다형성

타입 자체를 인자로 받는다. 코드는 타입 파라미터에 대해 아무것도 가정하지 않고, 그래서 모든 타입에 대해 옳을 수 있다.

두 문서는 같은 축을 반대편에서 본다 — 타입 파라미터가 언제 정해지고 얼마나 오래 사는가.

genericfunction — 함수가 타입을 받을 때

시그니처는 빈칸 (T, R)만 남기고, 그 빈칸은 호출 지점마다 새로 채워진다. 호출이 끝나면 타입 파라미터도 함께 끝난다.

generictype — 타입이 타입을 받을 때

타입 파라미터는 타입을 적는 순간 정해져 그 값이 사는 내내 따라다닌다. 그리고 런타임에는 소거로 지워져, 갈라져 나온 타입들이 다시 클래스 하나가 된다.

---

두 다형성의 만남

앞 장에서는 타입 파라미터를 서로 무관한 빈칸으로만 다뤘다. 그런데 실제 타입들 사이에는 이미 서브타입 관계가 있다. 그 관계가 타입 생성자를 통과할 때 어떻게 되는가 — 세 문서가 같은 물음의 다른 얼굴이다.

문서	묻는 것
inheritance	물려받을 때 타입 인자를 전달할 것인가 고정할 것인가
bound	T에 대해 최소한 무엇을 알아야 하는가
variance	Integer <: Number일 때 Cell<Integer>와 Cell<Number>는 무슨 관계인가

가변성이 이 장의 핵심이다. 불변은 제네릭의 결함이 아니라 읽기와 쓰기를 모두 허용한 대가이고, 그 증거가 배열이라는 반례로 같은 언어 안에 들어 있다.

---

구조

com.study.polymorphism/
├── parametric/                 매개변수에 의한 다형성
│   ├── genericfunction/        함수가 타입을 받는다
│   │   └── Lists.java
│   └── generictype/            타입이 타입을 받는다
│       ├── Stack.java          타입 파라미터 하나
│       ├── Pair.java           타입 파라미터 둘
│       └── ObjectStack.java    대비 - 매개변수가 없던 시절
└── genericsubtyping/           두 다형성의 만남
    ├── inheritance/            제네릭 클래스와 상속
    │   ├── Box.java  Chest.java        타입 파라미터를 전달
    │   └── StringBox.java              타입 인자를 고정 - 브리지 메서드
    ├── bound/                  타입 매개변수 제한
    │   ├── NumberBox.java              상한
    │   ├── Bounds.java                 다중 바운드 - 교차 타입
    │   └── Request.java  JsonRequest.java   재귀 바운드
    └── variance/               가변성
        ├── Source.java  Sink.java  Cell.java   공변 / 반공변 / 불변
        ├── Variance.java                       쓰는 쪽에서 만드는 변성
        ├── CovariantArrays.java                배열이라는 반례
        └── Capture.java                        검사기가 물음표를 여는 과정

패키지를 가르는 기준은 그 절이 던지는 물음이다. 테스트는 src/test/java 아래 같은 구조로 붙어 있다.

이 저장소의 규칙

• 테스트 먼저. 프로덕션 코드는 실패하는 (RED) 테스트를 눈으로 확인한 뒤에 쓴다.
• 정상 경로만 테스트하지 않는다. 빈 컬렉션, 용량 경계, null, 길이 불일치 같은 실패 경로도 함께 고정한다.
• 정책은 코드 옆에 근거와 함께. Stack의 null 거부, zip의 길이 불일치 거부는 둘 다 fail-closed이고, 왜 그렇게 골랐는지가 JavaDoc에 적혀 있다.
• JavaDoc은 "무엇을"이 아니라 "왜". @param source 소스 리스트 같은 동어반복은 달지 않는다. ./gradlew javadoc이 내는 @param 누락 경고는 그래서 나는 것이다.
• 한 줄 = 한 문장. 주석은 문장 경계에서만 줄을 바꾼다. 한 문장을 고치면 diff에 한 줄만 뜬다.
• 문서에 적은 에러 메시지는 실제로 확인한 것만 쓴다. 각 README의 실험 표가 그렇다.