Kotlin in action(6)

Nullable

코틀린은 nullable한 타입을 지정해서 컴파일 때 NPE를 예방할 수 있다. 런타임에서 발생하는 NPE를 컴파일 시점으로 검사시점을 옮겨서 처리하는 방식이다. 타입에 ?를 붙여서 사용한다.

val x: String? = null

 

자바의 경우 null이 될수있는 값은 Optional 타입 등 특별한 래퍼 타입으로 감싸야하는데, 코틀린은 그냥 non-null이나 nuallble이나 같은 타입으로 하기 때문에 nullable 타입을 실행할 때 부가비용이 들지 않는다.

?. - safe call

수신객체가 null이면 null을 리턴하고, null이 아니면 의도한 메서드를 호출한다.

s?.toUpperCase()
if(s!=null) s.toUpperCase else null
val input = a?.b?.c

 

위 두 줄은 같은 코드다. 마지막 줄 처럼 연쇄해서 호출하는 것도 가능하다. c까지 가기전에 null이 반환되면 input에는 null이 들어간다.

?: - elvis, null coalescing

엘비스 연산자는 null의 경우 처리할 식을 좀 더 간결하게 표현하도록 도와준다.

val address = person.company?.address ?: throw IllegalArgumentException("No address")

 

?: 앞의 식이 null이면 뒤의 식을 연산한다. 함수의 전제 조건을 검사하는 경우 유용하다.

as? - safe cast

캐스트연산자인 as를 null safe하게 쓰는 방법이다. 대상 타입으로 변환할 수 없으면 null을 반환하는 연산자다.

!! - not-null assertion

null이 아님을 단언하는 키워드로, !!로 지정한 곳에서는 NPE가 발생할 위험이 있다. null검사가 필요없는 확실한 곳에서 사용하면 되는데, 연쇄해서 사용할 경우 어디에서 발생한 NPE인지 모른다는 점이 문제다.

person.company!!.address!!.country

 

해당 라인에서 NPE가 발생한건 stack trace가 알려주지만, 어느 프로퍼티에서 NPE가 발생했는지는 알려주지 않는다.

let

let함수는 자신의 수신객체를 인자로 전달받은 람다에게 넘긴다.

이제 여기서 ?.let{ } 과 .let의 차이가 생긴다.

email?.let { sendEmailTo(it) }
email.let { sendEmailTo(it) }

 

let이 safe한게 아니고 let을 safe하게 호출했을때 람다에서는 타입이 확실하게 null이 아닌 것을 알 수 있다. safe하게 let을 호출하면 수신객체가 null이 아니면 람다에 인자를 넣는다.

두번째 줄의 코드는 email이 String?과 같은 nullable 타입이면, 람다의 인자로 String?이 추론된다는 것을 주의하자.

lateinit var

프로퍼티를 val로 선언하면 선언과 동시에 초기화 해야되고 final로 컴파일 되며, 생성자 안에서 반드시 초기화 해야하지만, 나중에 초기화하는 프로퍼티는 var로 선언해서 사용한다.

private lateinit var myService: MyService

 

초기화 전에 이 프로퍼티에 접근하면 lateinit property has not been initialized 예외가 발생한다.

널이 될 수 있는 타입 확장

타입에 대한 확장함수를 정의하는 건데, 이 확장함수는 null이 아니어야 호출할 수 있는 확장함수/프로퍼티가 아니라, null이 될 수 있는 타입을 받아서 null을 명시적으로 처리하는 방법이다.

fun verifyUserInput(input: String?) {
    if (input.isNullOrBlank()) {
        println("TODO")
    }
}

 

타입 파라미터의 nullable

이건 제네릭에서 다시 나올 부분이라 간단하게 하고 넘어간다.

fun <T> printHashCode(t: T) {
    println(t?.hashCode())
}
fun <T: Any> printHashCode(t: T) {
    println(t.hashCode())
}

 

T는 타입 파라미터로, 모든 타입 파라미터는 기본적으로 null이 될수있는데, 이 T를 타입이름으로 사용하면 이름 끝에 ?가 없어도 nullable하다. 따라서 타입상한을 지정해둬야 null이 될 수 없다.

그렇다면 자바와 호환은?

코틀린은 자바에서 @Nullable, @NotNull 애노테이션을 읽어서 처리하는데, 이게 안붙는 경우는 플랫폼 타입이라고 부른다. 플랫폼 타입은 코틀린이 null관련 정보를 알 수 없는 타입을 말하는데, nullable로 해도되고 아니어도 되니 책임은 프로그래머가 지는 타입이다.

fun yellAtSafe(person: Person) {
    println((person.name ?: "Anyone").toUpperCase() + "!!!")
}

 

Person은 자바 타입이고, kotlin에서 엘비스 연산자로 nullable할 수 있는 부분을 처리했다. 플랫폼 타입의 경우 ?가 없어도 null 이 들어갈 수 있음을 인지해야한다. 플랫폼 타입이 도입된 이유는 모든 값에 null을 검사하는 것은 비효율적이라고 판단해서, null여부를 프로그래머가 처리하도록 설계했다고 한다.

ERROR: Type mismatch: inferred type is String! but Int was expected

 

플랫폼 타입에서 발생한 에러는 ! 가 붙는다. nullable 정보다 없다는 뜻이다.

원시 타입

자바와 달리, 코틀린은 원시타입과 래퍼타입을 구분하지 않는다. 래퍼타입은 객체의 주소값이 들어가는데, 자바 컬렉션이 그 대표적인 예다. 코틀린의 nullable하지않은 원시타입은 그대로 자바의 원시타입으로 취급되어 컴파일되지만, nullable이 붙은 코틀린의 타입은 자바에서 래퍼타입으로 컴파일된다.

또한 JVM은 제네릭을 구현할 때 원시타입을 타입인자로 허용하지않기 때문에 제네릭 클래스를 만들때는 코틀린 역시 박스타입을 사용해야한다.(listOf()와 같은)

코틀린은 숫자 변환이 자동으로 되지않기 때문에 (심지어 Int-> double로 옮기는 것도) 항상 변환함수를 이용해 처리해야한다.

val x = 1
println(x.toLong() in listOf(1L, 2L, 3L))

 

int를 long과 비교할 수 있을 것 같지만 그렇게 되지않는다. 변환함수가 필요없을 때는 숫자 리터럴을 사용할 경우다.

최상위 타입: Any, Any?

코틀린에서는 Any타입이 모든 null이 안되는 타입의 조상타입이고 Any?는 nullable의 조상타입이다. 자바의 Object에 대응하는데, Object타입을 코틀린으로 가져오면 Object!로 플랫폼 타입으로 해석된다.

모든 코틀린 클래스에 들어있는 toString, equals, hashCode 메서드가 Any에서 가져온 것이지만, Object에 있는 메서드를 Any가 사용하려면 타입 캐스트가 필요하다.

Unit: void, 그리고 Nothing

Unit으로 선언된 함수는 반환 값이 없다. 메서드를 작성할 때 생략하도 되는데, void와 다른점은 void가 타입인자로 쓸 수 없는반면에 Unit은 가능하다는 점이다.

Unit 타입의 함수는 반환 값이 단 하나며, Unit값을 묵시적으로 반환하기 때문에 return 을 명시하지않아도 된다.

Nothing 타입은 아무 값도 포함하지않는다. 함수의 반환 타입이나 반환할 파라미터의 타입으로 사용할 수 있는데, 무한루프를 종료 시킨다던가 하는 정상종료 되지않는 작업에 사용하기 유용하다.

fun fail(message: String): Nothing {
    throw IllegalStateException(message)
}

 

이런 식으로 정의해서 사용할 수 있다. Unit과 Nothing 타입을 구분해야한다.

컬렉션

컬렉션으로 들어가면 고려할 게 더 많아진다.

val ll : List<Int?>
val ll : List<Int>?
val ll : List<Int?>?

 

첫번째는 컬렉션은 null이 아니지만 원소가 nullable이고, 두번째는 컬렉션 자체가 nullable하지만 들어갈 수 있는 값은 not-null이다. 모두 nullable한게 마지막 줄이다.

mutable : 변경 가능한

MutableCollection은 기존 Collection에 add, remove, clear 메서드를 추가해 만든 인터페이스다. 되도록이면 읽기전용으로 사용하는 게 좋은 방법이다.

코틀린은 자바의 모든 컬렉션 인터페이스 마다 Mutable키워드를 붙인 인터페이스를 추가로 제공하는데(Map도 제공), 이 인터페이스는 mutableListOf(), mutableSetOf() 와 같은 함수를 호출 할 때 사용된다.

책이 나온 당시에는 Mutable만 있었고, 지금도 kotlin.collections라이브러리를 열어보니 똑같다. 문제는 자바가 읽기전용/ 변경가능 컬렉션을 구분하지 않기 때문에 코틀린에서 Collection으로 선언되어 읽기전용으로 선언된 객체라도 자바에서는 변경할 수 있다.

// java class
public class CollectionUtils {
    public static List<String> uppercaseAll(List<String> items) {
        for (int i = 0; i < items.size(); i++) {
            items.set(i, items.get(i).toUpperCase());
        }
        return items;
    }
}
// kotlin
fun printInUppercase(list: List<String>) {
    println(CollectionUtils.uppercaseAll(list)) // java 메서드 사용중
    println(list.first())
}

 

여기서 Collection, MutableCollection을 보면서 생각나는 키워드, 플랫폼 타입이 있다.

• 컬렉션의 null 가능성
• 컬렉션 원소의 null 가능성
• 변경가능성

이 세가지를 고려해서 결정하면 되는데, 변경 가능성이 미치는 영향이 제일 크다.

배열

코틀린 배열은 타입파라미터를 받는 클래스다. arrayOf(), arrayOfNulls()로 넘기거나, Array<T>() 로 만들 수 있다. Array로 만드는 경우는 각 원소가 null이 아닌 배열로 만들어야 할 경우에 사용한다.

val letters = Array<String>(26) { i -> ('a' + i).toString() }
println(letters.joinToString(""))

 

알파벳소문자를 배열로 만드는 코드다.

가변인자를 받는 함수를 호출 할 때 배열을 자주 만드는데 이때 넘기는 배열이 타입추론이 안된 상태기 때문에, 이때 데이터가 이미 컬렉션에 들어있다면 toTypedArray()를 써서 넣으면 된다. vararg에 넣기 때문에 스프레드 연산자도 같이 써줘야한다.

val strings = listOf("a", "b", "c")
println("%s/%s/%s".format(*strings.toTypedArray()))

 

원시 타입별로 배열이 존재하는데, 컴파일 때 int[], byte[] 로 원시타입 배열로 컴파일된다. 람다로 이런 배열을 사용하는 법도 있다.

val squares = IntArray(5) { i -> (i+1) * (i+1) }

 

추가로 코틀린은 컬렉션에 사용할 수 있는 모든 확장함수를 배열에도 제공한다.

public inline fun <T> kotlin.Array<out T>.forEachIndexed(action: (kotlin.Int, T) -> kotlin.Unit): kotlin.Unit {}

 

이런식으로 다 정의되어 있어서 잘 작동하는 것을 볼 수 있다.

"댓글, 공감 버튼 한 번씩 누르고 가주시면 큰 힘이 됩니다"