pile·
백엔드·LINE Engineeringline·

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

문제Kotlin 에서 `IntArray` 의 박싱 회피 이점을 살리려 `List<Int>` 를 구현한 `ImmutableIntList` 같은 래퍼를 만들면, 상위 인터페이스의 기본 메서드가 그대로 따라와 의도치 않은 가변 동작·성능 저하가 발생한다.

접근"상위 타입을 상속/구현하면 제약과 책임이 함께 따라온다" 는 관점으로 설계를 재검토. 꼭 필요한 일부 메서드만 노출하거나, 인터페이스 구현 대신 별도 타입으로 한다.

결과박싱 최적화와 불변성을 동시에 얻으려고 인터페이스를 무리하게 구현하는 패턴의 비용을 명시한다. 작은 래퍼 클래스 설계 시 상속의 "상속세" 를 계산하라는 가이드를 제공.

LINE Engineering
LINE Engineering 블로그
원문은 여기서 이어서 읽을 수 있어요
원문 읽기
읽음 (0)
·takedown 요청

이 글과 비슷한

  2. 백엔드·네이버페이네이버페이·

    Composite PK에서 시작된 Spring Boot 4 / Spring Batch 6 업그레이드 기록

    문제Spring Data JDBC 의 Composite ID 적용을 위해 Spring Boot 3.5 → 4.0.1 업그레이드 시 Spring Batch, Kotlin, Jackson 등 전체 스택 메이저 전환 필요.

    접근Spring Boot 4 / Spring Batch 6 / Spring Framework 7 / Kotlin 2.3 / Jackson 3 / Kotest 6 / Gradle 9 / ojdbc11 순차 업그레이드. Composite ID 는 Persistable 인터페이스로 구현, JdbcDefaultBatchConfiguration 상속으로 메타데이터 저장.

    결과기술 부채 해결 + 장기 유지보수성 개선. 운영 DB 접근 정책 충돌을 사전 식별해 안정적 배포 달성.

    #kotlin#spring#spring-boot+3