답변.

질문의 역사

패턴 매칭은 타입을 검사하고 데이터를 한 번에 추출할 수 있도록 해주는 기능으로, 함수형 및 스크립트 언어에서 차용된 기법입니다. 자바에서 패턴 매칭의 발전은 자바 14(미리보기 기능)에서 시작되어, 자바 16-17에서 개선되었으며, 최근 릴리스에서는 switch로 확장되고 있습니다.

문제

전통적인 타입 검사 및 형변환 방법은 다음과 같이 복잡해 보였습니다:

if (obj instanceof String) {
    String s = (String) obj;
    ...
}

여분의 변수가 생기고, 많은 템플릿 코드가 생성되며, 형변환 오류의 위험이 증가했습니다.

해결책

패턴 매칭을 사용하면 타입 검사, 새로운 변수 선언 및 그것의 사용을 하나의 표현식으로 결합할 수 있습니다:

if (obj instanceof String s) {
    System.out.println(s.length());
}

유사한 패턴이 이제 switch 구문에서도 나타나므로 코드는 더 간결해지고 오류의 가능성이 줄어듭니다.

주요 특징:

간결하고 안전한 타입 작업.
형변환 오류 수 감소.
코드 유지보수 용이 및 새로운 타입에 대한 확장성.

속임수 질문.

패턴 매칭을 사용자 정의(커스텀) 클래스에 사용할 수 있나요, 아니면 표준 타입에만 사용할 수 있나요?

모든 클래스에 사용할 수 있습니다. 패턴 매칭은 instanceof를 사용할 수 있는 모든 클래스에 대해 작동합니다.

패턴 변수는 if/switch 블록 외부에서 접근할 수 있나요?

아니요, 패턴 매칭 내에서 선언된 변수는 생성된 블록 내에서만 볼 수 있습니다(예: if 또는 switch case 내에서).

코드 예:

if (obj instanceof Integer i) {
    // i는 이 블록 내에서만 보입니다
    System.out.println(i + 10);
}
// 여기서 i는 접근할 수 없습니다

패턴 매칭을 제네릭과 함께 사용할 수 있나요?

네, 다음과 같이 사용할 수 있습니다:

Object list = List.of("a", "b");
if (list instanceof List<?> l) {
    System.out.println(l.size());
}

하지만 raw 타입으로의 작업과 파라미터화된 타입으로의 형변환은 여전히 type erasure로 인해 제한적입니다.

일반적인 오류 및 안티 패턴

패턴 매칭이 null을 자동으로 처리한다고 가정: 객체가 null이면 조건이 충족되지 않습니다 (instanceof는 null일 때 항상 false).
getClass() 메서드로 충분한 곳에서 패턴 매칭을 사용하는 것.
패턴 매칭을 너무 자주 사용하면 의도가 불분명해져서 아키텍처를 악화시킬 수 있습니다.

실생활 예시

부정적인 케이스

팀은 모든 경우에 패턴 매칭을 도입했으며, 내부 DTO, 서비스 클래스 및 다형성이 충분했던 경우조차 포함되었습니다. 코드는 instanceof에 과도하게 의존하게 되었고, 클래스 계층의 역할이 흐릿해졌습니다.

장점:

빠른 도입.
간결한 스타일.

단점:

아키텍처적 실수.
낮은 가독성.

긍정적인 케이스

프로젝트에서는 패턴 매칭을 일반 인터페이스, 보조 유틸리티 및 알 수 없는 타입의 컬렉션 처리에만 사용했습니다. OOP 아키텍처가 유지되었고, 패턴을 꼭 필요할 때만 사용했습니다.