안드로이드 개발자 노트
[이펙티브 코틀린] Item23. 타입 파라미터의 섀도잉을 피하라 본문
반응형
다음 코드처럼 프로퍼티와 파라미터가 같은 이름을 가질 수 있습니다.
class Forest(name: String) {
fun addTree(name: String) {
//...
}
}
이렇게 되면 지역 파라미터가 외부 스코프에 있는 프로퍼티를 가리게되며, 이를 섀도잉이라고 부릅니다.
섀도잉 현상은 클래스 타입 파라미터와 함수 타입 파라미터 사이에서도 발생합니다.
interface Tree
class Birch : Tree
class Sqruce : Tree
class Forest<T : Tree> {
fun <T : Tree> addTree(tree: T) {
//...
}
}
이렇게 코드를 작성하면, Forest와 addTree의 타입 파라미터가 독립적으로 동작합니다.
val forest = Forest<Birch>()
forest.addTree(Birch())
forest.addTree(Sqruce())
코드만 봐서는 addTree 함수의 타입 파라미터와 Forest 클래스의 타입 파라미터 둘이 독립적으로 동작한다는 것을 빠르게 알아내기 힘듭니다.
따라서 addTree가 클래스 타입 파라미터인 T를 사용하게 하는 것이 좋습니다.
class Forest<T : Tree> {
fun addTree(tree: T) {
//...
}
}
// Usage
val forest = Forest<Birch>()
forest.addTree(Birch())
forest.addTree(Sqruce()) // Error, type mismatch
독립적인 타입 파라미터를 의도한다면, 이름을 아예 다르게 다는 것이 좋습니다.
또한, 다음 코드처럼 타입 파라미터를 사용해서 다른 타입 파라미터에 제한을 줄 수도 있습니다.
class Forest<T : Tree> {
fun <ST : Tree> addTree(tree: ST) {
//...
}
}
정리
- 타입 파라미터 섀도잉을 피하라. 타입 파라미터 섀도잉이 발생한 코드는 이해하기 어려울 수 있다.
반응형
'Kotlin > 이펙티브 코틀린' 카테고리의 다른 글
[이펙티브 코틀린] Item24. 제네릭 타입과 variance 한정자를 활용하라 (0) | 2023.11.12 |
---|---|
[이펙티브 코틀린] Item22. 일반적인 알고리즘을 구현할 때 제네릭을 사용하라 (0) | 2023.11.11 |
[이펙티브 코틀린] Item21. 일반적인 프로퍼티 패턴은 프로퍼티 위임으로 만들어라 (0) | 2023.11.11 |