책에서는 타입추론(type interference)으로 리턴하지 말라합니다.
잠시 타입추론을 설명하자면..
val name = "John" // 변수 name은 String 타입으로 추론됨
val age = 25 // 변수 age는 Int 타입으로 추론됨
fun calculateSum(a: Int, b: Int): Int {
return a + b
}
val result = calculateSum(5, 10) // 변수 result는 Int 타입으로 추론됨
위 코드처럼 코틀린은 타입을 지정하지 않아도 위의 코드처럼 처음 초기화될 때의 값에 따라 타입추론 하여 해당 변수나 상수의 타입을 지정해 줍니다. 이러다 보니 해당값에 착가하고 다른 것을 넣게 될 경우 당연히 Type mismatch오류가 발생합니다.
본론으로 돌아가서 타입추론을 이용하여 리턴하지 말라고 하는 것에는 이유가 있습니다.
예를 들어 자동차 공장이 있다고 생각해 봅시다.
interface CarFactory {
fun produce(): Car
}
이 자동차 공장에서는 모든 자동차를 생산할 수 있습니다.
val DEFAULT_CAR: Car = Fiat126P()
interface CarFactory {
fun produce() = DEFAULT_CAR
}
그런데 한직원이 출고가 되는 차가 Fiat126P밖에 없다 보니 DEFAULT_CAR를 Fiat126P로 지정하였습니다.
이 코드에서는 그래도 DEFAULT_CAR가 Car 자료형을 쓰기 때문에 다른 차도 만들 수 있습니다.
val DEFAULT_CAR = Fiat126()
그런데 여기서 또 한직원이 DEFAULT_CAR는 Car로 타입추론에 의해 자동으로 타입이 지정될 것이니 Car를 명시적으로 지정하지 않아도 된다고 생각하고 위와 같이 변경하였습니다. 이경우 자동차공장은 Fiat126P공장으로 바꾸어버립니다.
이것은 작은 프로젝트의 입장으로 보았을 때는 값만 바꾸면 되는 것이 아닌가라고 생각할 수 있습니다. 그렇지만 Api의 입장에서 보았을 때 이것은 큰 문제가 됩니다. 위처럼 다른 사람들이 모든 자동차를 만들 수 있을 것이라 생각하였지만 한 종류의 자동차밖에 만들지 못한다면 이것은 필요 없는 Api가 될 것입니다.
이처럼 타입추론으로 리턴을 할 경우 예측하지 못한 결과를 발생시킬 수도 있습니다. 그렇기 때문에 책에서는 타입추론보다는 명시적으로 타입을 지정해 주라고 말하고있습니다.
'코틀린 > Effective Kotlin' 카테고리의 다른 글
[Effective Kotlin] 6. 안정성 - 사용자 정의 오류보다는 표준 오류를 사용 하라 (0) | 2023.07.21 |
---|---|
[Effective Kotlin] 5. 안정성 - 예외를 활용해 코드에 제한을 걸어라 (0) | 2023.07.19 |
[Effective Kotlin] 3. 안정성 - 최대한 플랫폼 타입을 사용하지 말라 (0) | 2023.07.14 |
[Effective Kotlin] 2. 안정성 - 변수의 스코프를 최소화 하라 (0) | 2023.07.11 |
[Effective Kotlin] 1. 안전성 - 가변성을 제한하라 (0) | 2023.06.28 |