답변.

문제의 역사:

instanceof 키워드는 객체가 주어진 유형 또는 그 하위 유형에 속하는지 확인하기 위해 Java에서 등장했습니다. 이 메커니즘은 런타임에서 객체의 유형을 명확히 할 수 있게 하여 제너릭 컬렉션, 다형성 및 타입 변환 작업에 중요합니다.

문제:

객체 유형이 올바르게 정의되지 않으면 ClassCastException이나 코드 분기에서의 논리적 처리 오류가 발생할 수 있습니다. 또한, instanceof의 과도한 사용은 설계 실패의 징후일 수 있습니다.

해결책:

instanceof는 객체가 주어진 클래스의 인스턴스이거나 그 하위 클래스, 또는 인터페이스를 구현할 경우 true를 반환합니다. Java 16에서는 if 블록 내에서 타입을 자동으로 변환하는 패턴 매칭이 도입되었습니다.

코드 예시:

Object obj = "Hello!";

if (obj instanceof String) {
    String s = (String) obj; // 변환 안전
    System.out.println(s.length());
}

Java 16부터:

if (obj instanceof String s) {
    System.out.println(s.length()); // s는 자동으로 String으로 변환됨
}

주요 특징:

덫이 있는 질문들.

null instanceof SomeClass는 무엇을 반환할까요?

항상 false입니다. 연산자는 객체가 null인 경우 결과가 false임을 보장하여 NullPointerException을 방지합니다.

instanceof를 제너릭 매개변수와 함께 사용할 수 있나요, 예를 들어 if (obj instanceof List<String>)?

아니요. 타입 소거(type erasure)로 인해 런타임에서 제너릭 매개변수를 확인할 수 없습니다. 항상 raw 타입(예: List)에 대해서만 확인할 수 있습니다.

코드 예시:

List<String> list = ...;
if (list instanceof List<String>) { ... } // 컴파일 오류
if (list instanceof List) { ... } // 허용됨

instanceof의 사용이 코드 디자인에 문제를 나타낼 수 있나요?

네. 추상화나 패턴(예: 방문자 패턴) 대신 instanceof를 지속적으로 사용하는 것은 OOP 원칙, 예를 들어 개방-폐쇄 원칙 위반을 나타낼 수 있습니다.

메서드 내에 모든 가능한 하위 클래스에 대해 instanceof로 확인하는 긴 if-else 체인이 존재하고, 각 분기에서는 타입 변환과 해당 메서드 호출이 이루어집니다.

장점:

단점:

if-else 대신 방문자 패턴을 구현함: 각 하위 클래스는 필요한 행위를 호출하는 메서드를 가지고 있어, instanceof를 제거합니다.

장점:

단점: