본문 바로가기
공부/이펙티브코틀린

아이템 4 - inferred 타입으로 리턴하지 말라

by 띵커베르 2024. 3. 31.
728x90
  • 타입 추론은 코틀린의 특징 중 하나
  • 자바도 자바10부터는 코틀린을 따라 타입 추론을 도입함(물론 코틀린과 비교하면 몇가지 제약이 존재함)
    • c# 은 3.0 부터 도입함 var 타입..2007년..
  • 타입 추론을 사용할 때는 몇 가지 위험한 부분들이 있다
    • 할당 때 inferred 타입은 정확하게 오른쪽에 있는 피연산자에 맞게 설정된다
    • 절대로 슈퍼클랫 또는 인터페이스로는 설정되지 않습니다.
      • 코틀린의 타입 추론 과정에서 변수에 할당되는 구체적인 값의 타입을 기반으로 타입이 결졍되며, 이 과정에서 추상 타입(슈퍼클래스 또는 인처페이스) 은 타입으로 추론되지 않는 것을 의미. 즉 타입 추론은 가장 추제적인 타입을 선택
class Item4Test {

    @Test
    fun missMatchTest() {
        var animal = Zebra()
//    animal = Animal() //오류: Type missmatch
    }

// 타입을 명시적으로 지정해서 이러한 문제를 해결할 수 있다.
    @Test
    fun inferredTypeTest() {
        var animal: Animal = Zebra()
        animal = Animal()
    }

}

open class Animal
class Zebra:Animal()

 

 


정리

  • 타입을 확실하게 지정해야 하는 경우에는 명시적으로 타입을 지정해야 한다는 원칙을 갖고 있으면 된다.
    • 외부 API 를 만들 때는 반드시 타입을 지정하고, 이렇게 지정한 타입을 특별한 이유와 확실한 확인 없이는 제거하지 말자.
  • inferred 타입은 프로젝트가 진전될 때, 제한이 너무 많아지거나 예측하지 못한 결과를 낼 수 있다는 것을 기억하세요.

 

개인생각

  • 모든것을 타입을 명시적으로 선언해야하는 것은 아닌듯 하다.
    • 예를들어 로컬변수 라던지 컬렉션 생성같은 간단한 것들은 타입추론이 더 나은듯 하다.
    • val name = "injin Jeong" // String 추론
    • val numbers = listOf(1, 2, 3) -> // List<Int> 추론
  • 어떠한값이 return 되는지 함수를 보는거보다 명시적으로 적어주는게 더 낫지않을까 생각 함.
728x90

댓글