함수 호출과 정의

fun <T> joinToString(
        collection: Collection<T>,
        separator: String,
        prefix: String,
        postfix: String
): String {

    val result = StringBuilder(prefix)

    for ((index, element) in collection.withIndex()) {
        if (index > 0) result.append(separator)
        result.append(element)
    }

    result.append(postfix)
    return result.toString()
}

함수에 관해 얘기하는 이번 3장에서 계속 사용될 제네릭 함수다. 구분자를 받아서 앞뒤로 “(“, “)”를 붙여서 반환하는 함수다.

하나 하나 살펴보자.

코틀린에서는 인자에 이름을 붙일 수 있다. 함수를 호출할 때 separator = "." 와 같은 형식으로 인자를 넣어 전달할 수 있는데, 중간에만 넣을 수는 없고, 명명한 인자 이후로는 모두 이름을 붙여 호출해야된다는 규칙이 있다. 이렇게 사용하면 인자를 확실히 구분할 수 있어 여러개의 인자를 갖는 함수에 대한 혼동을 줄일 수 있다.

인자에 이름을 붙이는 행동은 디폴트 파라미터와 연결되는데, 함수 선언시 파라미터에 값을 지정해두면 해당 인자에 값이 들어오지 않을 경우 미리 지정해둔 값으로 파라미터 입력값을 대신한다. 이것을 디폴트 파라미터라고 하며, 디폴트 파라미터가 있는 함수를 이름붙여 사용하면 파라미터 순서와 관계없이 인자를 전달 할 수 있게 된다.

최상위 함수와 최상위 프로퍼티

코틀린에서는 함수를 꼭 클래스안의 메서드로 작성할 필요가 없다. 그냥 파일을 생성해서 함수를 적으면 되고, 해당 함수를 사용할 때는 함수가 들어있는 파일의 패키지만 import해주면 사용할 수 있다. 어떻게 이게 가능할까? 그 이유는 코틀린 컴파일러가 최상위함수가 들어있는 파일을 컴파일 할 때 새로운 클래스를 만들어서 JVM에 넘겨주기 때문이다.

package ch03.JoinToString

fun <T> joinToString(
       ...
){ ... }

이런식으로 정의하고, 사용할 수 있다. 코틀린 컴파일러가 생성한 새로운 클래스의 이름은 함수가 들어있던 파일과 대응하고, 최상위 함수는 정적 함수로 존재하게 된다. 이런 모양은 함수뿐만 아니라 프로퍼티도 가능한데, 클래스 범위 밖에서 const val로 상수를 선언하는게 그 예시다. const val은 자바의 public static final로 컴파일된다. 단 const 는 primitive타입들과, String 타입만 가능하다.

확장함수와 확장 프로퍼티

확장함수

확장함수는 기존 API를 건드리지 않고 클래스 밖에서 해당 클래스의 멤버 메서드인 것처럼 사용할 수 있는 함수다. 예시를 보자.

fun String.lastChar(): Char = this.get(this.length - 1)

String클래스를 확장해서 만든 lastChar()함수다. String클래스 객체에서 사용할 수 있게된다. 이때 확장할 클래스 이름(여기서는 String)을 수신 객체 타입(receiver type)이라고 하고 this.get()에서 사용되는 this가 호출되는 대상 값으로 수신 객체(receiver object)라고 부른다. 즉 수신객체는 클래스의 인스턴스 객체라고도 할 수 있다. 확장함수는 내부적으로 수신객체를 첫번째 인자로 받기 때문에 실행시점의 부가비용이 들지 않는다.

위 코드에서 사용된 this는 가독성을 위해 사용된 것이지 함수 본문에서 생략가능하다. 이렇게 클래스 밖에서 정의된 확장함수는 캡슐화를 깰까? 정답은 “깨지않는다”이다. 확장함수는 클래스의 private, protected 멤버에 접근할 수 없기때문에 캡슐화를 지키고 있다고 할 수 있다. 이렇게 만든 확장함수는 import해서 사용할 수 있다.

import string.lastChar
import string.*

아래 위 모두 확장함수를 사용할 수 있게 해주는 import구문이다. 확장함수와 다른 패키지의 함수가 이름이 겹치면 as를 이용해 다른 이름으로 확장함수를 별명지어 사용할 수도 있다.

마냥 좋을 것 같은 확장함수도 못하는게 있는데, 오버라이딩이다. 안드로이드에서 setOnClickListener의 object로 View의 onClick이 오버라이딩되는데, 이러면 오버라이딩 한 함수가 실행되는 것이 일반적이다. 그러나 이건 클래스 안에 들어있는 것이라 가능한 것이고, 확장함수는 클래스 밖에 있어서 오버라이딩 할 수 없다. 오버라이딩이 동적으로 결정되는 것이 반해 확장함수는 수신객체, 수신객체 타입에 의해 정적으로 결정되기 때문이다.

val view: View = Button()
    view.showOff()

view변수는 View타입이기 때문에 View의 확장함수 showOff를 실행하지 Button의 showOff를 실행하지 않는다. view: Button 이었다면 Button의 showOff를 실행했을 것이다.

확장 프로퍼티

확장 프로퍼티는 함수형태가 아니라 프로퍼티 형태로 정의하는 함수라고 보는 게 편하다. 인스턴스의 상태를 저장할 수없고 단지 프로퍼티 문법만 이용하기 때문이다. 확장함수를 프로퍼티 문법으로 바꾸려면 get()을 이용해야한다. 값을 저장할 수 없어 backing field가 없기 때문에 get()으로 게터를 정의해줘야하며 경우에 따라서 set()을 이용해 간단한 조작도 가능하긴하다. 아래가 그 예시다.

var StringBuilder.lastChar: Char
    get() = get(length - 1)
    set(value: Char) {
        this.setCharAt(length - 1, value)
    }

Collection

코틀린의 컬렉션은 자바 컬렉션을 그대로 사용한다. 거기에 확장함수로 코틀린에서 편하게 사용할 수 있는 API가 추가된 것이다.

varargs

이건 익숙한 표현이다. 가변길이 인자인데, 원하는 만큼 값을 넣어 인자로 넘기면 컴파일러가 배열에 값을 넣어 처리하는 것이다. 배열을 가변인자로 넘길때는 코틀린과 자바가 다른데, 코틀린에서는 전달할 배열 앞에 스프레드 연산자인 *를 붙이면 원소들을 펼쳐서 인자로 넣어준다.

val list = listOf("args: ", *args)

중위호출과 구조 분해

mapOf(a to b)에서 a는 key, b는 value로 맵핑되어 저장된다. 이때 사용되는 to는 키워드가 아니라 일반 메서드(확장함수다)이고, 중위호출(infix)로 사용된 것이다. 수신객체 to 유일한 메서드 인자로 되는데 to함수의 반환이 Pair임을 알면 구조분해까지 이해할 수 있다. Pair는 자바에는 없는 개념인데 순서쌍을 나타낸다.

val (num, name) = 1 to "one"

으로하면 num에 1, name에 one이 들어가는데, 이걸 구조분해선언, destructuring declaration이라고 한다. 우리는 이미 구조분해선언을 사용했다. for문에서 사용한 .withIndex()가 그 정체다.

to가 map에서 사용돼서 map에서만 사용해야되는 줄 알 수도 있는데, 순서쌍이 필요하면 to를 사용할 수 있다.

문자열과 정규식

정규식은 꼭 한번 익히고 넘어가야했던 부분이다. 자바의 문자열 메서드 중 split()의 인자로 “.”을 사용할 수 없는데, 이건 split의 인자가 정규식이고 .이 모든 문자를 나타내는 정규식으로 해석되기 때문이다.

import java.util.Arrays;

class Main {
  public static void main(String[] args) {
      String test = "12.51.6262.6515.";
      System.out.println(Arrays.toString(test.split(".")));
  }
} 

빈 문자열을 반환하는 걸 볼 수 있다. 코틀린에서는 이런 문제를 피하기 위해 기본을 String으로 받고 .toRegex()로 정규식임을 명시해주는 방법을 사용했다. 이렇게 쓰면 정규식을 표현할 때 \ 역슬래시를 사용하기 위해 \\로 표현하던걸 “”” “"”를 이용해 이스케이프 할 노동을 줄일 수 있게된다. 추가로 삼중 따옴표에도 문자열 템플릿을 넣을 수 있다.

정규식 문법은 필요할 때마다 찾아서 사용하면 된다.

로컬 함수

코드 중복을 줄이는 방법 중에 하나인데, 함수에서 추출한 함수를 원함수 내부에 중첩시키는 방법이다. 그냥 함수 안에 또 함수를 선언하는 것이다.

fun User.validateBeforeSave() {
    fun validate(value: String, fieldName: String) {
        if (value.isEmpty()) {
            throw IllegalArgumentException(
               "Can't save user $id: empty $fieldName")
        }
    }

    validate(name, "Name")
    validate(address, "Address")
}

validate가 로컬함수다. 함수 스코프를 보면 적어도 validateBeforeSave함수, 즉 validate함수 바깥에 있는 파라미터, 변수에 접근할 수 있게된다. 함수 중첩은 1 depth까지만 하는게 권장사항이다.

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

제네릭스를 쓰면 타입 파라미터를 받는 타입을 정의할 수 있다.(List, Map 과 같은)

코틀린은 값이 들어오는 것에 따라 타입인자를 추론할 수 있는데, 빈리스트를 만들 경우에는 타입인자의 타입을 명시해줘야한다. 자바에서는 처음부터 제네릭이 없었기에 타입인자를 명시하지않고 선언하는게 가능하지만 코틀린은 처음부터 제네릭이 도입돼서 추론을 하게 하던가, 명시를 해야한다.

제네릭 함수와 프로퍼티

모든 타입인자를 갖는 리스트를 다룰 수 있는 함수를 작성하면, 반드시 호출시점에 구체적인 타입을 타입인자로 넘겨줘야한다. 

fun <T> List<T>.slice(indices: IntRange) : List<T>

반환 값도 제네릭, 타입 인자도 제네릭이다. 수신객체를 이용한 함수로 정의되어 있다.

제네릭 클래스도 마찬가지로 <T>를 이용해 선언한다.

interface Comparable<T> {
    fun compareTo(other: T): Int
}

class String : Comparable<String> {
    override fun compareTo(other: String): Int = /*...*/
}

클래스에서 Comparable 인터페이스를 구현하는데, T에 String을 넣어서 구현했다.

타입 파라미터 제약

어떤 타입을 제네릭 타입의 타입 파라미터에 대한 상한으로 지정하면 그 제네릭 타입을 인스턴스화할 때 사용하는 타입 인자는 반드시 그 상한 타입이거나 그 상한 타입의 하위 타입이어야 한다. 상한으로 지정한다는 얘기는 Number같은 최상위 타입을 지정할 때를 말한다.

fun <T : Number> oneHalf(value: T): Double { 
    return value.toDouble() / 10.0
}

상한을 지정하면 이때부터 T는 상한타입으로 변한다.

이런 제약은 단일 제약이고, 여러 제약을 적용하고 싶으면 타입 파라미터 제약 목록을 사용하면 된다.

fun <T> ensureTrailingPeriod(seq: T) 
    where T : CharSequence, T : Appendable { // <- 이 부분의 조건 검사가 목록역할함
    
    }

non-null 타입으로 한정하는 법도 있다. 상한을 정하지않은 타입 파라미터는 Any?가 디폴트인데, 그러면 nullable이 기본이다. 항상 non-null만 인자로 받게하려면 Any를 명시적으로 써서 상한을 지정하면된다.(Any가 아니어도 non-null type으로 상한을 지정하면된다.)

그러면 String?, Int?는 Any?의 자손타입이지 Any의 자손타입이 아니기 때문에 null이 들어오지 못하게 만들 수 있다.

실행 시 제네릭스 동작

JVM의 제네릭스는 타입소거(type erasure)를 사용해 구현된다. 실행시점에 제네릭 클래스의 인스턴스에 타입인자 정보가 존재하지않는데, 이걸 inline함수를 이용해 타입인자가 런타임시점에 지워지지 않게 하는 것을 실체화(reify)라고 한다. 타입소거의 장점으로는 저장해야하는 타입정보 크기가 줄어서 메모리 사용량을 줄인다는 것이 있다.

실행시점에 제네릭스 인스턴스는 그 자체로만 있고, 어떤 원소타입을 갖는지는 컴파일러가 잘 보장해준다.

이번에 프로젝트 리팩토링하면서 자주 본 에러인데

if (value is List<String>) { ... }
ERROR: Cannot check for instance of erased type

타입소거로 인해 is 검사에서 타입인자로 지정한 타입을 실행시점에서 검사할 수 없기 때문에 발생하는 에러다. 이걸 올바르게 고치려면 

if (value is List<*>)

타입인자 타입을 *(스타프로젝션)으로 바꿔야한다. as 캐스팅에서는 빌드는 허용하지만 경고문구가 unchecked cast라고 나오긴하니 주의해야한다.

실체화

제네릭 함수의 본문에서 그 함수의 타입인자를 가리킬수 있게 하는 방법으로 inline 함수가 있다. 이게 인라인 함수가 유용한 이유 중 하나인 타입인자 실체화이다.

제네릭 함수를 인라인 함수로 만들고, 타입파라미터를 reified로 지정하면 실행시점에 타입 검사가 가능하다.

inline fun <reified T> isA(value: Any) = value is T

컴파일러는 인라인함수의 본문을 바이트코드로 변환해서 호출 지점에 다 붙여버린다. 이때 reified된 인자를 호출 지점에서 다 알 수 있기 때문에 실행시점에 타입 검사가 가능하다.

java.lang.Class 타입인자를 받는 경우 실체화를 자주 사용한다.

ClassName::class.java로 파라미터에 넣는 경우인데, 이걸 inline과 reified를 이용해 바꿔보면 아래와 같다.

inline fun <reified T: Activity> Context.startActivity() {
	val intent = Intent(this, T::class.java)
    startActivity(intent)
}

::는 클래스 참조할 떄 사용하는데, 10장에 리플렉션 때 자세히 나온다고한다.

실체화도 하지 못하는 게 있다.

• 타입 파라미터 클래스의 인스턴스 생성
• 타입 파라미터 클래스의 동반 객체 메소드 호출
• 실체화한 타입 파라미터를 요구하는 함수를 호출하면서 실체화하지 않은 타입 파라미터로 받은 타입을 타입 인자로 넘기기
• 클래스, 프로퍼티, 인라인 함수가 아닌 함수의 파라미터를 reified로 지정하기(이건 어느 정도 예상했다)

마지막 제약이 있으므로, 성능상의 이유나 인라이닝되는 과정에서 람다를 인라이닝할 수 없다면 noinline을 붙여서 인라이닝을 금지 할 수 있다.

변성 variance - 무공변, 공변성, 반공변성

base 타입이 같고 타입인자가 다른 여러타입이 어떤 관계에 놓여있는지 알아보는 절이다.

원소 변경이 생긴다면 List<String> -> List<Any> 과정에서 타입 불일치가 생길 수 있어서 불가능하다. 그게 아니라면 안전하다.

제네릭이 아닌 클래스의 경우 타입이 될 수 있다. 그 예시로 String 클래스는 String, String? 두 타입이 될 수 있다. 제네릭 클래스인 경우 타입 파라미터를 구체적인 타입 인자로 바꿔줘야하며 List는 타입이 될 수 없지만 여전히 클래스이고, List<String>과 같은 경우는 타입이다.

상한 개념에서 내려와서, 컴파일러는 변수대입/ 함수인자 전달 시 하위 타입검사를 매번 수행한다. 이때 보통의 경우는 하위타입 == 하위 클래스 이지만(non-null -> nullable가능, 그 반대는 불가능) 제네릭 클래스의 경우를 보자.

인스턴스화 할 때 MutableList<A> MutableList<B>에서 A와 B의 여부에 따라 하위타입관계가 성립하지않는 경우 그때 제네릭 타입을 무공변(invariant)이라고 한다. 

다시 말하면 B가 A의 하위타입이지만 MutableList<B>는 MutableList<A>의 하위타입이 아닌 것을 무공변이라고 한다.

List<T>의 경우에는 코틀린에서 읽기전용 컬렉션인데, List<A>, List<B>는 하위타입규칙을 적용할 수 있고 이때는 공변(covariant)적이라고 말한다.

제네릭 클래스(인터페이스도 당연히 포함)가 타입 파라미터에 대해 공변적임을 나타내려면 파라미터 앞에 out을 표기해야한다. 이게 공변적이라고 선언하는 방법이다. 

interface Producer<out T> {
    fun produce(): T
}

타입 파라미터를 공변적으로 만들면 이 클래스의 인스턴스를 함수 인자나 반환값으로 사용하는 게 가능해진다.

모든 곳에 공변적으로 만들고 싶지만 공변적일때 안전하지 못한 경우가 있다. 타입 파라미터를 공변적으로 지정하면 클래스 내부에서 그 파라미터 사용 방법이 제한되는데, 타입 안전성을 위해서는 생산(read)으로 고정되고 소비(write)가 불가능하다는 점이다.

생산/ 소비 도식이다. in에서 T타입 값을 소비하고, out에서 T타입 값을 생산한다. 따라서 공변적으로 선언하려면 out위치에 존재하는 경우 안전하다.

out 키워드의 의미가 이제 확실해졌다.

1. 공변성
2. T를 아웃위치에서만 사용할 수 있게 사용제한

생성자 파라미터는 in/out 어느쪽에도 속하지않는다. 그 이유는 생성자는 인스턴스를 생성할때 호출되지 그 이후 호출할 수 있는 메서드가 아니기 때문이다. 다만 생성자 파라미터를 프로퍼티로 만든다면 그건 in/out에 속한다.

또 변성규칙은 클래스 외부에서의 안전성을 확보하기 위함이므로 public, protected, internal 클래스에만 적용되고 클래스 내부에만 유효한 private에는 적용되지않는다.

반공변성(contravariance)는 공변성을 180도 뒤집어 둔 것이다. 

공변성이 생산자(read) 관점에서 나온것이라면 반공변성은 소비자(write)관점이다. 따라서 in키워드의 위치가 반공변성의 핵심이고 타입인자의 하위타입관계가 뒤집혀서 제네릭 인자로 들어가게 된다.

지금까지 클래스를 선언하면서 변성을 지정했다. 이걸 선언지점 변성이라고 하고, 특정 타입 파라미터가 나타나는 지점에서 변성을 결정하는 걸 사용지점 변성이라고 한다.

fun <T> copyData(src: MutableList<out T>)

 호출 지점에 out을 붙여서 T타입을 out에 사용하는 메서드만 호출한다고 선언해버린 예시다. 이때 MutableList는 제약을 가해진 타입으로 바뀌며 이걸 타입 프로젝션이라고 한다. 

스타 프로젝션

제네릭 타입 인자 정보가 없음을 표현하기 위해 스타 프로젝션을 사용하고, 원소 타입이 알려지지 않은 리스트는 List<*> 라는 구문으로 표현할 수 있다고 앞서 예시로 봤다.

중요한 몇가지를 짚고 가면 *의 정확한 의미가 어떤 정해진 타입의 원소를 담지만 그 원소의 타입을 정확히 모른다는 것이지 MutableList<*> == MutableList<Any?>로 대치할 수 있는 게 아니라는 점이다.

fun printFirst(list: List<*>) {  // 모든 구체적 타입의 리스트를 인자로 받을 수 있다. 
    if (list.isNotEmpty()) { // isNotEmpty()에서는 T를 사용하지 않는다. 
        println(list.first()) // first()는 이제 Any?를 반환. 
    }
}

프로젝션이 붙는 이유는 *가 out Any?처럼 동작하기 때문이다. 반대로 in일때 스타프로젝션을 지정하면 소비대상이 어떤 T인지 알 수 없기 때문에 in Nothing으로 작동한다. 또 타입 파라미터를 시그니처에서 전혀 언급하지 않거나 데이터를 읽기는 하지만 그 타입에는 관심이 없는 경우와 같이 타입 인자 정보가 중요하지 않을 때도 스타 프로젝션 구문을 사용할 수 있다.

코틀린 인 액션 책으로 스터디를 하게 됐는데, 내가 이해한 것을 기반으로 잘 기록해둘 계획이다.

개요

코틀린은 정적타입 지정언어다

정적 타입(statically typed) 지정이라는 말은 모든 구성요소의 타입을 컴파일 때 알 수 있고, 객체의 필드/메서드를 사용 시 컴파일러가 타입을 검증한다는 뜻이다. 동적 타입은 타입과 무관하게 모든 값을 변수에 넣을 수 있고, 검증시점이 실행시점이다. Groovy가 대표적인데, 간결한 코드는 확실한 장점이지만 컴파일 시 걸러내지 못하는 오류가 실행시점에 발생하기 때문에 각각 장단점이 있다.

정적타입 지정언어의 장점은 성능, 신뢰성(컴파일러 검증), 유지보수성, 도구 지원 등이 있다.

코틀린은 자바와 같은 정적 타입 지정 언어지만, 컴파일러가 문맥으로 타입을 추론한다. 따라서 타입 명시가 따로 필요하진 않지만 유지 보수시 가독성을 위해 명시를 해 주는게 더 좋은 방향이다.

마지막으로 코틀린은 nullable type을 지원하기 때문에 컴파일 시 null 검사를 거칠 수 있다. 또 function type을 지원하기 때문에 함수형 프로그래밍을 지원한다. 안드로이드 앱 개발에서도 이 장점은 유효한데, null을 추적하기 때문에 NPE(NullPointerException)의 빈도를 확 줄일 수 있게 된다.

함수형 프로그래밍

처음 접했을 때 굉장히 난해 했는데, 크게 3가지 특징이 있다.

• 함수는 일급시민(일반 값처럼 사용가능하다. 심지어 반환값으로 함수를 쓸 수 있다.)
• 불변성
• side effect 없음(순수 함수를 사용)

이런 특징은 간결성을 살려줘 중복을 줄여주고, 동기화 걱정이 없어서 다중 스레드에서 사용시 안전하다는 점이다. 또 순수함수를 사용한다는 점은 테스트하기 편하다는 장점도 있다.

코틀린 철학

실용성, 간결성, 안전성, 상호운용성이 있는데, 각 항목을 간단히 정리해봤다.

실용성:

이미 다른 언어가 검증한 해법과 기능들을 답습하기 때문에 코틀린을 배우는데 수고가 줄고, IDE에 좋은 도구가 많기 때문에(컴파일된 자바 바이트코드 읽기와 같은) 실용적이라고 할 수 있다.

간결성:

보일러 플레이트를 자바에 비해 많이 줄였다. getter, setter는 물론이고 data class와 같은 특수 클래스, 다양한 라이브러리를 이용해 코드의 간결함을 유지한다.

안전성:

우선 어느정도 안전성이 JVM을 따르기때문에 입증되어있고, 여기서 NPE에 대한 안전성이 추가된 것이다.

상호 운용성:

자바의 기존 라이브러리를 그대로 가져다 사용할 수 있고, 자바와 코틀린이 섞인 프로젝트를 컴파일하는데 아무런 장애가 되지않는다.

컴파일 과정

.kt로 저장된 파일을 컴파일러가 컴파일을 마치면 .class파일을 생성한다. .class파일은 .jar를 통해 패키징과정을 거쳐 애플리케이션에서 실행된다. 코틀린 컴파일러를 사용한 파일은 코틀린 런타임 라이브러리에 의존한다. 따라서 코틀린으로 컴파일 된 앱을 배포할 때는 코틀린 런타임 라이브러리도 같이 배포해야되는데, gradle과 같은 도구가 앱 패키지 시점에 코틀린 런타임을 포함시켜준다. 이러면 용량이 커지는 게 아닐까? 다행히 코틀린 런타임 시스템의 용량은 작기 때문에 포함 전과 후의 용량 차이가 크게 나지 않는다.

여기서 한번쯤은 궁금할 수도 있는데, 코틀린은 클래스를 만들지 않고 fun main(){ }으로 바로 코드를 실행할 수 있다. 그 이유는 컴파일러가 자동으로 클래스를 만들고 진입점을 만들어주기 때문이다.

기본 요소들

함수

fun foo(param: Int): String{
    return if(param>10) "BIG" else "SMALL"
}

파라미터는 이름 뒤에 타입을 명시한다.

코틀린의 if는 문(statement)이 아니라 식(expression)이다. 즉 값을 반환 할 수 있고 다른 식의 하위 요소로 연산에 관여할 수 있다는 것이다. 자바의 if는 문이지만 코틀린의 if는 식이다.

fun foo(param:Int) = if(param>10) "A" else "B"

함수가 식을 본문으로 가질 수 있는데, 이 경우 반환타입을 생략할 수 있다.

변수

val, var로 나뉘는데, val로 선언한 변수는 immutable하고, var는 mutable하다. val로 선언하는 것은 자바의 final 변수로 이해하면 된다. 변수를 초기화 할 때는 변수 타입이 필요 할 수도, 없을 수도 있다. 선언과 동시에 초기화를 한다면, 컴파일러가 타입추론이 가능하지만, 초기화 시점이 선언시점보다 후라면 컴파일러가 타입추론을 할 수 없다. 그래서 초기화를 나중에 할 경우 타입명시가 꼭 필요하다.

처음 코틀린을 접할 때 들었던 의문인데

val arr = arrayListOf("a","b")

arr은 immutable하다. 그러나 arr.add(“c”)로 조작이 가능한데, 왜 그럴까.

val 참조 자체는 불변이다. 하지만 참조가 가리키고 있는 객체의 내부 까지는 val가 관여하지않기 때문에 arr가 가리키고 있는 객체에 대한 연산이라고 보면 된다.

변수를 문자열 안에서 사용하려면 아래와 같이 표기한다. 이를 문자열 템플릿이라고 한다.

print("Hello, $name")
print("Hello, ${name}")

이런식으로 $를 붙여서 사용하면 되는데, 중괄호로 묶어주는 게 좋다. 컴파일러가 변수의 범위를 정확하게 인식하게 하기 위함이다. 멤버 변수를 사용하거나, 한글과 영문변수를 붙여 쓸때 컴파일러가 오류를 내게 되므로 중괄호로 묶어서 사용하는 게 권장된다. 변수 뿐만 아니라 식도 중괄호에 넣어 사용할 수 있다.

프로퍼티

자바 클래스에서의 필드와 게터, 세터를 한번에 묶어서 코틀린 프로퍼티가 탄생했다. val로 선언한 프로퍼티는 읽기전용, var로 선언한 프로퍼티는 쓰기전용이다. 따라서 val는 게터만 갖고, var는 둘다 갖는다.

코틀린의 프로퍼티도 기본으로 getter가 있지만, 이걸 커스텀 할 수도 있는데 이 프로퍼티를 backing field라고 하며 프로퍼티 값을 그때 그때 계산해서 사용하는 작업이 필요할때 사용할 수 있다.

이런 값만 모아둔 클래스를 value object라고 하는데, 자바에서 getter와 setter로 점철된 코드가 있다면 코틀린에서는 data class라는 강력한 도구가 있다.

val isSquare: Boolean
    get(){
        return h == w
    }

get()을 붙여 선언하면 커스텀 접근자를 만들 수 있게된다. 이 프로퍼티는 h와 w가 같으면 true를 반환 하는 프로퍼티다.

enum과 when

enum은 열거형 타입이고, when은 분기 문법이다.

enum class Color{
    RED, ORANGE, BLUE
}

enum class 라는 키워드로 enum객체를 만든다.

enum class 안에 프로퍼티와 메서드를 선언 할 수 있는데, 이때 코틀린에서 유일하게 세미콜론이 사용된다. enum 상수를 정의할 때, 상수 목록 가장 끝에 세미콜론으로 구별 지어줘야 메서드 정의 부분을 인식한다.

이렇게 만든 enum 객체는 when에서 유용하게 쓰인다.

when에 enum 타입을 넣으면, enum에 정의된 값으로만 when branch를 작성하면 된다. 빠져있으면 컴파일에러가 일어나고, else가 필요없어 유지보수에 좋다.

when 역시 반환값을 도출할 수 있는 식이고, switch와 비슷하지만 더욱 유연하게 작동한다.

when(input){
    a -> "A"
    b,c -> "B"
    1...5 -> "NUM"
    else -> "O" 
}

when은 break를 따로 적어줄 필요가 없고, 비교 값의 타입이 달라도 되고, 범위로 비교할수도 있고, 여러개 값과 매치해 볼 수도 있다. 아주 유연하다.

setOf()를 사용해 집합으로 비교도 가능하다. 이 말은 객체 비교가 된다는 말이다. when은 인자가 있을 수도 있지만, 함수 반환 값으로 사용될 때는 함수의 파라미터를 바로 조건분기로 끌고과 인자 없이도 사용가능하다.

fun foo1(c1: Color, c2: Color) = when((c1 == "R")&&(c2 == "B") -> "P")

이런식으로 사용할 수 있다. 즉 각 분기의 조건이 boolean판별이면 가능한 방식이다.

분기에 블록을 사용하면 맨 마지막 줄에 return을 붙이지 않아도 반환값으로 인식한다.

타입 캐스팅

스마트 캐스트는 컴파일러가 프로그래머 대신 캐스팅을 해주는 것으로, is 검사를 통해 타입을 캐스팅하는 것이다. 검사를 마친 변수의 타입은 검사이후 계속 같은 타입을 갖는것으로 컴파일러가 인식한다. 따라서 val로 선언해줘야한다.

명시적인 타입 캐스팅은 as 타입 으로 해주면 된다.

iteration

반복문의 사용법을 알려주는 절이다

for(i in a..b)와 같은 범위형태로 사용할 수 있고, 배열을 대상으로 foreach같이 돌릴 수도 있다.

범위 지정시 ..는 항상 [ ] 이다. a until b 를 사용하면 [ )로 끝 값을 포함하지 않게 된다.

인덱스를 사용하려면 컬렉션에 .withIndext()와 인덱스 변수를 같이 넣어주면 되는데

for((idx, i) in list.withIndex()

이때 idx가 인덱스 번호를 따라간다.

반복문에서 사용되는 in은 연산자이다. 어떤 값이 해당 범위에 속하는지 in을 통해 true/false를 알 수 있다. when에서도 사용되는 것을 본 적이 있을 것이다.

예외처리

예외처리에 사용되는 try, throw 문 역시 코틀린에서는 식이다.

val exc = try{
    ..
}catch(e: NumberFormatException){
    // 예외 발생
}finally{
    // 마무
}

예외처리할 때는 try~catch~finally를 사용할 수 있고, 함수가 반환값으로 예외를 포함할 의무가 없다. 자바로 사용하다보면 throws IOException을 사용할 때가 있는데 코틀린에는 그 작업이 필요없다는 뜻이다.

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

https://www.acmicpc.net/problem/10158

import java.io.*;

class Main {
    public static void main(String args[]) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        String[] map = br.readLine().split(" ");
        int w = Integer.parseInt(map[0]);
        int h = Integer.parseInt(map[1]);
        String[] start = br.readLine().split(" ");
        int p = Integer.parseInt(start[0]);
        int q = Integer.parseInt(start[1]);
        int t = Integer.parseInt(br.readLine());
        // p가 0, w에 닿으면 다음 이동은 (반전, 그대로) q가 0,h에 닿으면 (그대로, 반전)
        int dir = 0; // 0, 1, 2, 3 시계방향 순서대로

        for(int i=0; i<t; i++){
            if(i!=0 && p == Integer.parseInt(start[0]) && q == Integer.parseInt(start[1])){
                if (t%i == 0) break;
                else{
                    t = t%i;
                }
            }
            switch (dir){
                case 0: {
                    // + +
                    p++;
                    q++;
                    if (p == w) dir = bounceX(0);
                    if (q == h) dir = bounceY(0);
                    if(p==w && q==h) dir = 2;
                }
                break;
                case 1: {
                    // + -
                    p++;
                    q--;
                    if (p == w) dir = bounceX(1);
                    if (q == 0) dir = bounceY(1);
                    if(p==w && q==0) dir = 3;
                }
                break;
                case 2: {
                    // - -
                    p--;
                    q--;
                    if (p == 0) dir = bounceX(2);
                    if (q == 0) dir = bounceY(2);
                    if(p==0 && q==0) dir = 0;
                }
                break;
                case 3: {
                    // - +
                    p--;
                    q++;
                    if (p == 0) dir = bounceX(3);
                    if (q == h) dir = bounceY(3);
                    if(p==0 && q==h) dir = 1;
                }
                break;
            }
        }

        System.out.printf("%d %d",p,q);
    }

    static int bounceX(int dir){
        int next = 0;
        switch (dir){
            case 0: {
                // + + 이게 이전 상태, 다음 상태로 가려면?
                next=3;
                break;
            }
            case 1: {
                // + -
                next=2;
                break;
            }
            case 2: {
                // - -
                next=1;
                break;
            }
            case 3: {
                // - +
                next=0;
                break;
            }
        }
        return next;
    }

    static int bounceY(int dir){
        int next = 0;
        switch (dir){
            case 0: {
                // + + 이게 이전 상태, 다음 상태로 가려면?
                next=1;
                break;
            }
            case 1: {
                // + -
                next=0;
                break;
            }
            case 2: {
                // - -
                next=3;
                break;
            }
            case 3: {
                // - +
                next=2;
                break;
            }
        }
        return next;
    }
}

오답노트(푸는 동안 사고과정 및 개선점)

경우의 수를 촘촘히 짜서 진행 방향을 바꿔주는 방식으로 설계했다... 예시는 다 맞았고 시간초과가 나버렸다.

다시 출발지점에 도착하는 경우로 설계해서 제출해봤지만 여전히 시초가 났다.

정답코드

import java.io.*;

class Main {
    public static void main(String args[]) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        String[] map = br.readLine().split(" ");
        String[] start = br.readLine().split(" ");
        int W = Integer.parseInt(map[0]);
        int H = Integer.parseInt(map[1]);
        int P = Integer.parseInt(start[0]);
        int Q = Integer.parseInt(start[1]);
        int T = Integer.parseInt(br.readLine());

        int p = (P + T) % (2 * W);
        int q = (Q + T) % (2 * H);
        if (p > W) p = 2 * W - p;
        if (q > H) q = 2 * H - q;
        System.out.println(p + " " + q);
    }
}

도착하는 게 능사가 아니라 출발지점에서 출발 방향도 같을 때를 고려했어야됐다. 그리고 주기를 구하는 게 중요한데, 그냥 대각선(이동)을 기준으로 주기를 잡으려면 무조건 시간초과가 난다.

X, Y좌표의 주기를 각각 관찰하면,

X가 방향이 같은 좌표에 도착하는 주기가 p = (T%2W)*N 이고 Y좌표는 q = (T%2H)*N 이 된다. 그리고 주기를 구할 때 X좌표 Y좌표를 분리시키면 시간 복잡도가 X, Y 둘중 큰 값으로 귀속되니까 이 방법으로 작성하면 시간초과가 나지않는다..!

출발지점이 지금은 (0,0)이 아닌데 출발지점을 원점으로 땡겨서 보면 주기를 아주 빨리 구할 수 있게된다. 이때 땡기는 정도가 초기 좌표만큼이기때문에 시간 조절을 잘 해야한다. p, q 가 W, H 보다 클 때 2*W-p 작업을 해주는 이유가 그 때문이다.

위 정답코드는 놀랍게도 시간초과가 난다..!

그 이유는 java 버전에 따른 오차로, 11로 했을때는 시간초과, 8로 했을때는 무사히 채점완료가 된다.

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