![[Kotlin Docs] Properties](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FdvMRlz%2Fbtrsc0UyxYR%2F35PbqdbLRBS9d1klVFJexK%2Fimg.png)
본 글은 https://kotlinlang.org/docs/home.html 를 기반으로 작성자 마음대로 번역한 글입니다.
오역 & 의역이 빈번하며 모든 질문 및 태클 환영합니다!
2022-02-03 기준으로 작성되었습니다.
Declaring properties
코틀린 클래스의 프로퍼티는 var 키워드로 수정 가능하거나, val 키워드를 사용하여 읽기 전용으로 선언할 수 있습니다.
프로퍼티를 사용하기 위해서는 이름으로 참조하기만 하면 됩니다.
Getters and setters
프로퍼티를 선언하는 전체 구문은 다음과 같습니다:
초기화, getter, setter는 선택사항입니다. 프로퍼티 타입은 아래와 같이 이니셜라이저나 getter의 리턴 타입에서 유추할 수 있는 경우 선택사항입니다.
읽기 전용 프로퍼티 선언의 전체 구문은 수정가능한 프로퍼티와 두가지가 다릅니다: var 대신 val로 시작하며 setter를 허용하지 않습니다.
프로퍼티에 대한 커스텁 접근자를 정의할 수 있습니다. 만약 커스텀 getter를 정의한다면, 프로퍼티에 접근할 때마다 호출될 것입니다(이 방식으로 계산된 프로퍼티를 구현할 수 있습니다). 다음은 커스텀 getter의 예시입니다.
getter로부터 추론할 수 있는 경우 프로퍼티 타입을 생략할 수 있습니다.
커스텀 setter를 정의한다면, 초기화를 제외하고 프로퍼티에 값이 할당될 때마다 호출됩니다. 커스텀 setter는 다음과 같습니다.
일반적으로 setter 파라미터의 이름은 value이지만, 다른 이름을 선택할 수 있습니다.
접근자에 어노테이션을 붙이거나 가시성을 변경해야하지만, 기본 구현을 변경할 필요가 없는 경우에는 바디를 정의할 필요 없이 접근자를 정의할 수 있습니다.
- Backing fields
코틀린에서는, 해당 값을 메모리에 유지하는 프로퍼티의 일부로만 사용됩니다. 필드는 직접적으로 선언될 수 없습니다. 그러나, 프로퍼티에 backing field가 필요한 경우 코틀린은 자동으로 제공합니다. backing field는 field 식별자를 사용하여 접근자에서 참조될 수 있습니다.
field 식별자는 프로퍼티의 접근자에서만 사용될 수 있습니다.
프로퍼티가 적어도 하나의 접근자에서 기본 구현을 사용하거나, 커스텀 접근자가 field 식별자를 통해서 참조하고 있는 경우, backing field는 자동으로 생성됩니다.
예를 들어, 다음과 같은 경우에는 backing field가 존재하지 않습니다.
- Backing properties
implcit backing field 스키마에 맞지 않는 작업을 수행할 경우 항상 backing property를 갖는 것으로 대체될 수 있습니다:
On the JVM : 기본 getter와 setter를 사용한 private 프로퍼티의 접근은 함수 호출 오버헤드를 피하기 위해 최적화되었습니다.
Compile-time constants
읽기 전용 프로퍼티의 값이 컴파일 타임에 알려진다면, const 지시자를 사용하여 compile time constant라는 것을 표기하세요. 이러한 프로퍼티는 다음과 같은 사항을 충족해야합니다.
- top-level 프로퍼티이거나, object declaration↗ 혹은 companion object↗의 멤버여야합니다.
- String이나 원시 타입의 값으로 초기화되어야합니다.
- 커스텀 getter를 가질 수 없습니다.
컴파일러는 상수의 사용을 inline하여 상수에 대한 참조를 실제 값으로 변경시킵니다. 그러나, 필드는 제거되지 않으므로 reflection↗을 사용하여 조작할 수 있습니다.
이러한 프로퍼티들은 어노테이션에서도 사용될 수 있습니다.
Late-initialized properties and variables
일반적으로 non-null 타입을 갖도록 선언된 프로퍼티는 반드시 생성자에서 초기화되어야합니다.
그러나, 이러한 상황은 자주 불편할 수 있습니다. 예를 들어, 의존성 주입으로 초기화된 프로퍼티나 유닛 테스트의 setup 메소드가 있습니다. 이러한 경우, 생성자에서의 non-null 초기화를 사용할 수 없지만 여전히 클래스의 바디안에서 프로퍼티를 참조할 때 null 체크를 피하고 싶을 것입니다.
이러한 상황을 해결하기 위해 lateinit 지시자로 프로퍼티에 표시할 수 있습니다.
이 지시자는 클래스의 바디 내부에 선언된 var 프로퍼티 (기본 생성자가 아니며 프로퍼티가 커스텀 getter, setter를 가지지 않는 경우) , 최상위 프로퍼티와 지역 변수에서 사용될 수 있습니다. 프로퍼티나 변수의 타입은 non-null이여야 하며 기본 타입이여야합니다.
초기화 되지 않은 lateinit 프로퍼티로의 접근은 초기화되지 않은 프로퍼티로의 접근이라는 것을 명시하는 특별한 예외를 발생시킵니다.
- Checking whether a lateinit var is initialized
lateinit var이 이미 초기화 되었는지 확인하기 위해서, 프로퍼티를 참조↗하는 .isInitialized를 사용하면 됩니다.
동일한 타입이나 외부타입, 같은 파일에서의 최상위로 선언될 때, 프로퍼티에 사전적으로 접근이 가능한지만 확인해줍니다.
Overriding properties
Delegated properties
가장 일반적인 유형의 프로퍼티는 backing field로 부터 읽을 수(경우에 따라 쓸 수) 있습니다, 그러나 커스텀 getter와 setter를 사용하면 프로퍼티를 사용하여 모든 종류의 동작을 구현할 수 있습니다. 첫번째 유형의 단순성과 두번째의 다양상 사이에 프로퍼티가 수행할 수 있는 일반적인 패턴이 있습니다. 몇가지 예 : lazy 값, 주어진 키로 맵에서 읽기, 데이터베이스에 접근, 접근 시 listener에 알림.
이러한 일반적인 동작은 delegated properties↗를 사용하여 라이브러리로 구현될 수 있습니다.
https://kotlinlang.org/docs/properties.html
Properties | Kotlin
kotlinlang.org
'Kotlin > Docs' 카테고리의 다른 글
| [Kotlin Docs] Functional (SAM) interfaces (0) | 2022.02.17 |
|---|---|
| [Kotlin Docs] Interfaces (0) | 2022.02.04 |
| [Kotlin Docs] Inheritance (0) | 2022.01.24 |
| [Kotlin Docs] Classes (0) | 2022.01.24 |
| [Kotlin Docs] Packages and imports (0) | 2022.01.20 |