Java에서 Kotlin으로

4장. 옵션에서 무효화 가능으로

이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: [e-mail]

토니 호어는 널 참조의 발명을 10억 달러짜리 실수라고 생각할 수도 있습니다,¹ 하지만 우리는 여전히 소프트웨어 시스템에서 사물의 부재를 표현해야 합니다. Kotlin을 사용하여 안전한 소프트웨어를 유지하면서 어떻게 null을 수용할 수 있을까요?

부재 표시

아마도 Kotlin의 가장 매력적인 기능은 유형 시스템에서 null 가능성을 표현하는 것입니다. 이것은 Java와 Kotlin의 결이 다른 또 다른 영역입니다.

Java 8 이전에는 관습, 문서, 직관에 의존하여 널이 될 수 있는 참조와 그렇지 않은 참조를 구분했습니다. 컬렉션에서 항목을 반환하는 메서드는 null 을 반환할 수 있어야 하지만 addressLine3 이 null 일 수도 있고 정보가 없을 때 빈 문자열을 사용할 수도 있다는 것을 추론할 수 있습니다.

수년에 걸쳐 저자와 동료들은 별도의 플래그를 지정하지 않는 한 Java 참조는 널이 아닌 것으로 간주하는 규칙을 정착시켰습니다. 따라서 필드 이름을 addressLine3OrNull 또는 메서드 이름을 previousAddressOrNull 으로 지정할 수 있습니다. 코드베이스 내에서 이는 충분히 잘 작동합니다(약간 장황하고 NullPointerException의 재앙을 피하려면 영원한 경계가 필요하더라도).

일부 코드베이스는 @Nullable 및 @NotNullable 어노테이션을 대신 사용하기로 선택했으며, 종종 정확성을 검사하는 도구에서 이를 지원했습니다. 2014년에 출시된 Java 8은 어노테이션에 대한 지원을 강화하여 검사 프레임워크와 같은 도구가 널 안전 이상의 것을 정적으로 검사할 수 있도록 했습니다. 하지만 더 중요한 것은 Java 8에 표준 Optional 유형도 도입했다는 점입니다.

이때( ) 많은 JVM 개발자들이 Scala를 접하게 되었고, 이들은 옵션 유형(Scala의 표준 라이브러리에서는 Option )이 없는 경우 이를 사용하고, 없는 경우 일반 참조를 사용하는 것의 장점을 알게 되었습니다. Oracle은 개발자들에게 필드 또는 매개변수 값에 Optional 을 사용하지 말라고 말함으로써 물을 흐리기도 했지만, Java 8에 도입된 많은 기능이 그렇듯이 충분히 훌륭했고, 결국 Java의 주류 사용법으로 채택되었습니다.

Java 코드의 연식에 따라 이러한 전략 중 일부 또는 전부를 사용하여 부재를 처리할 수 있습니다. Null⁠Pointer​Excep⁠tion이 거의 보이지 않는 코드베이스를 가질 수는 있지만 현실적으로 이것은 어려운 일입니다. Java는 null에 짓눌려 있고 반쪽짜리 Optional 유형으로 인해 당황스러워합니다.

이와 대조적으로 Kotlin은 null을 수용합니다. 표준 라이브러리가 아닌 유형 시스템의 일부로 옵션성을 만들면 Kotlin 코드베이스는 누락된 값을 처리하는 데 있어 신선한 통일성을 갖게 ...