[번역] Java가 주지 않는 Kotlin의 7가지 기능 (그리고 단점)

어느 순간부터 코틀린으로 짠 오픈소스가 눈에 보이고 굳이 찾아보지 않았는데 여기 저기서 코틀린에 대한 언급이 되면서 언젠가 한번은 확인을 해봐야 겠다 생각했다. (불행히도 그 말은 절대 확인하지 않는다와 일치한다)

그러다가 Android Weekly #256 에서 이 글을 보게 되었는데 Java와 비교해서 코틀린이 가지는 장점과 Java에서의 구현 방법의 비교가 잘 되어 있어 코틀린을 처음 접하는 안드로이드 개발자, 코틀린의 장점을 알고자 할 때 유용하다 생각이 들었다.

[번역] Kotlin vs. Java: 커머셜 안드로이드 프로젝트를 위한 코틀린 사용으로부터 첫번째 영감

(아래 참고 문헌 링크를 번역 및 요약한 글입니다.)

안드로이드 개발에서 Kotlin은 스위프트가 Objective-C에 비교되는 것과 같다. 스위프트처럼 코틀린은 단순하고 깔끔하고 자바에 비해 많은 코드를 지울 수 있다. 몇 가지 자바가 지원하지 않는 피처도 있다.

2011년부터 얘기는 많았지만 상업적으로 사용하기 위해서는 다른 언어와 마찬가지로 시간이 필요하다.

코틀린의 러닝커브는 꽤 낮다. 경험있는 자바 개발자들은 몇 시간 안에 코틀린을 파악한다. C# 개발자들도 코틀린을 쉽게 접하는데 두 언어가 몇 가지 피처를 공유하기 때문이다.

안드로이드 스튜디오는 코틀린을 위한 도구적 지원이 좋은데 JetBrains에서 만들어진 것이라서다. 코틀린은 자바와 상호운용이 가능하다. 코틀린 기반 프로젝트에 자바 라이브러리를 사용하는 것도 바로 가능하다. RxKotlin의 경우 RxJava에 코틀린 래퍼를 입힌 라이브러리이다.

가장 큰 장점은 아마 다음과 같은 피처 집합일 것이다.

• nullable, non-nullable 타입으로 Null safety, 안전한 호출과 안전한 캐스팅

• Extention functions

• Higher-order functions / 람다 표현식

• Data 클래스

• Immutability

• Coroutines

• Type aliases

Null safety

코틀린은 non-nullable을 기본으로 해 null 참조를 제거한다. 이 말은 컴파일러가 초기화되지 않는 사용을 막는다는 얘기다. null 값을 가지고 싶으면 그 타입을 nullable로 선언해야 한다.

var nullable: String?

nullable 변수에 접근할 때는 null을 두 가지 방식으로 확인할 수 있다.

if (nullable != null) nullable.doStuff()
nullable?.doStuff() //safe call

세이프 호출은 체인이 가능하다.

nullable!!.doStuff() 는 호출을 강제하고 null이면 NullPointException을 발생한다.

Extensiton Functions

클래스에 상속하거나 데코레이터 패턴을 사용하지 않고도 행동을 추가할 수 있는 기능이다. 마치 클래스의 한 기능인것 처럼…

fun String.makePretty(): String {
    //… make the string pretty and return it
}

위의 핵심은 함수 이름 전의 타입 qualifier이다. 정적 함수로 컴파일 되고 Java에서는 StringExtensions.makePretty(myString); 코틀린에서는 myString.makePretty()로 호추할 수 있다.

Higher-order functions and lambdas

고차 함수(?)는 함수를 파라미터로 가져오고 함수를 리턴할 수 있다. 주요 유스케이스는 콜백 함수이다. 자바에서는 인터페이스를 받고 한쪽에서 인터페이스를 구현해야 하는반면(많은 코드를 요구하는). 함수는 변수에 저장되어서 나중에 사용될 수 있다. 또는 또다른 함수안에서 생성될 수도 있다. 함수가 선언되지 않았는데 전달되는 것을 우리는 람다 또는 익명 함수라고 한다. 또한 "functional literal"이라고도 한다. Java8은 람다를 지원하지만 안드로이드는 여전히 Java7을 사용하기 때문에 코틀린을 사용해야 하는 큰 이유이기도 하다.

//In Kotlin:
fun networkCall(onSuccess: (ResultType) -> Unit, onError: (Throwable) -> Unit){
  try {
    //... something
    onSuccess(myResult)
  } catch(e: Throwable) {
    onError(e)
  }
}
​
//Usage:
networkCall(result -> { 
  //successful result
}, error -> {
  // handle error
});

//In Java:
public interface Callback {
  void onSuccess(ResultType result);
  void onError (Exception exception);
}
​
public void networdCall (Callback callback) {
  try{
    //...
    callback.onSuccess(myResult);
  }catch (e: Throwable) {
    callback.onError(e);
  }
}
​
//Usage:
networkCall(new Callback() {
  public void onSuccess(ResultType result) {
    
  }
  public void onError(Exception e){
    
  }
})

Data classes

이 피처로 크게 시간 절약을 할 수 있다. 대부분의 애플리케이션은 데이터 기반이라고 하면 가끔 우리 스스로 데이터를 가지고 있기 위해 속성과 필드만 있는 클래스를 만들곤 한다. Java에서는 이런 과정이 매우 지루하다. 각 필드의 get/set 메서드를 요구하는 것도. 코틀린에서는 클래스를 싱글라인으로 모든 속성과 함께 선언할 수 있다. 컴파일러가 모든 게터와 세터를 만들고 toString(), copy() 함수까지 생성한다.

data class User(var name: String, var age: Int)

Immutability

멀티스레드 앱을 개발할 때 한가지 큰 걱정은 상태 관리이다. 변수가 mutable하면 어떤 스레드에서든 접근하면 변화가능하고 이것은 우리가 수동으로 동기화를 구현해야 데이터 붕괴를 피할 수 있다. 그리고 복잡성과 실행 시간을 증가시킨다. 만약 데이터가 절대 변하지 않는다면 멀티 스레드에서 에러없이 접근이 가능하다.

코틀린에서 변수를 var, val로 선언할 수 있는데 var는 재설정 가능한 변수이고 후자는 한번 설정되면 변경할 수 없다. 컴파일러는 변수가 재설정될 수 없음을 확신할 수 있다. 자바는 비슷한 기능으로 final 키워드를 가지지만 var/val는 더 큰 의미를 가지는데 속성을 선언할 때 var는 게터/세터로 정의하는반면 val는 게터와 프라이빗 세터로 정의하고 항상 생성자에서 할당되어야 한다.

만약에 mutable 객체를 가지는 val 변수는 실제로 immutability는 아닌데 리스트는 새로 할당할 수 없어도 리스트 내용이 바뀔 수 있기 때문이다.

코틀린 표준 라이브러리는 많은 immutable 콜렉션 인터페이스를 제공한다. 예를 들어 listOf() 함수는 읽기전용 빈 리스트를 생성한다.

Coroutines

전형적으로 롱러닝 태스크를 수행하기 위해 스레드를 호출하는데 Coroutines는 스레드를 블로킹하지 않고 실행할 수 있다. 겉으로는 동기적이면서 실제론 비동기적인 코드를 쓸 수 있다. 컴파일하는 동안 그 코드는 비동기적으로 바뀐다. 즉, 이 기술은 가상 머신이나 OS에 의존하지 않는다.

Type aliases

단순하지만 유용한 피처인데 몇 가지 키 입력을 저장하고 코드를 읽기 편하게 한다. 대안적인 이름 또는 별명을 타입에 붙이는 능력이다.

typealias MapOfLists = Map<String, List>
​
fun useMap(map: MapOfList) {
  //...
}

사용전 주의해야 할 점

매 릴리즈 마다 장벽을 개선해나가고 있긴 하지만 순수 자바보다 패키지 사이즈가 커진다는 점. 코틀린 표준 라이브러리가 자바 표준 라이브러리 위에 더해지기 때문이다. 그리고 빌드 시간이 조금 더 느리다. (안그래도 Gradle 빌드 시간이 느리지만 더 느리다)

참고 문헌

https://translate.googleusercontent.com/translate_c?anno=2&depth=1&rurl=translate.google.com&sl=auto&sp=nmt4&tl=ko&u=https://arctouch.com/2017/05/kotlin-vs-java/&usg=ALkJrhjyqbOFI-qYRiAT1WOok1-JX7TnaA