아이템 3 - 최대한 플랫폼 타입을 사용하지 말라

아이템 3 - 최대한 플랫폼 타입을 사용하지 말라를 정리한 내용입니다.

• 코틀린은 널 안정성(null-safety)를 지원하여 자바의 NPE를 많이 방지한다.

• 코틀린이 자바와 함께 연결되어 사용될때 NPE가 발생할 수 있다.

• 코틀린은 자바에서 @Nullable이 붙어 있으면 String?, @NotNull이면 String으로 사용하면 된다.

code1

// 자바
public class JavaTest {

    public String giveName() {
        // ...    
    }
}

- 자바에서 어노테이션이 붙어 있지 않은 경우 코틀린에서 안전하게 사용시 nullable로 가정하고 다루어야 한다.
- null이 아님이 확실하다면 코틀린에서는 not-null 단정인 !!를 붙인다.

• 자바의 제네릭 타입을 코틀린에서 다룰때 항시 nullable임을 염두해 두어야 한다.

만약 코틀린이 디폴트로 모든 타입을 nullable로 다룬다고 가정한다면,

• List<User>와 같은 컬렉션에서 리스트 및 내부 User 객체가 널이 아님을 확인해야 한다.

• 자바의 List<List<User>>은 널 확인시 더욱 복잡해진다.

• List는 map, filterNotNull 메서드를 제공하나 일반 제네릭 타입은 널 확인 자체가 복잡한 일이 된다.

code1

// 자바
public class UserRepo {

    public List<User> getUsers() {
        // ***
    }
}

code2

code3

• 코틀린은 모든 타입을 nullable로 다루지 않고 특수하게 다루는데 이를 플랫폼 타입이라고 부른다.

• 플랫폼 타입 다른 프로그래밍 언어에서 전달되어서 nullable인지를 알 수 없는 타입이다.

• 플랫폼 타입은 String! 처럼 뒤에 ! 기호를 붙여서 표시하나 이 노테이션을 직접적으로 코드에 표시하지는 않는다.

code1

// 자바
public class UserRepo {
    public User getUser() {
        //...
    }
}

code2

code3

- 플랫폼 타입은 모든 타입을 nullable로 바라봤을때의 문제를 사라지게 한다.
- 문제는 사라지지만 null이 아니라고 생각되는 것이 null일 가능성이 있으므로 여전히 위험하다.
- 플랫폼 타입을 다룰때는 항상 주의를 기울여야 한다. (명시적 어노테이션 표시, 주석... 등으로 보완)

• 자바를 코틀린과 함께 사용하고 자바 코드를 조작할 수 있다면 @Nullable, @NotNull을 사용하는게 좋다.

code1

// 자바
import org.jetbrains.annotations.NotNull

public class UserRepo {
    public @NotNull User getUser() {
        //...
    }
}

• 코틀린에서도 플랫폼 타입은 안전하지 않으므로 빨리 제거하는게 좋다.

code1

// 자바
public class JavaClass {
    public String getValue() {
        return null;
    }
}

code2

- statedType, platformType경우 모두 NPE(Null Pointer Exception)가 발생한다.
- statedType는 자바에서 값을 가져오는 위치에서 NPE가 발생하며 오류를 찾기 쉽다.
- platformType는 값을 사용할때 NPE가 발생하며 오류를 찾기가 어렵다.
- 플랫폼 타임은 많은 위험성을 가진다.