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
- 코틀린은 자신만의 컬렉션 기능을 제공하지 않는다. 자체 컬렉션을 제공하지 않고 표준 자바 컬렉션과 상호작용하면, 자바코드와 소통하기 쉽기 때문이다. 하지만 코틀린에서는 자바 컬렉션에서보다 더 풍부한 기능을 제공해준다.
- p108
- 자바로 작성한 코드를 호출할 때는 이름 붙인 인자를 사용할 수 없다.
- p109
- 코틀린에서는 함수 선언에서 파라미터의 디폴트 값을 지정할 수 있으므로 이런 오버로드 중 상당수를 피할 수 있다.
- p112
- 코틀린 파일의 모든 최상위 함수는 이 클래스의 정적인 메서드가 된다.
- p116
- 확장 함수가 캡슐화를 깨지는 않는다는 사실을 기억하라. 클래스 안에서 정의한 메서드와 달리 확장 함수 안에서는 클래스 내부에서만 사용할 수 있는 비공개 멤버나 보호된 멤버를 사용할 수 없다.
- p117
- 코틀린 문법상 확장 함수는 반드시 짧은 이름을 써야 한다. 따라서 임포트할 때 이름을 바꾸는 것이 확장 함수 이름 충돌을 해결할 수 있는 유일한 방법이다.
- 어떻게 해결하나 했더니 이름을 다르게 사용하는 방법을 사용했군 - 김은솔
- p121
- 확장 함수는 클래스의 일부가 아니다. 확장 함수는 클래스 밖에 선언된다.
- 확장 함수를 호출할 떄 수신 객체로 지정한 변수의 정적 타입에 의해 어떤 확장 함수가 호출될지 결정되지, 그 변수에 저장된 객체의 동적인 타입에 의해 확장함수가 결정되지 않는다.
- p129
- split의 구분 문자열은 실제로는 정규식이기 때문이다.
- p130
- 코틀린에서는 split 함수에 전달하는 값의 타입에 따라 정규식이나 일반 텍스트 중 어느 것으로 문자열을 분리하는지 쉽게 알 수 있다.
- p139
- 일반적으로는 한 단계만 함수를 중첩시키라고 권장한다.
- 코틀린은 함수 중첩을 오히려 권장한다는게 신기하네 - 김은솔
4. 클래스, 객체, 인터페이스 ¶
- p141
- 자바와 달리 코틀린 선언은 기본적으로 final이며 public이다.
- p144
- 하지만 자바와 달리 코틀린에서는 override 변경자를 꼭 사용해야 한다.
- p145
- 코틀린 컴파일러는 두 메서드를 아우르는 구현을 하위 클래스에 직접 구현하게 강제한다.
- 이름과 시그니처가 같은 멤버 메서드에 대해 둘 이상의 디폴트 구현이 있는 경우 인터페이스를 구현하는 하위 클래스에서 명시적으로 새로운 구현을 제공해야 한다.
- 인터페이스 구현을 상속이라고 이야기하는 부분 킹받네요 - 정우현
- p147
- 어떤 클래스가 자신을 상속하는 방법에 대해 정확한 규칙을 제공하지 않는다면 그 클래스의 클라이언트는 기반 클래스를 작성한 사람의 의도와 다른 방식으로 메서드를 오버라이드할 위험이 있다.
- 어떤 클래스의 상속을 허용하려면 클래스 앞에 open 변경자를 붙여야 한다.
- 오버라이드한 메서드는 기본적으로 열려있다.
- 애초에 오버라이드를 할 수 있다는 건 열려있는 메서드라는 뜻이다 - 김은솔
- p148
- 추상 멤버는 항상 열려있다. 따라서 추상 멤버 앞에 open 변경자를 명시할 필요가 없다.
- p150
- 아무 변경자도 없는 경우 선언은 모두 공개된다.
- 자바의 기본 가시성인 패키지 전용은 코틀린에 없다. 코틀린은 패키지를 네임스페이스를 관리하기 위한 용도로만 사용한다.
- 패키지 전용 가시성에 대한 대안으로 코틀린에는 internal이라는 새로운 가시성 변경자를 도입했다.
- 모듈 내부 가시성은 여러분의 모듈의 구현에 대해 진정한 캡슐화를 제공한다는 장점이 있다.
- p151
- 자바에서는 같은 패키지 안에서 protected 멤버에 접근할 수 있지만, 코틀린에서는 그렇지 않다는 점에서 자바와 코틀린의 protected가 다르다는 사실에 유의하라.
- p153
- 자바와의 차이는 코틀린의 중첩 클래스는 명시적으로 요청하지 않는 한 바깥쪽 클래스 인스턴스에 대한 접근 권한이 없다는 점이다.
- p156
- 클래스 계층을 만들되 그 계층에 속한 클래스의 수를 제한하고 싶은 경우 중첩 클래스를 쓰면 편리하다.
- p157
- sealed로 표시된 클래스는 자동으로 open임을 기억하라.
- p159
- 클래스 이름 뒤에 오는 괄호로 둘러싸인 코드를 주 생성자라고 부른다.
- 주 생성자는 제한적이기 때문에 별도의 코드를 포함할 수 없으므로 초기화 블록이 필요하다.
- p160
- 프로퍼티를 초기화하는 식이나 초기화 블록 안에서만 주 생성자의 파라미터를 참조할 수 있다는 점에 유의하라.
- 함수 파라미터와 마찬가지로 생성자 파라미터에도 디폴트 값을 정의할 수 있다.
- p162
- 어떤 클래스를 클래스 외부에서 인스턴스화하지 못하게 막고 싶다면 모든 생성자를 private으로 만들면 된다.
- p165
- 클래스에 주 생성자가 없다면 모든 부 생성자는 반드시 상위 클래스를 초기화하거나 다른 생성자에게 생성을 위임해야 한다.
- 부 생성자가 필요한 주된 이유는 자바 상호운용성이다.
- p166
- 코틀린에서는 인터페이스에 추상 프로퍼티 선언을 넣을 수 있다.
- 인터페이스에 있는 프로퍼티 선언에는 뒷받침하는 필드나 게터 등의 정보가 들어있지 않다.
- p169
- 클래스의 프로퍼티를 사용하는 쪽에서 프로퍼티를 읽는 방법이나 쓰는 방법은 뒷받침하는 필드의 유무와는 관계가 없다.
- p170
- 접근자의 가시성은 기본적으로는 프로퍼티의 가시성과 같다. 하지만 원한다면 get이나 set 앞에 가시성 변경자를 추가해서 접근자의 가시성을 변경할 수 있다.
- p174
- 자바의 equals를 ==, ==는 ===로 비교한다. 전자는 내부의 데이터에 대한 비교, 후자는 참조에 대한 비교이다.
- 코틀린의 is 검사는 자바의 instanceof와 같다.
- p175
- hashCode는 hashSet과 같은 컬렉션을 위해서 필요하다.
- p176
- 어떤 클래스가 데이터를 저장하는 역할만을 수행한다면 toString, equals, hashCode를 반드시 오버라이드해야 한다.
- p177
- 데이터 클래스의 모든 프로퍼티를 읽기 전용으로 만들어서 데이터 클래스를 불변 클래스로 만들라고 권장한다.
- 불변 객체를 사용하면 프로그램에 대해 훨씬 쉽게 추론할 수 있다.
- 객체를 메모리상에서 직접 바꾸는 대신 복사본을 만드는 편이 더 낫다.
- p178
- 종종 상속을 허용하지 않는 클래스에 새로운 동작을 추가해야 할 때가 있다. 이럴 때 사용하는 일반적인 방법이 데코레이터 패턴이다.
- p180
- 메서드 중 일부의 동작을 변경하고 싶은 경우 메서드를 오버라이드하면 컴파일러가 생성한 메서드 대신 오버라이드한 메서드가 쓰인다.
- p181
- 동반 객체는 인스턴스 메서드는 아니지만 어떤 클래스와 관련 있는 메서드와 팩토리 메서드를 담을 때 쓰인다.
- p188
- 동반객체는 클래스안에 정의된 일반 객체다. 따라서 이름을 붙이거나 인터페이스를 구현하거나, 확장함수, 프로퍼티를 내부에 정의할 수 있다.
