T
TechInsights
목록으로
BackEnd•2026. 01. 07.

코드 품질 개선 기법 28편: 제약 조건에도 상속세가 발생한다

라인
라인 Engineering Team
코드 품질 개선 기법 28편: 제약 조건에도 상속세가 발생한다

핵심요약

원문 보기

Kotlin에서 ImmutableIntList와 같이 불변성을 보장하는 클래스를 상속 가능한(open class)으로 만들 경우, 자식 클래스에서 불변성이 깨질 수 있다는 문제를 제기합니다. 불변성을 유지하기 위해서는 상속을 제한하거나, 가변/불변 객체 공통 부모로 '읽기 전용' 타입을 사용하는 것을 제안합니다.

코드 품질 개선: 제약 조건의 상속 문제

1. 불변성(Immutability)과 상속의 충돌

  • 문제 제기: Kotlin에서 IntArray는 효율적이지만, List의 유틸리티 사용 불가. ImmutableIntList 래퍼 클래스 생성 시, 이를 상속받는 ImmutableSortedIntList에서 불변성이 깨질 수 있음.
  • 상속의 함정:
    • ImmutableIntList를 open class로 선언하면 자식 클래스에서 가변적으로 동작하게 만들 수 있음.
    • valueArray를 private으로 해도 get 함수 오버라이딩으로 불변성 침해 가능.
  • 핵심: 범용적인 클래스를 상속 가능하게 만들 경우, 어떤 멤버를 오버라이딩 가능하게 할지 신중한 검토 필요.

2. 불변 객체와 상속 관계 원칙

  • 일반 원칙: 가변 객체 클래스와 불변 객체 클래스는 서로 상속 관계에 놓이지 않도록 해야 함.
  • 가변 객체가 불변 객체에서 상속 시: 불변성 제약 조건 파괴.
  • 불변 객체가 가변 객체에서 상속 시: 변경 메서드 호출 시 런타임 에러 발생.

3. '읽기 전용(Read-only)'을 통한 해결책

  • 공통 부모 클래스 필요 시: **읽기 전용(read-only)**으로 생성하는 것이 권장됨.
  • 가변 객체가 읽기 전용 상속 시: 문제 없음 (메서드 부분 집합).
  • 불변 객체가 읽기 전용 상속 시: 문제 없음 (제약 조건 부분 집합).
  • 결론: 불변성을 보장하려면 상속 불가능하게 만드는 것이 좋음.

4. 고려 사항

  • 독립된 타입 정의: 상속 관계 대신 독립된 타입으로 정의하는 것을 고려.
  • 키워드: immutability, inheritance, override
#BackEnd
라인
라인

라인 Engineering Team

기술 인사이트를 전달하는 공식 채널

You might also like

View all
토스 피플 : 새로운 길을 만들 땐 내 선택을 믿는다

토스 피플 : 새로운 길을 만들 땐 내 선택을 믿는다

"이 버튼 왜 안 눌려요?" 물류 현장의 목소리로 PDA 시스템 완성하기

"이 버튼 왜 안 눌려요?" 물류 현장의 목소리로 PDA 시스템 완성하기