TIL

아이템 16 프로퍼티는 동작이 아니라 상태를 나타내야 한다

• 코틀린 프로퍼티는 자바 필드와 비슷해 보이지만 사실 완전 다르다.
• 프로퍼티엔 더 많은 기능이 있다.
  • 기본적으로 사용자 정의 세터, 게터를 가질 수 있다.

var name: String? = null
	get() = field?.toUpperCase()
	set(value) {
		if (!value.isNullOrBlank()) {
			field = value
		}
	}

• 위 코드에서 field는 프로퍼티의 데이터를 저장해 두는 백킹 필드(backing field)에 대한 레퍼런스다.
  • 세터와 게터의 디폴트 구현에 사용되기에 따로 만들지 않아도 된다.
  • val로 읽기 전용 프로퍼티를 만들 땐 field가 만들어지지 않는다.
• 코틀린 프로퍼티는 디폴트로 캡슐화 되어 있기에 내부 데이터 타입 변경에 유연하게 대처 가능하다.
  • ex) 아래 코드는 Date 타입이었던 프로퍼티가 mills라는 별도 프로퍼티로 리팩터링된 경우, 외부에 date 프로퍼티를 참조하는 다른 코드들에 대응하는 예제

var date: Date
	get() = Date(mills)
	set(value) {
		mills = value.time
	}

• 이처럼 프로퍼티엔 필드가 없고 개념적으로 접근자를 나타내기에 인터페이스에도 프로퍼티를 정의할 수 있다.

interface Person {
	val name: String
}

• 프로퍼티는 본질적으로 함수이기에 확장 프로퍼티를 만들 수도 있다.

val Context.preferences: SharedPreferences
	get() = PreferenceManager.getDefaultSharedPreferences(this)

• 프로퍼티를 함수 대신 사용할 수 있지만 그렇다고 완전 대체하는 것은 좋지 않다.
  • 아래 코드처럼 알고리즘의 동작을 프로퍼티로 처리하지 않길 바란다.
  • 보통 프로퍼티(getter)에 많은 계산량이 필요하지 않다고 생각하지만 아래 코드는 큰 컬렉션의 경우 많은 계산이 필요하게 된다.
  • 따라서 이러한 처리는 함수로 구현해야 한다.

val Tree<Int>.sum: Int
	get() = when(this) {
		is Leaf -> value
		is Node -> left.sum + right.sum
	}

• 프로퍼티 대신 함수를 사용하는 것이 좋은 경우
  • 연산 비용이 높거나 복잡도가 O(1)보다 큰 경우
  • 비즈니스 로직을 포함하는 경우
  • 결정적이지 않은 경우
  • 변환의 경우
  • 게터에서 프로퍼티 상태 변경이 일어나야 하는 경우
• 많은 사람들이 경험적으로 프로퍼티는 상태 집합을, 함수는 행동을 나타낸다고 생각한다.