KotlinInAction/밑줄긋기 (rev. 1.17)
1. 코틀린 소개 ¶
- p35
- 코틀린은 간결하고 실용적이며, 자바 코드와의 상호운용성을 중시한다.
- p37
- 코틀린의 주목적은 현재 자바가 사용되고 있는 모든 용도에 적합하면서도 더 간결하고 생산적이며 안전한 대체 언어를 제공하는 것이다.
- p38 ~ p39
- 코틀린은 정적 타입 지정 언어다. 모든 프로그램 구성 요소의 타입을 컴파일 시점에 알 수 있고 프로그램 안에서 객체의 필드나 메서드를 사용할 떄마다 컴파일러가 타입을 검증해준다는 뜻이다.
- 대부분의 경우 코틀린 컴파일러가 문맥으로부터 변수 타입을 자동으로 유추할 수 있다.(타입 추론 기능)
- p41
- 불변 데이터 구조를 사용하고 순수 함수를 그 데이터 구조에 적용한다면 다중 스레드 환경에서 같은 데이터를 여러 스레드가 변경할 수 없다. 따라서 복잡한 동기화를 사용하지 않아도 된다. (!!)
- p46
- 흔한 안드로이드 개발 작업을 훨씬 더 적은 코드로 작성할 수 있고, 때로는 전혀 코드를 작성하지 않고 그렇게 할 수도 있다.
- 개발할 때마다 리스너 덕지덕지 붙어 있는 게 마음에 안 들었는데 코틀린은 좀 다르려나 - 김은솔
- 코틀린 타입 시스템은 null 값을 정확히 추적하며 널 포인터로 인해 생기는 문제를 줄여준다.
- 제일 기대하고 있는 기능... - 김은솔
- 현실은 자바 라이브러리 가져다가 쓸때 nullable한 타입(String?같은)으로 떡칠되어있어서 고통 받을 것 같다는 생각.. sound null safety한 코틀린은 이 문제를 해결했지만 자바는 아니기 때문에 오히려 더 심연으로 빠지는 경우도 많을 것 같아 ㅋㅋㅋ- 정우현
- 아 그런 문제가ㅠ - 김은솔
- p49
- 게터, 세터, 생성자 파라미터를 필드에 대입하기 위한 로직 등 자바에 존재하는 여러 가지 번거로운 준비 코드를 코틀린은 묵시적으로 제공한다.
- 인터페이스 제공 vs 코드가 길어지는 번거로운 준비 / 둘 다 각각 지향하는 방향이 다른 것 같다. - 김은솔
- p51
- 어떤 객체의 타입을 검사했고 그 객체가 그 타입에 속한다면 해당 타입의 메서드나 필드 등의 멤버를 별도의 캐스트 없이 사용할 수 있다.
- p53
2. 코틀린 기초 ¶
- p60
- 함수를 선언할 때 fun 키워드를 사용한다. 실제로도 코틀린 프로그래밍은 수많은 fun을 만드는 재미있는 (...) 일이다!
- p61
- 함수를 최상위 수준에 정의할 수 있다. 꼭 클래스 안에 함수를 넣어야 할 필요가 없다.
- System.out.println 대신에 println이라고 쓴다.
- 이 부분 마음에 든다. 자바에서의 표준 입출력 함수는 최소지식원칙을 어기게 한다. 그러나 이렇게 변경된 println은 어느 객체에서 호출된 함수인지 노출되지 않기 때문에 그러한 문제를 마주치지 않게 해준다. 코틀린.. 벌써부터 재미있는데..? ㅋㅋㅋ - 정우현
- p62
- 자바에서는 모든 제어 구조가 문인 반면 코틀린에서는 루프를 제외한 대부분의 제어구조가 식이다.
- p65
- 초기화 식을 사용하지 않고 변수를 선언하려면 변수 타입을 반드시 명시해야 한다.
- p66
- 변경 불가능한 참조와 변경 불가능한 객체를 부수 효과가 없는 함수와 조합해 사용하면 코드가 함수형 코드에 가까워진다.
- val 참조 자체는 불변일지라도 그 참조가 가리키는 객체의 내부 값은 변경될 수 있다.
- var 키워드를 사용하면 변수의 값을 변경할 수 있지만 변수의 타입은 고정돼 바뀌지 않는다.
- p67
- 문자열 템플릿을 사용할때는 리터럴 스트링 안에서 $<변수명>을 사용하면 된다.
- 낯선 곳에서 익숙한 언어의 느낌이 난다. 이 문법은 PHP의 리터럴 스트링 사용법과 같다. 개인적으로는 변수명을 brace로 감싸준 언어들이 더 보기 좋은 것 같다. ㅋㅋㅋ - 정우현
- p71
- 클래스에서 프로퍼티를 선언할 때는 앞에서 살펴본 변수를 선언하는 방법과 마찬가지로 val이나 var를 사용한다. (val이 읽기 전용, var이 변경 가능)
- p72
- 이름이 is로 시작하는 프로퍼티의 게터에는 get이 붙지 않고 원래 이름을 그대로 사용하며, 세터에는 is를 set으로 바꾼 이름을 사용한다.
- 따로 이유가 있지는 않은 것 같다. - 김은솔
- 관용적인 이유때문에 그런 것 같습니다. uhyeon이라는 객체에서 uhyeon.isMarried()를 호출하는건 자바 개발자들한테 자연스러운 일이지만, uhyeon.getIsMarried()같은 메소드를 호출하는 건 부자연스러운 일인 것 같거든요.
- p75
- 코틀린에서는 클래스 임포트와 함수 임포트에 차이가 없으며, 모든 선언을 import 키워드로 가져올 수 있다.
- p76
- 코틀린에서는 여러 클래스를 한 파일에 넣을 수 있고, 파일의 이름도 마음대로 정할 수 있다. 코틀린에서는 디스크상의 어느 디렉터리에 소스코드 파일을 위치시키든 관계없다.
- 하지만 여러 클래스를 한 파일에 넣는 것을 주저해서는 안 된다.
- 자바 방식이랑 다른 점이 꽤 있는 듯 - 김은솔
- p79
- (when은) 자바와 달리 각 분기의 끝에 break를 넣지 않아도 된다.
- 개인적으로 강력한 기능이라고 생각함 - 김은솔
- 이 부분 찾아보니까 자바 SE13에서부터 거의 동일하게 지원해주네요 - 정우현
- p82
- when에 아무 인자도 없으려면 각 분기의 조건이 boolean 결과를 계산하는 식이어야 한다.
- p85
- 코틀린에서는 is를 통해서 검사하고 나면 변수를 타입캐스팅하지 않아도, 원하는 타입으로 캐스팅을 수행해준다. 이것은 스마트 캐스팅이라고 불린다.
- 이부분은 항상 형변환에 시달리던 개발자들에게 숨통을 트이게 해주는 특성이라고 생각한다. 타입 검사후에는 이미 확신을 얻게 되는 경우가 많은데, (분기처리를 통해서 원하는 경우가 아니면 해당 코드로 애초에 가지 않을것) 일일히 타입검사를 하는 자바 특성상 항상 형변환을 하면서 지낼 수 밖에 없었다. 그런데, 스마트캐스팅 덕분에 반복되던 작업이 사라졌으니 참 좋다 - 정우현
- p94
- c in "a".."z" 같은 range와 in을 통한 검사는 컴파일시 'a' <= c && c <= 'z'로 변환된다.
- 이런 부분 기억해두면 좋을 것 같다. 내부 동작 원리.. - 정우현
- 그런데.. 이 range 문 그러면 컴파일될때 for in 문에서와는 다르게 동작하는거네 - 정우현
- p98
- 자바는 체크 예외 처리를 강제한다. 하지만 프로그래머들이 의미없이 예외를 다시 던지거나, 예외를 잡되 처리하지는 않고 그냥 무시하는 코드를 작성하는 경우가 흔하다.
3. 함수 정의와 호출 ¶
- p104
- 코틀린은 자신만의 컬렉션 기능을 제공하지 않는다. 자체 컬렉션을 제공하지 않고 표준 자바 컬렉션과 상호작용하면, 자바코드와 소통하기 쉽기 때문이다. 하지만 코틀린에서는 자바 컬렉션에서보다 더 풍부한 기능을 제공해준다.
