Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
Tags
- Kotiln
- react
- Flutter
- RxKotiln
- RxJava
- Dev6
- 잡담
- Kotlin
- 코틀린
- 안드로이드
- 안드로이드 다이얼로그
- 반응형 프로그래밍
- MVVM
- 이펙티브 코틀린
- Java
- Swift 문법
- 안드로이드 클린아키텍쳐
- 개발자
- 이펙티브코틀린
- 프로그래머스
- android
- Firebase
- 알고리즘
- Go언어
- 코딩테스트
- 안드로이드 개발자
- 안드로이드 컴포즈
- 코루틴
- android compose
- Rxjava 안드로이드
Archives
- Today
- Total
최데브는 오늘도 프로그래밍을 한다.
[이펙티브 코틀린] 4. inferred 타입으로 리턴하지 말라 본문
코틀린은 타입추론(type inference) 를 제공한다. 자바 10부터는 코틀린처럼 타입추론을 제공하지만 코틀린에 비해서는 제약이 많다.
아무튼 타입 추론을 사용할때 주의할 점들이 있는데 할당 할때 inferred 타입은 정확하게 오른쪽에 있는 피연산자에 맞게 설정된다는 것을 기억해야 한다.
일반적으로는 아래와 같이
open class Drink
class Water: Drink()
fun main() {
var drink = Water()
drink = Drink() // 타입에러
}
하지만 이건
open class Drink
class Water: Drink()
fun main() {
var drink : Drink = Water() // 타입 명시
drink = Drink()
}
타입 명시를 해주면 금방 해결 할 수 있다.
하지만 우리가 조작하지 못하는 외부 모듈의 경우는 문제가 생길 수 있다
그리고 이런 경우 inferred 타입을 노출하면 위험한 일이 발생할 수 있다.
여기 CarFactory 인터페이스가 있다.
interface CarFactory {
fun produce(): Car
}
그리고 다른 걸 지정하지 않았으면 아래처럼 디폴트로 생성되는 자동차가 있다고 친다.
var DEFAULT_CAR: Car = Fiat126P()
다른 개발자가 와서 봤을때 DEFAULT_CAR는 Car로 명시적으로 지정돼 있어 따로 필요없다고 판단해서 함수의 리턴 타입을 제거한다면?
var DEFAULT_CAR = Fiat126P()
이제 CarFactory에선 Fiat126P 이외의 차를 생산하지 못하는 문제가 발생한다.
리턴 타입은 API를 잘 모르는 사람에게 전달할 수 있는 중요 정보다. 따라서 리턴 타입은 외부에서 확인할 수 있게 명시적으로 지정하는 게 좋다.
inferred 타입은 프로젝트가 커지고 참여인원이 많아지면 예측하지 못한 결과를 낼 수 있다.
반응형
'Effective Kotiln' 카테고리의 다른 글
[이펙티브 코틀린] 7. 결과 부족이 발생할 경우 null과 Failure를 사용하라 (0) | 2023.03.01 |
---|---|
[이펙티브 코틀린] 5. 예외를 활용해 코드에 제한을 걸어라 (0) | 2023.01.18 |
[이펙티브 코틀린] 3. 최대한 플랫폼 타입을 사용하지 마라 (0) | 2023.01.13 |
[이펙티브 코틀린] 2. 변수의 스코프를 최소화하라. (2) | 2023.01.13 |
[이펙티브 코틀린] 1. 가변성을 제한하라 (0) | 2023.01.08 |
Comments