로그인이 구현된 fragment에서 가입되지않은 사용자가 로그인 시도를 할 때, 카카오 로그인에서 반환 받은 access token을 회원가입 페이지로 넘겨야했는데, 이때 서로 다른 Fragment로 작성되어 있는데다 viewmodel도 공유하고 있지않아서 골치가 아팠다. datastore를 이용해 access token을 저장하는 건 미리 짜 두었지만, 간단하게 프래그먼트끼리 값을 넘기는 방법이 없을까 고민하던 중, 프로젝트 팀장형이 safe args라는 키워드를 알려주셨다.

safe args는 android jetpack navigation component에 속한 플러그인 중 하나이고, navigation의 탐색 그래프 소스코드의 action에 값을 담아서 넘기는 아주 획기적인 기능을 갖고있다.

대상 사이에서 데이터를 탐색하고 전달할 때 유형 안정성을 제공하는 그래프 플러그인입니다. 인수를 통해 복잡한 데이터 구조를 전달하는 것은 안티패턴으로 간주됩니다. 각 대상은 항목 ID와 같이 필요한 최소 정보를 기반으로 UI 데이터 로드를 담당해야 합니다. 이를 통해 프로세스 재생성이 간소화되고 잠재적 데이터 불일치가 방지됩니다.

내 경우에는 string으로 된 값을 넘기면 되는 상황이라 사용하기 적합한 조건이다. 이제 사용방법을 알아보자

Safe Args 사용법

gradle 플러그인이다 보니, gradle을 사용하지 않는 경우에는 사용할 수 없는 방법이고, 그 때는 bundle을 이용해 값을 넘겨야한다.

최상위 gradle 파일(프로젝트 수준)에 classpath 설정을 추가한다.

buildscript {
    repositories {
        google()
    }
    dependencies {
        val nav_version = "2.5.3"
        classpath("androidx.navigation:navigation-safe-args-gradle-plugin:$nav_version")
    }
}

nav_version은 계속 업데이트 될 것이므로 version catalog나 따로 buildSrc 모듈을 만들어서 관리하는 것이 유지 보수에 좋다.

사용할 app / presentation 모듈에 아래 dependency를 추가해준다.

plugins {
    id("androidx.navigation.safeargs.kotlin")
}

AndroidX 패키지이기 때문에 gradle.properties파일에 android.useAndroidX=true가 있어야한다. 최근 생성한 프로젝트라면 이미 들어가 있을 것이지만 예전에 생성한 프로젝트라면 없을 수도 있다.

이제 코드로 돌아가면, 송신(발신)대상 프래그먼트에서 프래그먼트 이름 + Directions가 생성된다. 이제 값을 넘길 준비를 하겠다. 먼저 값을 담아서 넘길 action에 인수를 설정한다.

<action
    android:id="@+id/action_loginFragment_to_signupFragment"
    app:destination="@id/signupFragment">
    <argument
        android:name="acToken"
        app:argType="string"/>
</action>

이 action은 발신대상에서 사용하는 action이다. 수신대상도 argument를 설정해줘야하는데, 수신대상은 fragment에서 값을 받기 때문에 argument의 위치가 action이 아닌 fragment이다.

<fragment
    android:id="@+id/signupFragment"
    android:name="com.shypolarbear.presentation.ui.join.JoinFragment"
    android:label="SignupFragment"
    tools:layout="@layout/fragment_signup">
    <argument
        android:name="acToken"
        app:argType="string"/>
</fragment>

이게 수신대상의 설정이다. 이렇게 하면 프래그먼트이름 + Args코드가 생성되어 접근할 수 있다.

코드로 돌아가서, action을 argument값을 넣어서 재정의한다.

sendTokenToJoin = LoginFragmentDirections.actionLoginFragmentToSignupFragment(token.accessToken)

Directions에 메서드로 action id가 잡히고, 인수에 사용할 값을 넣으면 된다. 내 코드에서 sendTokenToJoin은 NavDirection Type으로, 따로 navigate하는 코드가 있기때문에 거기서 사용하기 위해lateinit var 선언해뒀다.

수신쪽에서는 더 간단하다. ktx계열 dependency를 사용중이라면(아마 플러그인을 사용중이라면 android-ktx를 쓰고 있을 확률이 높다.) by navArgs()를 이용해 값을 받아올 인스턴스를 생성한다.

private val args: JoinFragmentArgs by navArgs()
val acToken = args.acToken

수신대상의 코드다. 탐색 그래프 ui에서 사용하는 방법도 있지만 나는 코드로 작업하는 게 편해서 이렇게 진행했다.

Safe Args 사용이점

공식문서를 보면 유형 안전성이라는 단어가 나온다. 이게 번역이 어색해서 그런건데 Type Safety가 원문에 적혀있는 단어다.

safe args를 사용하면 탐색 그래프 인자에 대한 정보를 컴파일러가 확인하기 때문 컴파일 시점에 에러를 발견 할 수 있어서 런타임 에러를 방지할 수 있다. 

(10/11 추가) Safe Args를 쓰면서 DataClass를 넘기는 법

원시타입만 넘기는 게 아니라 DataClass로 넘기고 싶다면 Parcelable로 선언하는 과정이 필요하다.

@Parcelize
data class StoreDataArgs(
    val storeId: Int,
    val storeName: String,
    val imageUrl: String
): Parcelable

Parcelable로 선언해줘서 직렬화/역직렬화 과정에도 사용할 수 있게 data class를 작성한다음

<action
    android:id="@+id/action_navigation_map_to_navigation_detail"
    app:destination="@id/navigation_detail">
    <argument
        android:name="storeInfo"
        app:argType="com.suchelin.android.util.parcelable.StoreDataArgs"/>
</action>

argType에 data class 위치를 넣으면 된다. 수동으로 하면 헷갈릴수도 있으니 이때는 도구를 쓰는 것을 추천한다.

Attributes에 add arguments를 누르면 이렇게 custom parcelable를 지정할 수 있고 IDE가 찾아준다.

참조:

https://developer.android.com/guide/navigation/navigation-pass-data?hl=ko

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

DataStore는 코루틴과 flow를 사용하는 SharedPreferences의 개선판이라고 할 수 있다. SharedPreferences를 사용할 때는 보통 설정값과 같은 단순 데이터 셋인 key-value로 묶이는 값들을 저장하는데, primitive type만 저장할 수 있다는 단점과, String으로 만든 JSON을 저장한다고 쳐도 불시에 발생하는 런타임에러를 피할 수 없었다.

또한 생성되는 파일이 XML파일이고 실제 파일작업을 하기 때문에 UI 쓰레드에서 돌려버리면 ANR이 발생하거나 런타임에러가 발생할 가능성이 농후하다. 비동기 기능도 유연하지않다. DB수준의 데이터를 저장해야 한다면 당연히 Room을 사용해야한다.

 

DataStore를 사용하게 된 계기는 서버에서 받아오는 access token을 저장해놔야 api 요청할 때 헤더에 토큰을 넣어서 요청하는데, SharedPreferences는 파일이 남아있어 안전하지 않아 DataStore를 선택했다.

 

이 글에서 SharedPreference -> DataStore 마이그레이션은 다루지 않는다.

DataStore

DataStore는 Preferences DataStore와 Proto DataStore로 나뉜다.

전자는 기존의 SharedPreferences와 거의 동일한 기능, 사용법을 갖고, 후자는 커스텀 데이터타입을 Protocol Buffer를 통해 저장한다. 커스텀 데이터 타입을 사용하기 때문에 Type-Safety를 보장하기 위한 스키마를 미리 지정해야된다는 귀찮음이 있긴하다.

설정법과 같은 건 공식문서를 따라가면 알 수 있는 부분이기 때문에 따로 다루진 않겠다. 또한 이번 프로젝트에서는 Preferences DataStore가 사용됐기 때문에 이걸 다루겠다.

Preferences DataStore

DataStore 클래스와 Preferences클래스를 사용하여 구현한다. Preferences클래스는 Map형식으로 DataStore를 사용하기 위한 타입이다.

싱글톤으로 인스턴스 만들기

val Context.dataStore: DataStore<Preferences> by preferencesDataStore(name = "preferences name")

 

이 과정이 제일 중요하다. 최상위 프로퍼티로 data store인스턴스를 호출해서 싱글톤으로 만드는 작업인데, 싱글톤으로 인스턴스를 만들지 않는다면 아래와 같은 에러메시지를 볼 수 있다.

You should either maintain your DataStore as a singleton or confirm that there is no two DataStore’s active on the same file (by confirming that the scope is cancelled)

동일한 이름을 갖는 datastore인스턴스가 중복으로 생성되어 버린 대참사다.

읽고 쓰기(멀티모듈에서)

쓸 때는 코루틴에서, 읽을 때는 flow로 작동한다. 여기서는 샘플코드 말고 실제로 작업했던 코드를 가져와봤다.

멀티모듈을 사용 중이고 data layer에 작성된 코드다. 전체 코드 먼저 올려놓겠다. 리프레시 토큰, 토큰 재발급 부분도 있지만 편의를 위해서 Access Token부분만 가져왔다.

@Singleton
val Context.tokenDataStore by preferencesDataStore("tokens")

class TokenRepoImpl @Inject constructor(
    private val api: TokenApi,
    @ApplicationContext private val context: Context
): TokenRepo {

    private object PreferenceKeys {
        val ACCESS_TOKEN = stringPreferencesKey("access_token")
    }

    override suspend fun getAccessToken(): String {
        val userAccessToken: Flow<String?> = context.tokenDataStore.data.map {
            it[ACCESS_TOKEN]
        }
        return userAccessToken.first().toString()
    }
    override suspend fun setAccessToken(accessToken: String) {
        context.tokenDataStore.edit {prefs ->
            prefs[ACCESS_TOKEN] = accessToken
        }
    }
}

 

최상위 프로퍼티로 인스턴스를 생성해 싱글톤으로 만들어준다.

@Singleton
val Context.tokenDataStore by preferencesDataStore("tokens")

 

여기서 preferencesDataStore의 파라미터로 들어가는 String값은 일종의 디렉터리다. 여기서는 tokens인데, 앞으로 tokenDataStore로 접근하는 key-value 쌍은 모두 tokens 밑에 생성된다.

private object PreferenceKeys {
        val ACCESS_TOKEN = stringPreferencesKey("access_token")
    }

 

key-value쌍으로 들어갈 값의 Key를 담는 곳이다. 그냥 “access_token”이라고 직접 값을 넣어도 되지만 가독성을 높이기 위해 object로 묶어서 만들어 줬다.

지원되는 PreferencesKey 유형은 여기서 확인할 수 있다.

override suspend fun setAccessToken(accessToken: String) {
        context.tokenDataStore.edit {prefs ->
            prefs[ACCESS_TOKEN] = accessToken
        }
    }

 

datastore에 쓰는 부분이다. SharedPreferences와 유사한 모습인데, edit 메서드는 데이터를 트랜잭션 방식으로 업데이트 한다. 람다로 묶인 부분은 단일 트랜잭션으로 취급된다. suspend fun으로 선언되어 있기 때문에 반드시 코루틴에서 호출해야한다.

override suspend fun getAccessToken(): String {
        val userAccessToken: Flow<String?> = context.tokenDataStore.data.map {
            it[ACCESS_TOKEN]
        }
        return userAccessToken.first().toString()
    }

 

Flow를 통해 값을 읽는 코드다. first()는 Flow의 첫번째 값을 collect하는 메서드인데, 위 코드에서는 값이 하나기 때문에 first로 충분하다.

HTTP통신 헤더에 토큰 값을 넣을 때는 비동기로 처리할 때 값 보장이 안될 수 있어서 runBlocking을 사용했다.

참조:

https://developer.android.com/jetpack/androidx/releases/datastore?authuser=1&hl=ko#:~:text=kotlin%20%ED%8C%8C%EC%9D%BC%EC%9D%98%20%EC%B5%9C%EC%83%81%EC%9C%84%20%EC%88%98%EC%A4%80%EC%97%90%20%EB%B0%B0%EC%B9%98%ED%95%98%EB%A9%B4%20%EC%9D%B4%20%EC%9D%B8%EC%8A%A4%ED%84%B4%EC%8A%A4%EA%B0%80%20%ED%95%98%EB%82%98%EB%A7%8C%20%EC%83%9D%EA%B9%81%EB%8B%88%EB%8B%A4.

https://medium.com/androiddevelopers/introduction-to-jetpack-datastore-3dc8d74139e7

https://developer.android.com/topic/libraries/architecture/datastore?authuser=1&hl=ko

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

고차 함수 정의

코틀린에서는 람다나 함수 참조를 사용해 함수를 값으로 표현할 수 있는데, 고차 함수는 다른 함수를 인자로 받거나 함수를 반환한다. filter, map도 고차함수에 속한다.

함수 타입 - 람다로 인자 받기

함수 타입을 정의하려면 함수 파라미터의 타입을 괄호 안에 넣고, 그 뒤에 화살표를 추가한 다음, 함수의 반환 타입을 지정하면 된다. Unit 타입은 의미 있는 값을 반환하지 않는 함수 반환 타입에 쓰는 특별한 타입이다. 그냥 함수를 정의한다면 함수의 파라미터 목록 뒤에 오는 Unit 반환 타입 지정을 생략해도 되지만, 함수 타입을 선언할 때는 반환 타입을 반드시 명시해야 하므로 Unit을 빼먹어서는 안 된다.

val action: () -> Unit = { println(42) }        

인자로 받은 함수 호출

인자로 받은 함수를 호출하는 방법은 그냥 일반 함수와 같다.

fun twoAndThree(operation: (op1: Int, Int) -> Int) {
	  val result = operation(2, 3)
    println("The result is $result")
}

반환타입에 당연히 Nullable 하게 선언할 수 있고 파라미터에 이름을 붙여서 사용해도 된다. 이름을 붙여서 쓰면 가독성이 더 좋아지는 효과가 있다.

디폴트 값을 지정한 함수 타입 파라미터나 널이 될 수 있는 함수 타입 파라미터

파라미터를 함수 타입으로 선언할 때도 디폴트 값을 정할 수 있다.

fun <T> Collection<T>.joinToString(
        separator: String = ", ",
        prefix: String = "",
        postfix: String = "",
        transform: (T) -> String = { it.toString() } 
): String {
    ...
}

보다시피 디폴트 값을 람다로 지정하면 된다.

함수 타입은 invoke 메서드를 구현하는 인터페이스라는 게 이제 자연스럽게 이해되는데, 그냥 함수로 사용해도 되지만 invoke메서드를 safe call로 호출하면 더 null safe한 코드가 된다. 호출 부분만 살펴보자.

transform?.invoke(element) ?: element.toString()// 파라미터가 하나다

이렇게 하기 위해서는 함수타입도 nullable하게 고쳐줘야한다.

transform: ((T) -> String)? = null

함수를 함수에서 반환

함수를 반환하려면 return 식에 람다나 멤버 참조나 함수 타입의 값을 계산하는 식을 넣으면 된다.

fun getPredicate(): (Person) -> Boolean {
        val startsWithPrefix = { p: Person ->
            p.firstName.startsWith(prefix) || p.lastName.startsWith(prefix)
        }
        if (!onlyWithPhoneNumber) {
            return startsWithPrefix
        }
        return { startsWithPrefix(it)
                    && it.phoneNumber != null }
    }

익숙하지않은 모습이지만 반환값이 함수타입이다. return에 들어가 있는 것도, 변수로 정의된 람다와 그냥 람다 식이다.

왜 함수 타입을 사용할까? 고차함수를 사용하게 되면, 코드 구조를 좀 더 간단하게 개선할 수 있고 함수를 직접 넘기면서 그 전에 사용하던 보일러 플레이트들을 제거할 수 있게 된다. 중복제거 먼저 살펴보자.

람다를 활용한 중복 제거

사실 이건 filter, map을 사용하면서 미리 체감했을 수 있다. 코틀린으로 코딩테스트를 본다고 가정했을 때, 입력값을 받아 리스트로 변환하는 코드를 한줄로 바꿀 수 있다.

val input = br.readLine().split(" ").map{ it.toInt }.toIntArray()

함수타입이 반환되는걸 받아서 split, map, toIntArray로 차례로 변환되는 모습이다. 이렇게 함수를 넘기는 건 디자인패턴 중 전략패턴에 대응한다고 볼 수 있다. 전략에 따라 다른 람다를 넘기면 되기 때문에 자바 구버전처럼 전략별로 코드를 작성할 필요가 없어진다.

인라인 함수: 람다의 부가 비용 없애기 inline

inline 변경자를 어떤 함수에 붙이면 컴파일러는 그 함수를 호출하는 모든 문장을 함수 본문에 해당하는 바이트코드로 바꿔치기 해준다. 즉 내가 볼 때는 별도의 함수지만, 컴파일러가 볼 때는 본문에 들어가 있게 되는 것이다. 호출 비용을 없애준다는 말이다

인라이닝이 작동하는 방식

어떤 함수를 inline으로 선언하면 그 함수의 본문이 인라인된다. 다른 말로 하면 함수를 호출하는 코드를 함수를 호출하는 바이트코드 대신에 함수 본문을 번역한 바이트 코드로 컴파일한다는 뜻이다.

inline fun foo(): Person -> Boolean { }

인라인 함수의 본문 코드가 호출 지점에 들어가게 되고, 인라인 함수 안에 있는 람다 본문은 그냥 일반적인 람다 호출로 된다. 따라서 컴파일러는 무명 클래스로 감싸지 않고 람다를 사용하게 놔둔다.

인라인 함수의 한계점

인라인으로 사용한 람다가 본문에 펼쳐지기 때문에 파라미터로 받은 람다를 다른 변수에 저장했다가 사용해야되는 경우에는 인라이닝이 불가능하다. 이 경우 인라인 키워드를 붙이면

Illegal usage of inline-parameter 메시지가 나오기 때문에 noinline 키워드를 붙여서 미리 인라이닝을 금지시켜야한다.

fillter와 map은 인라인 함수로 컬렉션에서 아주 많이 사용되는데, 과정에서 중간리스트를 만들어 사용하기 때문에 컬렉션의 크기가 커지면 부가비용도 같이 커진다. 이때는 asSequence를 붙여 시퀀스로 사용하면 된다. 다만 람다를 저장해서 사용하는 시퀀스는 람다를 인라인해서 사용하지않는다.

함수를 인라인으로 선언해야 하는 경우

inline 키워드의 이점을 배우고 나면 코드를 더 빠르게 만들기 위해 코드 여기저기에서 inline을 사용하고 싶어질 것이다. 하지만 사실 이는 좋은 생각이 아니다. inline 키워드를 사용해도 람다를 인자로 받는 함수만 성능이 좋아질 가능성이 높다(전체로 보면 성능이 나빠질 수 있다는 이야기).

일반 함수 호출의 경우 JVM은 이미 강력하게 인라이닝을 지원한다. JVM은 코드 실행을 분석해서 가장 이익이 되는 방향으로 호출을 인라이닝한다. 이런 과정은 바이트코드를 실제 기계어 코드로 번역하는 과정(JIT)에서 일어난다. 이런 JVM의 최적화를 활용한다면 바이트코드에서는 각 함수 구현이 정확히 한 번만 있으면 되고, 그 함수를 호출하는 부분에서 따로 함수 코드를 중복할 필요가 없다. 반면 코틀린 인라인 함수는 바이트 코드에서 각 함수 호출 지점을 함수 본문으로 대치하기 때문에 코드 중복이 생긴다. 게다가 함수를 직접 호출하면 스택 트레이스가 더 깔끔해진다.

inline 변경자를 함수에 붙일 때는 코드 크기에 주의를 기울여야 한다. 인라이닝하는 함수가 큰 경우 함수의 본문에 해당하는 바이트코드를 모든 호출 지점에 복사해 넣고 나면 바이트코드가 전체적으로 아주 커질 수 있다.

자원 관리를 위해 인라인된 람다 사용

자바 7부터는 자원을 관리하기 위한 특별한 구문인 try-with-resource문이 생겼다. 코틀린으로는 use함수가 있는데 closable 자원에 대한 확장함수며, 파라미터는 람다다. 작동방식은 람다를 호출하고, 자원을 닫는다.

BufferedReader(FileReader(path)).use { br ->
        return br.readLine()
    }

람다를 실행하고, FileReader를 인자로 받는 BufferedReader를 close한다.

고차 함수 안에서 흐름 제어

람다 안의 return문: 람다를 둘러싼 함수로부터 반환

for와 forEach의 차이를 보겠다.

fun lookForAlice(people: List<Person>) {
    people.forEach {
        if (it.name == "Alice") {
            println("Found!")
            return
        }
    }
    println("Alice is not found")
}

람다 안에서 return을 사용하면 람다로부터만 반환되는 게 아니라 그 람다를 호출하는 함수가 실행을 끝내고 반환된다. 그렇게 자신을 둘러싸고 있는 블록보다 더 바깥에 있는 다른 블록을 반환하게하는 방식을 non-local return이라 부른다. 예제에서 forEach는 인라인 함수이므로 람다 본문과 함께 인라이닝된다. 따라서 return 식이 바깥쪽 함수를 반환시키도록 쉽게 컴파일할 수 있다.

람다로부터 반환: 레이블(label)을 사용한 return

람다 식에서도 로컬 return을 사용할 수 있다. 반복문 탈출 할 때 break지점 지정하는 것과 비슷한데. 로컬 return과 넌로컬 return을 구분하기 위해 레이블(label)을 사용해야 한다.

fun lookForAlice(people: List<Person>) {
    people.forEach label@{
        if (it.name == "Alice") return@label
    }
    println("Alice might be somewhere")
}​

람다에 레이블을 붙여서 사용하는 대신 람다를 인자로 받는 인라인 함수의 이름을 return 뒤에 레이블로 사용해도 된다. 람다 식의 레이블을 명시하면 람다식에 레이블을 2개 이상 넣을 수 없기 때문에 함수이름을 레이블로 사용할 수 없다.

people.forEach {
        if (it.name == "Alice") return@forEach
    }

무명 함수: 기본적으로 로컬 return

무명 함수는 코드 블록을 함수에 넘길 때 사용할 수 있는 다른 방법이다. 람다 안에서 여러개의 return@label이 필요하게 되면 보기 어렵기 때문에 이럴 때는 무명함수를 사용하는 것이 좋다.

fun (person) {
        if (person.name == "Alice") return
        println("${person.name} is not Alice")
    }

이렇게 시그니처가 없는게 무명함수인데

fun lookForAlice(people: List<Person>) {
    people.forEach(fun (person) {
        if (person.name == "Alice") return
        println("${person.name} is not Alice")
    })
}

무명 함수 안에서 레이블이 붙지 않은 return 식은 무명 함수 자체를 반환시킨다. 식을 본문으로 하면 반환타입도 생략할 수 있게된다. 무명함수를 사용하면 무명함수 본인을 반환하기 때문에 로컬 리턴 방식으로 작동하게된다. 람다 식의 구현 방법이나 람다 식을 인라인 함수에 넘길 때 어떻게 본문이 인라이닝 되는지 등의 규칙을 무명 함수에도 모두 적용할 수 있다.

요약하자면 return을 이해할때는 가장 가까운 fun을 반환한다고 보는게 편하다.

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

Part2 첫 장이다. 연산자 오버로딩, 메서드 네이밍 컨벤션, 위임 프로퍼티에 대한 내용이 나온다.

operator

연산자 오버로딩이다.

data class Point(val x: Int, val y: Int)

operator fun Point.plus(other: Point): Point {
    return Point(x + other.x, y + other.y)
}

사용할 데이터 클래스의 확장함수로 연산자 오버로딩을 만들었다. + 연산은 plus함수를 호출해서 컴파일되기 때문에 operator를 안붙인다면 미리 예약된 메서드 이름인 plus가 겹친다고 에러가 나온다. 코틀린은 미리 지정된 연산자만 오버로딩 가능하며, times(곱셈), div(나눗셈), mod(나머지연산), plus, minus 가 있다.

반환 타입이 수신객체와 달라도 가능하다.

operator fun Char.times(count: Int): String {
    return toString().repeat(count)
}

한가지 유의할 건 코틀린은 교환법칙을 지원하지 않기 때문에 1.5*p, p*1.5는 다른 연산자를 호출 할 수 있다.

정의된 변수가 var이라면 +=, -= 와 같은 복합대입연산자도 오버로딩이 된다. 다만 반환타입이 있는 경우에는 새로 인스턴스를 만들어 참조시키는데, 원래 값의 내부를 변경하고 싶다면 Unit으로 반환값을 주는 -Assign 연산자함수를 오버로딩하면된다.

문제는 plus와 plusAssign을 동시에 정의했다면, var 변수의 경우 모호성 에러를 내뿜는다. 따라서 val로 지정해서 쓰거나, 동시에 정의하는 일을 피해야한다.

단항연산도 오버로딩이 되는데, unaryPlus, unaryMinus, inc, dec, not 을 사용한다. 단항이니 파라미터도 없다.

operator fun Point.unaryMinus(): Point {
    return Point(-x, -y)
}

증감연산자인 inc, dec을 보면

operator fun BigDecimal.inc() = this + BigDecimal.ONE

this를 이용해 구현하는 걸 볼 수 있다.

다음은 비교 연산자인데, equals나 compareTo를 오버로딩하는 것이다. equals는 Any에 정의되어 있기 때문에 override를 붙여서 사용해야한다.

class Point(val x: Int, val y: Int) {
    override fun equals(obj: Any?): Boolean {
        if (obj === this) return true
        if (obj !is Point) return false
        return obj.x == x && obj.y == y
    }
}

===를 이용해 메모리 값을 비교하는 방법은 오버라이딩이 안된다. 따라서 if (obj === this) return true 이렇게 비교하는 것이다.

compareTo는 Comparable 인터페이스에 있는 메서드를 호출하는데, 사용할 클래스에서 인터페이스를 상속받아야한다.

class Person(
        val firstName: String, val lastName: String
) : Comparable<Person> {

    override fun compareTo(other: Person): Int {
        return compareValuesBy(this, other,
            Person::lastName, Person::firstName)
    }
}

Comparable<T> 이기 때문에 타입을 지정해줘야한다.

Collection에서 in은 contains에 대응한다. 컬렉션 안의 원소중 필요한 값의 유무를 찾으려면 in을 쓰면 된다. for에서 사용하는 in은 이터레이터를 얻는 것이라서 의미가 다르다.

닫힌범위를 지정할때만드는 ..는 rangeTo에 대응한다. Comparable 인터페이스를 구현한 상태라면 rangeTo는 자동으로 지원되므로 따로 구현할 필요가 없다. 책을 보다가 이거는 좀 헷갈릴만한 것 같아서 가져왔다

0..n+1
0..(n+1)

두 범위는 같게 나온다. rangeTo의 우선순위가 낮기 때문에 괄호를 쳐줄 필요는 없지만 가독성을 위해 괄호를 쓰거나, 띄어쓰기를 해주는게 좋다.

destructuring도 대응하는 메서드가 있다.컴파일러에서 변환하는 메서드라 코드에서 보이지는 않는 componentN인데 N은 변수 위치에 따라 달라지는 값이다. 무한히 componentN을 선언할수는 없고, 5개까지 가능하다.

5개를 초과하면

Destructuring declaration initializer of type List must have a 'component6()' function

이런 에러문을 보여준다.

for ((key, value) in map) {
        println("$key -> $value")
    }

이런 구조분해선언은 루프와 map을 같이 쓸때 장점이 극대화된다. 자바에서는 안되던 map 이터레이션이 코틀린에서는 되기 때문에 가능한 방법이다.

위임 프로퍼티 delegated property

앞 내용이 연산자에 대한 이해를 높이는 거 였다면, 이번 장의 핵심은 이거라고 생각한다. 위임은 디자인패턴에서도 나오는데 객체가 직접 작업을 수행하는 게 아니라 작업을 처리하게 하는 도우미 객체를 호출하는 방법이다. 이 도우미 객체를 위임 객체라고 하고 여기서는 프로퍼티의 접근자에 대응한다.

class Foo{
  private val delegate = Delegate()
  var p: Type
  set(value: Type) = delegate.setValue(..., value)
  get() = delegate.getValue(...)
}

접근은 p에 하지만, 실제로 값 처리는 delegate에서 하는 모습이다. 사용하는 모습이 viewmodel의 프로퍼티를 설정하는 것과 비슷한데

private val _answerId = MutableLiveData<String?>()
val answerId: LiveData<String?> = _answerId

backing property라는 기법이다.

java.beans에 있는 PropertyChangeSupport와 setter의 field를 조합해서 리스너를 만들 수도 있지만, 위임프로퍼티를 사용해 만들어보겠다.

open class PropertyChangeAware {
    protected val changeSupport = PropertyChangeSupport(this)

    fun addPropertyChangeListener(listener: PropertyChangeListener) {
        changeSupport.addPropertyChangeListener(listener)
    }

    fun removePropertyChangeListener(listener: PropertyChangeListener) {
        changeSupport.removePropertyChangeListener(listener)
    }
}
class ObservableProperty( // observer를 구현해둔 것.
    var propValue: Int, val changeSupport: PropertyChangeSupport
) {
    operator fun getValue(p: Person, prop: KProperty<*>): Int = propValue

    operator fun setValue(p: Person, prop: KProperty<*>, newValue: Int) {
        val oldValue = propValue
        propValue = newValue
        changeSupport.firePropertyChange(prop.name, oldValue, newValue)
    }
}

도우미 클래스인데, getValue, setValue를 오버라이딩해서 접근자를 개조했다. 이 방법 말고 Delegates.observable을 쓰는 방법이 더 간단하지만 어떻게 생겼나 보기 위해 이 코드를 가져왔다. 이때 사용된 KProperty는 코틀린에서 프로퍼티를 표현하는 타입이다. 이렇게 하면 get, set을 통해 간단히 값을 옵저빙할 수 있게된다. by를 사용해 위임 객체로 지정한다. 그러면 이전에 getter, setter에서 field로 접근해 일일이 연결해줘야했던 걸 컴파일러가 해준다.

var age: Int by ObservableProperty(age, changeSupport) // Delegates.observable(age, changeSupport)
var salary: Int by ObservableProperty(salary, changeSupport)

이때 컴파일러에서는 ObservableProperty클래스의 인스턴스를 age의 프로퍼티에 저장하고 이걸 delegate, 프로퍼티를 표현하기 위한 KProperty는 property로 생성한다.

이번장은 뭔가 정보의 나열들이라는 생각이 든다.

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