역사
스위치 구조는 C 스타일 제어 흐름 문에서 발전하여 Java 14에서 값을 생성할 수 있는 완전한 표현으로 진화했습니다. Java 17에서는 상속을 제한하기 위해 밀봉 클래스와 인터페이스가 소개되었고, 스위치를 위한 패턴 매칭이 미리보기 기능으로 등장하여 Java 21에서 표준화되었습니다. 이러한 진화는 스위치를 단순한 정수 상수 기반의 점프 테이블에서 패턴 매칭 메커니즘으로 전환시켰고, 표현으로 사용될 때 완전성을 보장해야 합니다.
문제
스위치가 표현으로 작동할 때(화살표 구문 -> 또는 yield 사용), Java의 정적 타입 시스템을 만족하기 위해 모든 가능한 입력에 대해 값을 생성해야 합니다. 전통적인 스위치 문과 달리, 이 표현은 모든 실행 경로가 값을 반환하는 절대적인 확신을 요구합니다. 밀봉 계층 구조는 허용된 모든 서브타입을 명시적으로 열거하여, 컴파일 타임에 이론적으로 검증 가능한 폐쇄된 우주를 만듭니다. 컴파일러는 이 폐쇄된 세계를 타입 패턴이나 null 케이스와 같은 열린 패턴과 조율하여 커버되지 않은 타입으로 인해 런타임 MatchException이 발생하지 않도록 해야 합니다.
해결책
컴파일러는 컴파일 단계에서 귀속 검토를 하면서 우선성 및 포괄성 분석을 수행합니다. 밀봉 클래스의 허용 조항을 정해진 유한, 닫힌 타입 집합으로 취급합니다. 스위치 내의 각 패턴에 대해, 매치된 타입을 허용된 타입의 우주에서 빼냅니다. 마지막 패턴 후에 허용된 서브타입이 남아있고, 무조건적인 default 또는 전체 타입 패턴이 없으면, 컴파일러는 오류와 함께 코드를 거부합니다. 이 분석은 패턴 우선성 규칙을 준수하며(특정 패턴이 보다 일반적인 패턴보다 앞서야 함), null 입력을 타입 패턴과 별개로 처리하기 위해 합성 기계를 생성합니다.
sealed interface Payment permits Credit, Debit, Crypto {} record Credit() implements Payment {} record Debit() implements Payment {} record Crypto() implements Payment {} // Crypto 케이스가 없으면 컴파일 타임 오류 double fee = switch (payment) { case Credit c -> 0.02; case Debit d -> 0.01; // Crypto 케이스가 없으면: "스위치 표현이 모든 가능한 값을 다루지 않음" };
문제 설명
지불 처리 마이크로서비스에서 우리는 Credit, Debit, BankTransfer, 및 Crypto를 기반으로 수수료를 계산해야 했습니다. 도메인 모델은 정확히 이 네 가지 구현을 허용하는 밀봉 인터페이스 PaymentInstrument를 사용했습니다. 한 주니어 개발자가 스위치 표현을 사용하여 수수료 계산기를 구현했지만, 우연히도 Crypto 케이스를 누락하여 암묵적으로 제로를 생성할 것이라고 가정했습니다. 실제 운영에서 암호화폐 결제가 활성화되었을 때, 이 누락으로 인해 런타임에서 MatchException이 발생하여 거래 파이프라인이 중단되었고 긴급 롤백이 필요했습니다.
고려된 다양한 솔루션
솔루션 A: 기본 케이스 폴백
서로 맞지 않는 악기를 처리하기 위해 default -> 0.0 조항을 추가할 수 있습니다. 이 접근 방식은 충돌을 방지함으로써 즉각적인 안전성을 제공합니다. 그러나 처리되지 않은 타입을 조용히 흡수하여 비즈니스 의도를 흐리게 합니다. 만약 나중에 밀봉 계층에 새로운 악기 타입이 추가된다면, 기본 조항은 그것을 수수료 계산에서 숨기게 되어, 잠재적으로 수익 유출이나 규제 위반을 초래할 수 있습니다.
솔루션 B: 열거형 기반 타입 매핑
열거형 InstrumentType으로 이동하면 상수 열거를 통한 컴파일 타임 포괄성 검사가 가능해집니다. 그러나 이는 각 지불 악기가 중복 타입 메타데이터를 노출하도록 강제하는 병행 분류를 생성합니다. 각 서브타입이 카드 번호나 블록체인 주소와 같은 유일한 데이터 필드를 보유하는 밀봉 클래스의 다형성을 희생시키며, 불필요한 데이터 비정규화를 강요합니다.
솔루션 C: 컴파일러 강제 포괄 패턴 모든 네 가지 허용된 타입에 대해 명시적 케이스로 스위치 표현을 구현하여 컴파일러의 밀봉 계층 분석을 활용합니다. 이 접근 방식은 누락된 케이스를 컴파일 오류로 간주하여 밀봉 허용이 변경될 때마다 코드베이스 업데이트를 강제합니다. 런타임의 놀라움을 제거하며 검증 과정을 빌드 단계로 이동시킵니다.
선택한 솔루션 및 결과
우리는 솔루션 C를 선택하고 비포괄적 스위치 표현에 대한 컴파일러 경고를 치명적 오류로 처리하도록 빌드 파이프라인을 구성했습니다. 이후 제품 팀이 다섯 번째 허용 서브타입인 BuyNowPayLater를 추가하자, CI/CD 파이프라인은 수수료 계산이 불완전한 열일곱 개의 위치를 즉시 플래그했습니다. 이로 인해 배포 전에 세금, 규제 및 회계 모듈 전반에 걸쳐 조정된 업데이트가 강제되어 새로운 악기가 적절한 재무 로직을 받을 수 있도록 했습니다. 컴파일 타임 보장은 조용한 기본값을 방지하고 분산 팀 간의 타입 안전성을 유지했습니다.
null 처리가 패턴 스위치에서 포괄성 검사와 어떻게 상호작용합니까?
많은 후보자들은 밀봉 클래스의 모든 서브타입을 포괄하면 포괄성 요건이 충족된다고 잘못 가정합니다. 그러나 스위치 표현은 null 선택자를 타입 패턴과 별도로 취급합니다. 별도의 case null 조항이나 전체 패턴이 필수적입니다. 명시적인 null 처리가 없으면, 컴파일러는 NullPointerException을 발생시키는 합성 null 검사를 생성하여 표현이 타입에 대해서는 기술적으로 포괄적이지만 null 값 자체에 대해서는 그렇지 않음을 의미합니다.
밀봉 계층에 대한 스위치에 기본 조항을 추가하는 것이 밀봉 타입 원칙을 잠재적으로 위반하는 이유는 무엇입니까?
후보자들은 종종 방어 코딩 습관으로 default를 추가하지만 그것이 밀봉 클래스의 폐쇄적인 세계 가정을 약화시킨다는 사실을 인식하지 못합니다. 기본 조항은 모든 타입과 일치하므로, 향후 릴리스에서 허용 목록에 추가된 타입이 포함됩니다. 이는 컴파일 타임 포괄성 검증을 런타임 등의 Catch-all로 전환하여, 처리되지 않은 새로운 타입이 의도하지 않은 로직을 조용히 실행할 수 있도록 하는 정확한 취약성을 다시 도입합니다.
밀봉 타입에 대한 스위치 표현이 현재 모듈에서 볼 수 없지만 허용되는 타입을 만날 때 어떤 일이 발생합니까? 이 시나리오는 밀봉 클래스가 패키지-프라이빗 서브타입을 다른 패키지에 허용하는 가시성 경계를 포함합니다. 컴파일러는 사용 지점에서 허용된 타입의 완전한 집합을 알 수 없기 때문에 포괄성을 검증할 수 없으며, 모든 로컬 가시 타입이 처리되더라도 컴파일 오류가 발생합니다. 이 문제를 해결하려면 기본 조항을 추가하거나 JPMS 모듈 내보내기를 조정하여 허용을 가시적으로 만드는 방법이 필요하며, 모듈 접근성과 패턴 매칭 간의 상호 작용을 강조합니다.