immutability

코드 품질 개선 기법 28편: 제약 조건에도 상속세가 발생한다 (새 탭에서 열림)

코드의 불변성을 보장하기 위해 설계된 클래스가 상속을 허용할 경우, 자식 클래스에서 해당 제약을 위반함으로써 시스템 전체의 안정성을 해칠 수 있습니다. 특히 `Immutable`이라는 이름을 가진 클래스가 가변적인 자식 클래스를 가질 수 있게 되면 개발자의 의도와 다른 런타임 동작이 발생할 위험이 큽니다. 따라서 특정 제약 조건을 강제하고 싶다면 클래스를 상속 불가능하게 설계하거나, 공통의 '읽기 전용' 인터페이스를 활용하는 구조적 접근이 필요합니다. ### 불변성 보장을 방해하는 상속 구조 * Kotlin의 `IntArray`를 래핑하여 성능과 불변성을 동시에 잡으려는 `ImmutableIntList` 예시를 통해 상속의 위험성을 설명합니다. * 클래스를 상속 가능(`open`)하게 설정하면, `Immutable`이라는 명칭에도 불구하고 이를 상속받아 내부 상태를 변경하는 `MutableIntList`와 같은 자식 클래스가 생성될 수 있습니다. * 외부에서는 `ImmutableIntList` 타입으로 참조하더라도 실제 인덱스 값이 변할 수 있는 객체를 다루게 되어, 불변성을 전제로 한 로직에서 오류가 발생합니다. ### 멤버 오버라이딩을 통한 제약 조건 우회 * 내부 데이터 구조를 `private`이나 `protected`로 보호하더라도, 메서드 오버라이딩을 통해 불변성 제약을 우회할 수 있습니다. * 예를 들어 `get` 연산자를 오버라이딩하여 내부 배열이 아닌 가변적인 외부 필드 값을 반환하도록 재정의하면, 클래스의 핵심 규약인 '불변 데이터 제공'이 깨지게 됩니다. * 범용적인 클래스일수록 예상치 못한 곳에서 잘못된 상속이 발생할 가능성이 높으므로, 어떤 멤버를 노출하고 오버라이딩을 허용할지 엄격하게 제한해야 합니다. ### 가변·불변 객체의 올바른 상속 관계 * 가변 객체가 불변 객체를 상속하면 불변성 제약이 깨지고, 불변 객체가 가변 객체를 상속하면 불필요한 변경 메서드(`add`, `set`)로 인해 런타임 에러가 발생할 수 있습니다. * 가장 이상적인 구조는 가변 객체와 불변 객체가 모두 '읽기 전용(Read-only)' 인터페이스나 클래스를 상속받는 형태입니다. * 가변 객체는 읽기 전용 부모의 메서드 집합을 확장하고, 불변 객체는 읽기 전용 부모의 제약 조건을 확장하는 방식(예: Kotlin의 `List` 구조)이 안전합니다. 특정 제약 조건(불변성 등)이 핵심인 클래스를 설계할 때는 기본적으로 상속을 금지(`final`)하고, 확장이 필요하다면 상속 대신 독립된 타입을 정의하거나 읽기 전용 인터페이스를 통한 계층 분리를 권장합니다.

코드 품질 개선 기법 25편: 요컨대... 무슨 말이죠? (새 탭에서 열림)

효과적인 코드 리뷰를 위해서는 리뷰 코멘트를 작성할 때 결론인 제안이나 요청 사항을 가장 먼저 제시하고, 그에 따른 근거와 이유는 뒤에 덧붙이는 구조를 취해야 합니다. 이러한 방식은 리뷰 요청자가 코멘트의 핵심을 즉각적으로 파악하게 하여 전체적인 리뷰 프로세스의 효율성을 높여줍니다. 명확한 구조로 작성된 코멘트는 불필요한 재독을 줄이고 제안된 의견의 타당성을 더 빠르게 검증할 수 있게 돕습니다. **불명확한 리뷰 코멘트의 예시와 문제점** * **가변 객체 사용의 위험성**: Kotlin의 `data class`에서 속성을 `var`로 선언하면 외부에서 객체의 상태를 직접 변경할 수 있어, 의도치 않은 시점에 데이터가 수정되는 버그를 유발할 수 있습니다. * **불필요한 인스턴스 공유**: 상태를 업데이트할 때 새로운 불변 인스턴스를 생성하는 대신 동일한 가변 객체를 공유하면 시스템의 견고함이 떨어집니다. * **정보 전달의 지연**: 제안 사항(모든 속성을 `val`로 변경하고 클래스를 분리할 것)이 코멘트의 마지막에 위치하면, 작성자는 긴 설명을 다 읽은 후에야 무엇을 고쳐야 하는지 알게 되어 인지적 부담이 커집니다. **제안 사항 우선 방식의 코멘트 구조화** * **핵심 제안 선행**: 코멘트의 첫머리에 "데이터 업데이트 빈도에 따라 클래스를 분리하고 속성을 `val`로 선언하세요"와 같이 구체적인 액션을 명시합니다. * **근거의 범주화**: 제안 뒤에 붙는 이유는 '객체의 불변성'과 '값의 라이프사이클'처럼 논리적인 항목으로 나누어 설명합니다. * **가독성 향상 기법**: 설명해야 할 항목이 몇 개인지 미리 밝히고(예: "다음 두 가지 측면에 기반합니다"), 각 항목에 제목을 붙여 구조화하면 전달력이 극대화됩니다. **데이터 모델링의 기술적 개선 방향** * **불변성 유지**: `data class`에서는 `var` 대신 `val`을 사용하여 `copy` 함수를 통한 예측 가능한 상태 업데이트를 지향해야 합니다. * **라이프사이클에 따른 분리**: 사용자 ID와 같이 거의 변하지 않는 속성과, 온라인 상태나 상태 메시지처럼 자주 변하는 속성을 별도의 클래스(예: `UserModel`과 `UserStatus`)로 분리하면 잘못된 업데이트를 방지하기 쉬워집니다. 리뷰 코멘트를 작성할 때는 '빠른 이해'를 목표로 결론부터 쓰는 것이 기본입니다. 다만, 상대방이 스스로 답을 찾아보게 하거나 깊은 고민을 유도하고 싶을 때는 의도적으로 중요한 부분을 뒤에 배치하는 전략을 취할 수도 있습니다. 상황에 맞는 적절한 설명 순서가 코드 품질과 팀의 개발 문화를 결정짓는 중요한 요소가 됩니다.

코드 품질 개선 기법 17편: 사상누각 (새 탭에서 열림)

무분별한 빌더 패턴의 사용은 필수 인자의 누락을 런타임 시점에야 발견하게 만들어 코드의 안정성을 해칠 수 있습니다. 견고한 소프트웨어를 구축하기 위해서는 런타임 에러 대신 컴파일 타임에 결함을 발견할 수 있는 생성자나 팩토리 함수를 우선적으로 고려해야 합니다. 특별한 제약 사항이 있는 경우가 아니라면, 프로그래밍 언어의 기능을 활용해 불완전한 객체 생성을 원천 차단하는 것이 코드 품질 개선의 핵심입니다. **빌더 패턴의 한계와 위험성** * 전통적인 빌더 패턴은 필수 인자가 누락되어도 컴파일 단계에서 이를 감지하지 못하며, `build()` 호출 시점에 `IllegalStateException` 등의 런타임 에러를 발생시킨다. * 이는 '사상누각'처럼 기초가 불안정한 코드를 양산하는 결과를 초래하므로, 컴파일러가 인자 누락을 체크할 수 있는 생성자 기반 설계를 지향해야 한다. **기본값이 있는 인자가 많은 경우의 대안** * Kotlin과 같이 기본 인수를 지원하는 언어에서는 빌더 대신 생성자에 기본값을 설정함으로써 인자 전달의 유연성을 확보하고 가독성을 높일 수 있다. * 만약 환경상 빌더 패턴을 반드시 사용해야 한다면, 필수 인자만큼은 빌더의 생성자 인수로 직접 전달받도록 설계하여 누락 가능성을 구조적으로 방지한다. **생성 중인 상태의 처리와 타입 구분** * 빌더 객체를 다른 함수에 인자로 전달해 값을 채우는 방식(출력 인수)은 가독성을 떨어뜨리므로, 값을 반환받아 생성자나 팩토리 함수에 전달하는 방식으로 개선하는 것이 바람직하다. * 객체 생성 로직이 복잡한 파이프라인 형태라면 각 단계마다 서로 다른 타입을 정의함으로써, 유효하지 않은 중간 상태의 객체가 사용되는 것을 방지할 수 있다. **빌더 패턴이 효과적인 상황: 마지막 작업 정의** * 0회 이상 임의의 순서로 적용되는 작업이 있고, 특정 '마지막 작업(terminal operation)'을 통해 최종 결과를 산출해야 하는 경우에는 빌더 패턴과 유사한 구조가 유용하다. * 예를 들어 이미지 편집 과정(crop, filter 등)에서 데코레이터 패턴을 사용할 때, 빌더 형식을 도입하면 순수 데코레이터 패턴보다 중첩 구조가 단순해져 가독성이 크게 향상된다. 객체 생성 시 발생할 수 있는 결함을 런타임이 아닌 컴파일 타임에 검출할 수 있도록, 가장 먼저 생성자나 팩토리 함수 사용을 검토하세요. 빌더 패턴은 언어적 제약이 있거나 특수한 파이프라인 설계가 필요한 경우에만 선택적으로 활용하는 것이 좋습니다.