begaonnuri
  • 소개
  • Book
    • 이펙티브 코틀린
      • 아이템 1. 가변성을 제한하라
      • 아이템 2. 변수의 스코프를 최소화하라
      • 아이템 3. 최대한 플랫폼 타입을 사용하지 말라
      • 아이템 4. inferred 타입으로 리턴하지 말라
      • 아이템 5. 예외를 활용해 코드에 제한을 걸어라
      • 아이템 6. 사용자 정의 오류보다는 표준 오류를 사용하라
      • 아이템 7. 결과 부족이 발생할 경우 null과 Failure를 사용하라
    • 클린아키텍처
      • 1장 설계와 아키텍처란?
      • 2장 두 가지 가치에 대한 이야기
      • 3장 패러다임 개요
      • 4장 구조적 프로그래밍
      • 5장 객체 지향 프로그래밍
      • 6장 함수형 프로그래밍
      • 7장 SRP: 단일 책임 원칙
      • 8장 OCP: 개방-폐쇄 원칙
      • 9장 LSP: 리스코프 치환 원칙
      • 10장 ISP: 인터페이스 분리 원칙
      • 11장 DIP: 의존성 역전 원칙
      • 12장 컴포넌트
      • 13장 컴포넌트 응집도
      • 14장 컴포넌트 결합
      • 25장 계층과 경계
Powered by GitBook
On this page
  1. Book
  2. 이펙티브 코틀린

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

코틀린에서 타입을 추론할 땐 오른쪽에 있는 피연산자에 맞게 타입이 추론된다.

open class Animal
class Zebra: Animal()

fun main() {
  var animal = Zebra()
  animal = Animal() // Type mismatch 에러 발생
}

animal이 바로 오른쪽에 있는 피연산자인 Zebra 타입으로 추론되기 때문에 Animal 타입으로 재할당할 경우 컴파일 에러가 발생한다.

일반적인 경우 타입을 명시해서 해결할 수 있다.

open class Animal
class Zebra: Animal()

fun main() {
  var animal: Animal = Zebra() // Animal 타입 명시로 해결
  animal = Animal()
}

하지만 라이브러리나 외부 API처럼 직접 코드를 조작할 수 없는 경우 이런 문제를 쉽게 해결할 수 없다. 따라서 리턴 타입은 외부에서 확인할 수 있게 명시적으로 지정하는 것이 좋다.

정리

  • 타입을 확실하게 지정해야 하는 경우 명시적으로 지정한다.

  • 외부 API를 만들 때는 반드시 타입을 지정한다.

Previous아이템 3. 최대한 플랫폼 타입을 사용하지 말라Next아이템 5. 예외를 활용해 코드에 제한을 걸어라

Last updated 3 years ago