이동식 저장소

상한 (Upper bound) 다음과 같이 ``List``의 확장 함수를 선언했다. fun List.sum() = ... 이때 ``T``는 모든 타입이 될 수 있다. 그러나 ``List.sum``은 수를 저장한 리스트에 대해서만 실행되어야 한다. 그러니까 ``T``의 타입을 제한해야 한다는 말이다. Kotlin에는 모든 수(number) 타입의 부모 클래스 ``Number``가 존재한다.따라서 ``Number`` 또는 그 하위 클래스를 담은 리스트만 sum 함수를 실행할 수 있게 해야 한다. 다음과 같이 선언하면 된다. fun List.sum() = ... 이렇게 하면 ``Number`` 또는 ``Number``의 하위 타입만 ``T``가 될 수 있다. 이처럼 Kotlin에서는 제네릭 타입의 상한(upp..

Boolean AND 연산을 &&로 하는 사람이 대부분이겠지만, 간혹 ``and`` 함수를 사용하는 사람도 있다. 예를 들어 다음 두 코드의 출력값은 같다. println(true and false) println(true && false) 그렇다면 &&와 ``and`` 중 무엇이 올바른 표현인가? &&가 맞다 사실 ``and`` 함수는 Boolean 값을 비교하는 연산자가 아니다. ``and`` 함수는 비트 연산 AND를 구현하는 함수이다. 그래서 ``and`` 함수로 3개 이상의 Boolean 값을 연산할 수 없다. 2개의 Boolean을 연산할 때는 &&와 같은 결과값을 반환하지만, 코드의 의미를 혼란스럽게 할 수 있으므로 웬만하면 &&를 사용하자. 참고: Kotlinlang - Bitwise op..

일반적인 for문과 ``Collections.forEach()`` 중 뭘 써야 하나요? JetBrains의 Kotlin 개발자들이 쓴 Kotlin in Action에 이런 구절이 있다. The forEach function is somewhat more concise than a regular for loop, but it doesn’t have many other advantages, so you needn’t rush to convert all your loops to lambdas. 요약하면 ``forEach``가 읽기 쉬운 건 맞지만, for문을 모두 바꿔야 할 만큼 명확한 이점이 있는 것은 아니라고 한다. 각자 편한 걸 쓰는 걸로.

가위바위보에서 낼 수 있는 선택지는 가위, 바위, 보 3개뿐이다. 따라서 가위바위보의 참가자들은 다른 선택지를 내지 말아야 한다. 현실에서는 상대방의 강력한 항의와 눈초리를 통해 제한되지만, 프로그래밍에서도 그렇게 강제할 수 있을까? interface RSPOption class Rock: RSPOption class Scissors: RSPOption class Paper: RSPOption // 이건 반칙이다 class Gun: RSPOption 짖궂은 개발자가 가위바위보에 ``Gun``을 추가하지 못하도록 막을 수 있는 방법이 없을까? 있으니까 글을 썼겠지? sealed class Kotlin의 sealed class를 사용하면 외부 개발자가 상속할 수 없는 상위 타입을 만들 수 있다. sealed..

Kotlin에서도 클래스 안에 다른 클래스를 정의할 수 있다. 특정 외부 클래스에 종속된 클래스를 외부로부터 숨기고자 할 때 유용하다. 그러나 Kotlin의 내부 클래스는 기본적으로 외부 클래스의 멤버에 접근할 수 없다. 예시를 하나 들어 보겠다. ``View``를 상속하여 커스텀 뷰를 만들려 한다. 이때 ``View``를 직렬화(serialize) 가능하게 만든다고 생각해 보자. 뷰 자체를 직렬화하기는 쉽지 않지만, 대신 뷰가 가지고 있는 데이터를 직렬화하면 된다. 뷰의 데이터를 담는 일반적인 객체를 정의하기 위해 ``Serializable``을 구현하는 ``State`` 인터페이스를 정의하자. interface State: Serializable interface View { fun getState(..