Optional vs Non-Null Property
Optional이란?
- 자바에서는 어떤 프로퍼티에도 다 Null이 들어갈 수 있음
- 그 프로퍼티가 Null이 될 수도 있다는 것을 “명시적으로” 표현하기 위해 만들어진 래퍼 클래스
Null Safety에 대해 직접 느껴볼 수 있는 기회
- Kotlin만 했다면 NPE가 얼마나 지독한 것인지 알기 어려웠을 것
- 왜 자바에서 Optional이 탄생했을지? 왜 코틀린에서는 처음부터 non-null 프로퍼티로 지정할 수 있게 만들어놨을지?
- Kotlin: 컴파일 타임에 NPE가 발생할 여지를 최대한 줄일 수 있다
- Java: 직접 실행하기 전까진 모른다
코드 안정성을 컴퓨터에게 맡기는 것 vs 사람에게 맡기는 것
- Optional을 사용해서 Java에서도 NPE를 방지할 수 있지만…
- 이건 결국 개발자 자체 역량에 코드 안정성을 맡기는 것
- 개발자 마인드란: 사람은 믿으면 안 되고, 컴퓨터는 대체로 믿을 수 있다
- 이것이 테스트 코드를 작성하는 이유가 되기도 함
- 사람에게 일일히 수동 QA를 맡기는 것 vs 코드가 자체적으로 기능의 동작을 보장해주는 것
final by default in Kotlin
자바에서 클래스는 기본적으로 상속이 가능하다
- 기본값으로 open 되어있다
- 상속/오버라이딩을 막고 싶으면 final 키워드 사용 필요
- 일부만 열어주고 싶다면 Java 17에서 나온 sealed 키워드 사용 필요
코틀린에서 클래스, 메소드는 기본적으로 상속이 불가능하다
- 기본값이 final
- 상속/오버라이딩을 허용하고 싶으면 open 키워드 사용 필요
- 모든 클래스는 불변한 것이 코틀린의 컨셉
open class Base(p: Int)
class Derived(p: Int) : Base(p)
왜 코틀린에서는 final을 디폴트로 만들었을까?
- 무분별한 상속/오버라이딩 오용으로 인한 실수 방지
- 상속과 오버라이딩이 필수적인 상황은 그렇게 많지 않다 → 웬만하면 Composition으로 해결 가능
상속이 무분별하게 허용되면?
내가 부모 클래스를 변경했을 때 자식 클래스에게 어떤 영향을 미칠지 알기 어렵다. 자식 클래스가 어떤 식으로 부모 클래스를 사용하고 있을지 알 수 없다. 즉, 코드의 예측 가능성이 저하된다.
라이브러리 개발자처럼 불특정 다수가 사용할 코드를 작성하는 사람뿐만 아니라, 한 프로젝트에서도 여러 사람이 작업하다보면 부모 클래스를 작성했을 때 의도를 다르게 해석하여 부모 클래스를 사용하는 경우가 발생한다.
final이 기본값인 것에 대해 마냥 장점만 있는 건 아니고 의견이 나뉘는 부분
- 상속을 허용하려고 할 때마다 open 을 붙여주는 게 번거로움
- 외부 라이브러리 등 내가 수정할 수 없는 코드의 클래스를 상속하고 싶을 때, 상속할 수 없는 경우가 종종 발생
코틀린은 불변을 좋아한다!! 코틀린 공식문서로 자바랑 다른거 봐라
https://kotlinlang.org/docs/java-to-kotlin-nullability-guide.html#default-values-instead-of-null
툴스 들어가서 코틀린을 자바로 컴파일 가능
왜 자바를 선택했나요? 아직 대세는 자바이고 자료도 자바가 훨씬 많기 때문입니다. 그리고 만약 자바가 물러나는걸 대비해 코틀린도 알고 있습니다