TIL

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

코틀린의 null-safety는 코틀린의 주요 기능 중 하나다.
하지만 자바, C 등 프로그래밍 언어와 코틀린을 연결해서 사요할 땐 예외가 발생할 수 있다.
자바에서 리턴 타입에 @Nullable 어노테이션을 표시해서 이를 코틀린에선 nullable 타입으로 다루면 되긴 하지만 어노테이션이 없는 경우가 문제다.

public class JavaTest {
	// @Nullable
	public String giveName() {
	 // ...
	}
}

자바에선 모든 것이 null일 수 있기에 최대한 안전하게 접근한다면 모두 nullable로 다루어야 한다.
코틀린은 자바 등 다른 프로그래밍 언어에서 넘어온 타입들을 특수하게 다루는데 이러한 타입을 플랫폼 타입(platform type)이라 부른다.
- 플랫폼타입은 String!처럼 타입 뒤에 ! 기호를 붙여 포기하는데 물론 이러한 노테이션이 코드에 나타나지는 않는다.
- 대신 아래 코드의 형태로 이를 선택적으로 사용할 수 있다.

val repo = UserRepo() // null을 뱉을 수 있는 자바 객체

val user1 = repo.user // User! (플랫폼 타입)
val user2: User = repo.user // User 타입
val user3: User? = repo.user // User? 타입

문제는 여전히 null이 아니라고 생각되는 것이 null일 가능성이 있기에 플랫폼 타입을 사용할 땐 항상 주의를 기울여야 한다.
- 자바를 코틀린과 함께 사용할 때 가능한 @Nullable과 @NotNull 어노테이션을 붙여야 한다.
플랫폼 타입은 그럼에도 안전하지 않으므로 최대한 빨리 제거하는 것이 좋다.
- 아래 statedType과 platformType 예제 코드를 보자.
- statedType에선 값을 꺼낼 때 npe가 발생하지만 platformType에선 값을 사용할 때 npe가 발생한다.
- 플랫폼 타입에선 이처럼 값이 활용될 때 npe가 발생하기에 (상황에 따라 발생하지 않을 수도 있다) 오류를 찾는 데 오랜 시간이 걸리게 될 것이다.

fun statedType() {
	val value: String = JavaClass().value // NPE
	println(value.length)
}

fun platformType() {
	val value = JavaClass().value
	println(value.length) // NPE
}

추가로 인터페이스에서 플랫폼 타입을 사용하면 메섣의 inferred 타입(추론된 타입)이 플랫폼 타입이 된다.
- 누구나 nullable 여부를 지정할 수 있게 된다.
- nullable을 리턴하는게 의도였지만 클라이언트 코드에서 null이 아니라고 받아들인다면 문제가 된다.

interface UserRepo {
	fun getUserName() = JavaClass().value
}

class RepoImp: UserRepo {
	override fun getUserName(): String? {
		return null
	}
}

fun main() {
	val repo: UserRepo = RepoUmpl()
	val text: String = repo.getUserName() // 런타임에 NPE
	print("${text.length}")
}

정리

다른 언어에서 와서 nullable 여부를 알 수 없는 타입을 플랫폼 타입이라 부른다.
플랫폼 타입은 해당 부분 뿐 아니라 다른 곳까지 영향을 줄 수 있는 위험한 코드다.
최대한 빨리 플랫폼 타입을 제거하는 것이 좋다.
연결되어 있는 자바 생성자, 메서드, 필드에 null 관련 어노테이션을 활용하는 것도 좋다.
- 이는 자바/코틀린 개발자 모두에게 유용한 정보다.