[Kotlin in Action] 1장 코틀린이란 무엇이며, 왜 필요한가?

** 코틀린은 간결하고 실용적이며, 자바 코드와의 상호운용성을 중시하는 언어다. **

data class Person(val name : String,    // '데이터 클래스'
                  val age: Int? = null) // 널이 될 수 있는 타입(Int?)과 파라미터 디폴트 값

fun main(args: Array<String>) { // 최상위 함수
    val persons = listOf(Person("영희"),
                         Person("철수", age = 29))  // 이름 붙은 파라미터

    val oldset = persons.maxBy { it.age ?: 0 } // 람다 식과 엘비스 연산자
    println("나이가 가장 많은 사람: $oldest") // 문자열 템플릿
}

// 결과 : 나이가 가장 많은 사람: Person(name=철수, age=29) toString 자동 생성

이게 뭐야 대충 유추하는건 널이 가능한 타입과 불가능한 타입을 가능한 경우엔 타입뒤에 ?를 두는 것 같다
listOf 얜 자바 스트림에서 보던거랑 비슷하다..

persons.maxBy {it.age ?: 0 } 람다..라 하네 모양이 자바 때랑은 살짝 다르다.

name, age라는 프로퍼티가 들어간 간단한 데이터 클래스를 정의한다.

age 프로퍼티의 디폴트 값은 (따로 지정하지 않은 경우) null이다.

maxBy 함수에 전달한 람다식은 파라미터를 하나 받는다. it이라는 이름을 사용하면 유일한 인자를 사용할 수 있다.

엘비스 연산자 ?:는 age가 null인 경우 0을 반환하고, 그렇지 않은 경우 age의 값을 반환

영희의 나이를 지정하지 않아도 엘비스 연산자가 0으로 변환한다.

뭔가 괜찮네.. 현대적이란 느낌일까..

코틀린의 주요 특성

정적 타입 지정 언어

자바, 코틀린 둘 다 정적 타입 지정 언어. 컴파일 시점에 모든 프로그램의 구성 요소의 타입을 알 수 있다. 프로그램 안에서 객체의 필드, 메소드를 사용할 때마다 컴파일러가 타입을 검증해준다.

동적 타입 지정 언어

JVM의 Groovy, JRuby가 동적 타입 지정 언어다. 이는 타입과 관계없이 모든 값을 변수에 넣을 수 있고 메서드 필드 접근 시 검증이 실행된다.

장점

• 코드가더 짧아진다.
• 데이터 구조를 더 유연하게 생성하고 사용할 수 있다.

단점

• 반대로 이름을 잘못 입력하는 등의 실수도 컴파일 시 걸러내지 못하고 Runtime Error를 일으킨다.

그래도 코틀린은 자바와 다른게

모든 변수의 타입을 프로그래머가 명시할 필요 없이 컴파일러가 문맥으로부터 변수 타입을 자동으로 유추한다.

EX)

var x = 1

컴파일러가 변수의 타입이 Int 임을 자동으로 알아낸다. 컴파일러가 문맥을 고려해 변수 타입 결정하는걸 타입 추론이라 한다.

정적 타입 지정의 장점

• 성능: 실행 시점에 어떤 메소드를 호출할지 알아내는 과정이 필요 없어 메소드 호출이 더 빠르다. ( 이게 무슨 말이지? 필드에게도 적용되는거 아니야?)
• 신뢰성: 컴파일러가 프로그램의 정확성을 검증하기 때문에 실행 시 프로그램이 오류로 중단될 가능성이 더 적어진다.
• 유지 보수성: 코드에서 다루는 객체가 어떤 타입에 속하는지 알 수 있기 때문에 처음 보는 코드를 다룰 때도 좋다.(var로 다 땜빵치면 이런거 없지 않아? IDE에서 나타내주려나? 작게 Int 이렇게)
• 도구 지원: 정적 타입 지정을 활용하면 더 안전하게 리팩토링 가능. 도구는 더 정확한 코드 완성 기능을 제공할 수 있다. IDE의 다른 지원 기능도 더 잘 만들 수 있다.

널 가능한 타입과 불가능한 타입을 지원한다. 그래서 컴파일 시점에 널 포인트 예외가 발생할 수 있는 여부를 검사해 좀 더 프로그램의 신뢰성으르 높일 수 있다. 함수 타입이 무엇인가 알아보기 위해 함수형 프로그래밍이 어떤 개념인지와 코틀린이 함수형 프로그래밍을 어떻게 지원하는지를 알아야한다.

null이 있어서 유연하게 코드를 짤 수 있었던거 같은데 null safty 개념이 참 흥미롭네요.

함수형 프로그래밍과 객체지향 프로그래밍

함수형 프로그래밍의 핵심 개념

• 일급 시민인 ^first-class^ 함수: 함수(프로그램의 행동을 나타내는 코드 조각)를 일반 값처럼 다룰 수 있다. 함수를 변수에 저장할 수 있고, 함수를 인자로 다른 함수에 전달할 수 있으며, 함수에서 새로운 함수를 만들어서 반환할 수 있다.
• 불변성 ^immutability^ : 함수형 프로그래밍에서는 일단 만들어지고 나면 내부 상태가 절대로 바뀌지 않는 불변 객체를 사용해 프로그램을 작성한다.
• 부수 효과 ^side effeect^ 없음: 함수형 프로그래밍에서는 입력이 같으면 항상 같은 출려을 내놓고 다른 객체의 상태를 변경하지 않으며, 함수 외부나 다른 바깥 환경과 상호작용하지 않는 순수 함수 ^pure function^ 를 사용한다.

함수형 스타일 장점

1) 간결성 : 함수형 코드는 그에 상응하는 명령어 코드에 비해 더 간결하고 우아하다. 순수 함수를 값처럼 활용할 수 있으면 더 강력한 추상화를 할 수 있고 강력한 추상화를 사용해 코드 중복을 막을 수 있다. 비슷한 작업하는 비슷한 두 개의 코드 조각이 있다. 두 코드 조각은 일부 세부 사항에서 차이가 난다. 이 부분에서 공통 부분을 따로 함수로 뽑아내고 서로 다른 세부 사항을 인자로 전달할 수 있다. 하지만 람다식이라 불리는 무명함수 구문을 사용하면 간결하게 그런 함수를 표현할 수 있다.

fun findAlice() = findPerson { it.name == "Alice" } // findPerson에는 사람을 찾는 일반 로직이 들어가 있다.
fun findBob() = findPerson { it.name == "Bob" } // 중괄호 ({}) 사이에 있는 코드 블록은 찾으려는 사람을 인식한다.

2) 다중 스레드를 사용해도 안전 ^safe multithreading^하다. : 불변 데이터 구조를 사용하고 순수 함수를 그 데이터 구조에 적용한다면 다중 스레드 환경에서 같은 데이터를 여러 스레드가 변경할 수 없다. 따라서 복잡한 동기화가 필요없다. (논리적으로 모든 문제를 이렇게 해결할 수 있을까?? 동기화를 해서라도 같은 데이터에 접근해 처리해야한다던가.. 이러는편이 성능이 더 우수하다던가..)

3) 테스트하기 쉽다. (와! 코틀린 할래!!!): 부수 효과가 있는 함수는 그 함수를 실행할 때 필요한 전체 환경을 구성하는 준비 코드가 필요하지만, 순수함수는 그런 준비 코드 없이 독립적으로 테스트를 할 수 있다.

코틀린의 함수형을 위한 지원

• 함수 타입을 지원함에 따라 어떤 함수가 다른 함수를 파라미터로 받거나 함수가 새로운 함수를 반환할 수 있다.
• 람다 식을 지원함에 따라 번거로운 준비 코드를 작성하지 않아도 코드 블록을 쉽게 정의하고 여기저기 전달할 수 있다.
• 데이터 클래스는 불변적인 값 객체 ^value object^ 를 간편하게 만들 수 있는 구문을 제공한다.
• 코틀린 표준 라이브러리는 객체와 컬렉션을 함수형 스타일로 다룰 수 있는 API를 제공한다.

코틀린 응용

코틀린 서버 프로그래밍

• 브라우저에 HTML 페이지를 돌려주는 웹 애플리케이션
• 모바일 애플리케이션에게 HTTP를 통해 JSON API를 제공하는 백엔드 ^backed^ 애플리케이션
• RPC^원격 프로시져 호출^ 프로토콜을 통해 서로 통신하는 작은 서비스들로 이뤄진 마이크로서비스

코틀린은 기존 자바의 기능을 따르며 동시에, 몇 가지 새로운 기술을 활용해 서버 시스템을 개발할 수 있다. 코틀린의 빌더 패턴을 활용하면 간결한 구문을 사용해 객체로 이뤄진 그래프를 쉽게 구축하면서도 코틀린이 제공하는 완전한 추상화와 코드 재활용을 지속적으로 누릴 수 있다.

HTML 생성 라이브러리가 예이다

fun renderPersonList (persons: Collection<Person>) =
    createHTML().table {
        for (person in persons) {
            tr {
                td { +person.name }
                td { +person.age }
            }
        }
    }
}

HTML 페이지를 생성하면서코틀린 루프 등의 일반적인 코틀린 기능을 모두 활용할 수 있다.

코틀린이 제공하는 깔끔하고 간결한 DSL 기능을 활용할 수 있는 다른 예로는 영속성 프레임워크를 들 수 있다. 예를 들어 Exposed 프레임워크는 SQL 데이터베이스의 구조를 기술할 수 있는 읽기 쉬운 DSL을 제공하며, 코틀린 코드만을 사용해 완전한 타입 검사를 지원하면서 데이터베이스 질의를 실행할 수 있다.

object CountryTable : IdTable() { // 데이터베이스 테이블에 대해 기술한다.
    val name = varchar("name", 250).uniqueIndex()
    val iso = varchar("iso", 2).uniqueIndex()
}

class Country(id: EntityID) : Entity(id) { // 데이터베이스 엔티티에 해당하는 클래스를 만든다.
    var name: String by CountryTable.name
    var iso: String by CountryTable.sio
}

val russia = Country.find { // 오직 코틀린 코드만으로 이 데이터베이스에 질의를 던질 수 있다.
    CountryTable.iso.eq("ru")
}.first()

println(russia.name)

코틀린의 철학

실용성

큰 시스템에서 개발을 해온 전문가들이 실용적인 목적으로 만든 언어. 연구나 실험을 위한 언어도 아니라 그러한 복잡함을 늘릴 수 있는 요소는 없다. IDE 와의 호흡도 정말 좋다.

간결성

기본적으로 코드를 작성하는 시간보다 기존 코드를 읽어야하는 시간이 길어 그러니 간결성은 중요하다. 게터, 세터, 생성자 파라미터 같은 요소를 줄이기 위해 코틀린에서는 묵시적으로 제공한다. 그리고 코드가 불필요하게 길어지는 이유는 컬렉션에서 원소를 찾는 것과 같은 일반적인 작업을 수행하기 위해 명시적으로 작성해야만 하는 코드의 양이 상당하기 때문이다. 코틀린은 다양한 표준 라이브러리 제공해 반복되거나 길어지는 코드를 라이브러리 함수 호출로 대치한다. 코틀린은 람다를 지원해 작은 코드 블록으로 라이브러리 함수에 쉽게 전달할 수 있다.
따라서 일반적인 기능을 라이브러리 안에 캡슐화하고 작업에 따라 달라져야 하는 개별적인 내뇽을 사용자가 작성한 코드에 남겨둘 수 있다. 와우 이게 그 강력한? 완전한? 추상화의 예일까 엄청나다!!

안전성

PL에서 안전성이란 프로그램에서 발생할 수 있는 오류 중에서 일부 유형의 오류를 프로그램 설계가 원척적으로 방지해준다는 뜻이다. 절대적이지는 않지만! 안전성과 생산성은 트레이드오프 관계! 코틀린을 JVM에서 실행한다는 사실만으로 상당한 안전성을 보장한다. 메모리 안전성을 보장하고, 버퍼 오버플로우를 방지하며, 동적으로 할당한 메모리를 잘못 사용함으로 인해 발생할 수 있는 다양한 문제를 예방할 수 있다. 코틀린은 타입안전성을 보장한다. 자바보다 더 적은 비용을 사용한다. 컴파일러가 타입을 추론해줘 지정할 필요가 없으며 실행 시점에 오류를 발생시키는 대신 컴파일 시점에 검사로 방지한다. 무엇보다도 프로그램의 NullPointerException을 없애기 위해 노력한다. null이 될 수 없는 값을 추적하며, 실행 시점에 NullPointerException이 발생할 수 있는 연산을 사용하는 코드를 금지한다. 이로 인해 추가로 들어가는 비용은 미미하다. 널이 될 수 있는지 없는지는 타입 뒤 ? 유무

val s: String? = null // nullable!
val s2: String = "" // non nullable

추가로 Null이 될 수 있는 값을 다룰 수 있는 편리한 방법을 다양하게 제공한다.

코틀린이 방지해주는 다른 예외로는 ClassCastException이 있다. 어떤 객체를 다른 타입으로 캐스트하기 전에 타입을 미리 검사하지 않으면 ClassCastException이 발생할 수 있다. 자바에서 타입 검사화 그 직후 이뤄지는 타입 캐스트에서 같은 타입 이름을 반복 사용하는 것이 귀찮아서 생략하는 사람 많다. 반면 코틀린에서는 타입 검사와 캐스트가 한 연산자에 이뤄진다. 어떤 객체의 타입을 검사했고 그 객체가 그 타입에 속한다면 해당 타입의 메소드나 필드 등의 멤버를 별도의 캐스트 없이 사용할 수 있다. 따라서 타입 검사를 생략할 이유가 없고, 검사를 생략하지 않으면 검사를 생략해서 생기는 오류가 발생할 없다.(참 말 어렵다 이중 부정 느낌)

if (value is String) // 타입을 검사한다.
    println(value.toUpperCase()) // 해당 타입의 메소드를 사용한다.

상호운용성

자바와 혼용해서 사용할 수 있으며 자바의 라이브러리를 최대한 활용한다. 기존 컬렉션을 더 쉽게 활용할 수 있게 몇 가지 기능을 더한다. 코틀린에서 자바 API를 호출할 때 객체를 감싸거나 변환할 필요가 없고, 자바에서 코틀린 API를 호출할 때도 아무런 변환이 필요 없다. 코틀린이 제공하는 풍부한 API는 실행시점에 아무런 부가 비용을 야기하지 않는다. 어떻게 이럴 수 있지!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

코틀린이 제공하는 도구도 강력하다.

• 자바와 코틀린 소스 파일을 자유롭게 내비게이션
• 여러 언어로 이뤄진 프로젝트를 디버깅하고 서로 다른 언어로 작성된 코드를 언어와 관계없이 한 단계씩 실행할 수 있다.
• 자바 메소드를 리팩토링해도 메소드와 관련된 코틀린 코드까지 제대로 변경된다. 역도 성립한다.

어떻게 이럴 수 있는거야!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

코틀린 도구 사용

코틀린 코드 컴파일

소스코드 저장 시 .kt 확장자를 쓴다. 코틀린 컴파일러는 자바 컴파일러가 자바처럼 코틀린 소스코드 분석해 .class 파일을 만든다. 만들어질 .class 파일은 개발 중인 애플리케이션의 유형에 맞는 표준 패키징 과자ㅓㅇ을 거쳐 실해오딜 수 있다.

컴파일
kotlinc <소스파일 또는 디렉터리> -icnlude-runtime -d <jar 이름>

실행
java -jar <jar 이름>

컴파일만 거치면 자바든 코틀린이든 .class (자바 바이트코드)가 된다. 이게 상호운용의 핵심인가?.

코틀린 컴파일러로 컴파일한 코드는 코틀린 런타임 라이브러리에 의존한다. 런타임 라이브러리에는 콜린 자체 표준 라이브러리 클래스와 콜린에서 자바 API의 기능을 확장한 내용이 있다. 코틀린으로 컴파일한 애플리케이션을 배포할 때는 런타임 라이브러리도 함께 배포해야한다.

실제 개발 시 프로젝트 컴파일 위해 메이븐, 그레이드 앤트 등의 빌드 시스템을 사용한다. 콜린도 그런 빌드 시스템과 호환된다.

인텔리J 아이디어와 안드로이드 스튜디오의 콜린 플러그인

둘이 정말 잘 맞다. 꼭 같이 써보자

대화형 셀

코드 빨리 시험해보고 싶으면 대화형 셀 사용해라. 대화형 셀을 REPL(입력을 받아 값을 계산한 다음 ㅁ결과 값을 출력하는 루프라는 뜻의 read-eval-print loop의약자)잉라 부른다. 코틀린 코드 한 줄 입력하면 즉시 그 코드를 실행한 결과를 볼 수 있다. REPL 시작하려면 콜린컴파일러 명령을 아무 인자 없이 실행하거나 인텔리j 아이디어 플러그인의 메뉴에서 사용하면 된다.

요약으로 마무리!

• 코틀린은 타입 추론을 지원하느 ㄴ정적 타입 지정 언어. 소스코드의 정확성과 성능을 보장하면서 소스코드를 간결하게 유지한다.
• 코틀린은 객체지향과 함수형 프로그래밍 스타일을 모두 지원한다. 코틀린에서는 일급 시민 함수를 사용해 수준 높은 추상화가 가능하고, 불변 값 지원을 통해 다중 스레드 애플리케이션 개발과 테스트를 더 쉽게 할 수 있다.
• 코틀린을 서버 애플리케이션 개발에 잘 활용할 수 있다. 코틀린은 기존 자바 프레임워크를 완벽하게 지원하는 한 편, 새로운 도구를 제공한다.
• 코틀린은 안드로이드에도 활용 가능하다. 코틀린 런타임 라이브러리는 크기가 작고, 코틀린 컴파일러는 안드로이드 API를 특별히 지원한다.
• 코틀린은 무료! 오픈소스!, 주요 IDE, 빌드 시스템을 완전 지원!
• 실용적이며 안전하고, 간결하며 상호운용성이 좋다. 이는 이미 잘 알려진 해법을 채택하고 NullPoEX 같은 흔히 발생하는 오류를 방지하며, 읽기 쉽고 간결한 코드를 지원하면서 자바와 아무런 제약 없이 통합될 수 있는 언어를 만들기에 초점을 뒀다.