일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- https go
- 돌연변이 테스팅
- InnoDB
- 자바
- go https 구현
- https 실습
- cli 만들기
- kotlin
- 오블완
- HTTPS
- AES-GCM
- Mutation testing
- Test
- Pitest
- ruby
- standard input
- Java
- resizer 구현
- resize image with go
- https 서버 구현
- JPA
- 객체지향
- https implement
- IntelliJ
- MySQL
- 직접 코드로 구현
- 코틀린
- image resizer with go
- 대칭 키 알고리즘
- standard output
- Today
- Total
Rlog
Kotlin) 변성 본문
변성 (Variance)
Generic Type 의 대체 가능성을 정의 (무공변, 반공변, 공변), 변성은 Genrice Parameter Type 간의 관계를 나타낼때 쓰이는 단어임.
무공변(invariance)
Generic 의 Parameter Type 은 각각 고유하므로 GenericType 사이의 대체 가능성은 기본적으로 성립하지 않음. 이 상태가 무공변(invariance) 상태임. 이 말을 듣고 느낀 점은, 지금 까지 Generic Parameter 에 넣는 Type 을 자꾸, 내가 생성한 Class 들의 상속관계로 가져와서 생각하다보니, 공변을 한동안 이해하기 어려웠던 건가? 이런 생각이 들었다.
class Tree<T>(val value: T)
var tree: Tree<Number> = Tree<Int>(10) // error
공변(covariance)
하지만 Kotlin 도 객체지향 언어이므로, 대체 가능성을 지원하고 있음. 따라서 Generic Parameter Type 에서 대체가능성을 지원하는 경우가 있는데 이때를 "공변(covariance)" 라고 함. Parameter Type 이 기존 Type 의 관계를 가져가려는 시도임.
class Tree<T>(val value: T)
var tree: Tree<Number> = Tree<Int>(10) // success
tree.value.toDouble()
공변이 성립되는 경우는 위의 예제에서 Type Parameter 로 쓰인 T Type 이 바깥으로 노출되는 구조일땐데, 즉 Producer 형태로 값을 노출시키는 구조에만 가능하다. 그 이유는 다른 값을 받게 될 경우에는 문제가 발생할 수도 있다. 예를 들면, 지금은 init 하는 시점에 받은 Int Value 만 사용하는데 후에 다른 Type 의 값이 들어오게 될 수도 있기 때문이다. 아래 예시를 보면 알겠지만, 그래서 코틀린에서는 이를 방지하고 있다.
var list: MutableList<Number> = mutableListOf<Int>(10) // Type mismatch: inferred type is MutableList<Int> but MutableList<Number> was expected
list.add(10.0) // 이런식으로 이상 한 값이 들어올 수 있음. 하지만 Kotlin 에서는 안됨.
println(list)
위의 예제를 보면 일반적인 Type 의 대체 가능성을 생각해본다면 가능할 것 같다. 하지만 불가능하다. 그 이유는 Invariance 하기 때문이다. Invariance 한 이유는 mutableList 는 Producer 와 Consumer 역할을 동시에 하기 때문이다.
fun main() {
var list: List<Number> = listOf<Int>(10)
println(list)
}
반면의 위의 List 를 사용한 예제는 잘 동작한다. 그 이유는 코틀린의 List Collection 은 기본적으로 immutable 하다. 따라서 Producer 의 역할만 하게된다. 그래서 공변이 성립할 수 있게 되는 것이다. 즉, Producer 역할만 하게 되는 경우에는 Covariance 하다.
out
그래서 공변의 경우에는 생산자가 외부에 T Type 을 노출하게 되는 구조이므로, out
식별자를 사용하게 된다. 그래서 아래와 같이 적게 되면, 내가 외부에 이 List 의 원소들을 Number Type 으로 노출시킬꺼야. 라고 컴파일 시점에 공표하는 것과 같다. (Intellij 를 쓴다면 out 식별자를 저기 붙여주면, List 는 이미 invariance 하니까 없애라고 나온다.)
val list: List<out Number> = listOf(10)
반공변성(contravariant) && in
반대로 파라미터 구상타입에 추상타입이 들어오는 경우를 반공변성(contravariant) 라고 함. 즉 in
은 Consumer 구조 일때 사용가능하다.
internal class Node<in T : Number> (
private val value: T,
private val next: Node<T>? = null
) {
operator fun contains(target: T): Boolean {
return if (value.toInt() == target.toInt()) true else next?.contains(target) ?: false
}
fun isPositive(target: T): Boolean {
return target.toInt().isPositive()
}
}
fun main() {
val node: Node<Int> = Node<Number>(10.0)
node.contains(8)
}
위의 예시를 보면 Int Type Node 에 Number Type Node 를 대입하고 있다. 이게 어떻게 가능한 일일까? 일단 하나하나씩 살펴보면 아래와 같은 이유를 추론할 수 있다.
contains 메소드 안에 들어왔을때,
toInt()
메소드가 실행하는데 Number Type 들은 해당메소드로 Convert 시 반드시 Int Type 으로 변한다. 따라서 Number Type 으로만 UpperBound 규약이 있다면 상관없음.contains 로직은 Number 의 method 이므로 아무런 문제가 없음.
값을 UpperBound 로 규정지어서 가능하다. 아래 예시를 한번 보면 좀 더 이해가 편할 것 이다.
internal class Node<in T : Number> (
private val value: T,
private val next: Node<T>? = null
) {
operator fun contains(target: T): Boolean {
return if (value.toInt() == target.toInt()) true else next?.contains(target) ?: false
}
fun isPositive(target: T): Boolean {
return target.toInt().isPositive() // 반드시 Int 로 Bound 를 규정짓고만 확장함수를 사용가능.
}
}
// 확장함수 추가
fun Int.isPositive(): Boolean {
return this >= 0
}
선언지점 변성
코틀린에서는 in
, out
을 이용해서 컴파일 시점에 변성에 대한 조건을 체크할 수 있다. Java 에서는 컴파일 시점에 변성 체크가 불가능하다. 따라서 아래 코드를 만나면 죽는다.
var list: MutableList<Number> = mutableListOf<Int>(10)
list.add(10.0) // dead
list.get(0)
println(list)
그래서 위와 같은 상황에서는 "무공변성(invariance)" 를 유지해야만 한다.
참고
'Kotlin' 카테고리의 다른 글
Kotlin Coroutine Exception Handling (0) | 2022.07.05 |
---|---|
Kotlin Coroutine Job (0) | 2022.07.01 |
Coroutine Builder (0) | 2022.06.27 |
Kotlin Coroutines (1) | 2022.06.19 |
코드스피츠 코틀린 3강 정리 (0) | 2022.06.18 |