[이펙티브 코틀린] 1장 안정성 Item 4 inferred 타입으로 리턴하지 말라

Sdoubleu·2023년 1월 5일
0

이펙코

목록 보기
4/7
post-thumbnail
  • 코틀린의 타입 추론(type inference)은 JVM 세계에서 가장 널리 알려진 특징

  • 타입 추론을 사용할 때 몇 가지 💣위험한 부분들 존재

  1. 우선 할당 때 inferred 타입은 정확하게 오른쪽에 있는 피연산자에 맞게 설정됨
  2. ⚡절대로 슈퍼클래스 또는 인터페이스로는 설정되지 않음

ex)

open class Animal
class Zebra: Animal()

fun main() {
	var animal = Zebra()
    animal = Animal() // 오류: Type mimatch
}

↪ 일반적인 경우에는 이러한 것이 문제❌

open class Animal
class Zebra: Animal()

fun main() {
	var animal: Animal = Zebra()
    animal = Animal() // 오류: Type mimatch
}

↪ 💣하지만, 직접 라이브러리/모듈을 조작할 수 없는 경우에는 이러한 문제 간단히 해결❌


다음과 같은 CarFactory 인터페이스가 있다고 가정

🛠️Interface에 대해 작성하기

interface CarFactory {
	fun produce(): Car
}
 
//다른 것을 지정하지 않았을 경우, 다음과 같이 디폴트로 생성되는 자동차가 있다고 가정
val DEFAULT_CAR: CAR = Fiat126P()
// 대부분의 공장에서 Fiat126P라는 자동차를 생산한다고 디폴트로 가정
 
/*
DEFAULT_CAR는 Car로 명시적으로 지정되어 있으므로 따로 필요 없다고 판단,
함수의 리턴 타입을 제거했다고 가정
*/

interface CarFactory {
	fun produce() = DEFAULT_CAR
}
 
/*
그런데 다른 사람 코드보다가, DEFAULT_CAR는 타입 추론에 의해 
자동으로 타입이 지정될 것이므로, Car를 명시적으로 지정하지 않아도 된다고 생각,
다음과 같이 코드를 변경 
*/

val DEFAULT_CAR = Fiat126P()
  • 이제 문제 발생..

  • CarFactory에서는 이제 Fiat126P 이외의 자동차를 생산 불가

  • 리턴 타입은 API를 잘 모르는 사람에게 전달해 줄 수 있는 중요한 정보
    따라서 리턴 타입은 외부에서 확인할 수 있게 명시적으로 지정해주는 것이 좋음👍


⭐정리

타입을 확실하게 지정해야 하는 경우에는 명시적으로 타입을 지정해야 한다는 원칙만 갖고 있으면 됨
이는 굉장히 중요한 정보이므로, 숨기지 않는 것이 좋음
또한, 안전을 위해서 외부 API를 만들 때는 반드시 타입을 지정하고,
지정한 타입을 특별한 이유와 확실한 확인 없이 제거❌

profile
개발자희망자

0개의 댓글