TIL

아이템 1 가변성을 제한하라

코틀린은 모듈로 프로그램을 설계한다.
- 클래스, 객체, 함수, 타입 별칭, 톱레벨 프로퍼티 등
- 모듈 중 일부는 상태를 가질 수 있다.
  - var 또는 mutable 객체 사용
상태를 적절하게 관리하는 것은 꽤 어렵다.
- 디버깅이 힘들다. 상태 변경이 많으면 이를 추적하기가 까다롭고 예상치 못한 상태 변화는 큰 문제가 된다.
- 가변성이 있으면 코드 실행을 추론하기가 어려워진다.
- 멀티스레드 프로그램일 때는 적절한 동기화가 필요하다.
- 모든 상태를 테스트해야 하므로 테스트하기 어렵다.
- 상태 변경 시 이러한 변경을 다른 부분에 알려야 하는 경우가 있다.
가변성의 단점 때문에 이를 완전하게 제한하는 언어가 바로 순수 함수형 언어이다.
- 하지만 가변성에 너무 많은 제한이 걸려 있어 프로그램 작성하기가 굉장히 어렵다.

코틀린에서 가변성 제한하기

읽기 전용 프로퍼티 (val)

val을 사용해 읽기 전용 프로퍼티를 만들면 일반적인 방법으로는 값이 변하지 않는다.
다만 읽기 전용 프로퍼티가 mutable 객체를 담고 있다면 내부적으로 변할 수 있다.

val list = mutableListOf(1, 2, 3)

val 프로퍼티는 값이 변경될 수 있긴 하지만 프로퍼티 레퍼런스 자체를 변경할 수 없어 동기화 문제를 줄일 수 있다.
읽기 전용 프로퍼티는 사용자 정의 게터로도 정의할 수 있다.
- var 프로퍼티를 사용하는 val 프로퍼티는 var 프로퍼티가 변할 때 변할 수 있다.

var name: String = "Marcin"
var surname: String = "Moskaja"
val fullname 
	get() = "$name $surname"

코틀린 프로퍼티는 기본적으로 캡슐화되어 있다.
- 사용자 정의 게터와 세터까지 가질 수 있다.
- 때문에 API를 변경하거나 정의할 때 굉장히 유연하다.
val는 읽기 전용이지만, 불변을 의미하는 것은 아니다.
- 또한 이는 게터 또는 델리게이트(delegate)로 정의할 수도 있다.
- 만약 완전 변경이 필요 없다면 final 프로퍼티를 사용하는 것이 좋다.
val는 정의 옆에 상태가 바로 적히므로 코드 실행을 예측하는 것이 쉽고 스마트 캐스트 등의 추가 기능을 활용할 수 있다.

가변 컬렉션과 읽기 전용 컬렉션 구분하기

코틀린에선 컬렉션도 가변과 불변으로 나뉜다.
- Iterable, Collection, Set, List 인터페이스는 읽기 전용 컬렉션
- MutableIterable, MutableCollection, MutableSet, MutableList 인터페이스는 읽고 쓸 수 있는 컬렉션
- mutable이 붙은 인터페이스는 읽기 전용 인터페이스를 상속 받아 변경을 위한 메서드를 추가한 것 뿐이다.
읽기 전용 컬렉션이 내부 값을 변경할 수 없는 것은 아니지만 읽기 전용 인터페이스가 이를 지원하지 않기에 불변인 것이다.
- ex) Iterable<T>.map과 .filter 등 함수는 ArrayList를 리턴하는데 이는 변경 가능하다.
- 컬렉션을 진짜 불변으로 만들지 않고 읽기 전용으로 설계함으로써 더 많은 자유를 얻을 수 있었다.
  - 실제 컬렉션을 리턴함으로써 플랫폼 고유 컬렉션을 사용할 수 있음
다만 개발자가 ‘시스템 해킹’을 시도해서 다운캐스팅을 할 때 문제가 된다.

val list = listOf(1, 2, 3)

if (list is MutableList) { // 이렇게 하지 말자
	list.add(4)
}

mutable로 변경해야 한다면 list.toMutableList를 활용하면 된다.
- 복제(copy)를 활용하는 방법

데이터 클래스의 copy

불변 객체에는 다음 장점이 있다.
- 한 번 정의된 상태가 유지되므로 코드를 이해하기 쉽다.
- 객체를 공유해도 충돌이 이뤄지지 않기에 병렬 처리가 안전
- 불변 객체에 대한 참조가 변경되지 않기에 쉽게 캐시할 수 있다.
- 방어적 복사본을 만들 필요가 없고 객체 복사 시 깊은 복사를 다로 하지 않아도 된다.
- 불변 객체는 다른 객체를 만들 때 활용하기 좋다.
- 객체 실행을 더 쉽게 예측 가능하다.
- Set 또는 Map의 키로 사용할 수 있는데 mutable 객체는 그럴 수 없다.
  - Set과 Map은 처음 요소 값을 기반으로 버킷을 결정하기 때문에 요소에 수정이 일어나면 내부에서 요소를 찾을 수 없게 되버린다.
따라서 불변 객체는 자신의 일부를 수정한 새로운 객체를 만들어 내는 메서드를 가져야 한다.
- ex) Int도 내부적으로 plus와 minus 등이 자신을 수정한 새로운 Int를 리턴한다.
하지만 모든 메서드에 이를 적용하기는 번거롭기에 data 한정자를 사용하면 된다.
- copy 메서드를 활용하면 모든 기본 생성자 프로퍼티가 같은 새로운 객체를 만들어 낼 수 있다.

data class User(
	val name: String,
	val surname: String
)

var user = User("Maja", "Markiewicz")
user = user.copy(surname = "Moskaja")

다른 종류의 변경 가능 지점

변경할 수 있는 리스트를 만들어야 한다면 두 가지 선택지가 존재한다.

val list1: MutableList<Int> = mutableListOf()
var list2: List<Int> = listOf()

// 두 가지 모두 변경 가능하다.
list1.add(1)
list2 = list2 + 1

두 가지 모두 변경 가능 지점이 있지만 그 위치가 다르다.
- list1은 구체적인 리스트 구현 내부에 변경 가능 지점이 있다.
  - 멀티스레드 환경에서 적절한 동기화가 이루어졌는지 알 수 없다.
- list2는 프로퍼티 자체가 변경 가능 지점이다.
  - 멀티스레드 처리 안정성이 더 좋기는 하다.
mutable 프로퍼티에 읽기 전용 컬렉션을 사용하는 것이 더 쉽다.
- 여러 객체를 변경하는 여러 메서드 대신 세터를 사용하면 되고 이를 private로 만들 수 있기 때문

var announcements = listOf<Announcement>()
	private set

변경 가능 지점 노출하지 말기

mutable 객체를 외부에 노출하는 것은 굉장히 위험하다.
- 리턴되는 mutable 객체를 복제하는 방어적 복제를 활용하면 좋다.
- 또는 객체를 읽기 전용 슈퍼타입으로 업캐스트하여 가변성을 제한할 수도 있다.

class UserHolder {
	private val user: MutableUser()
	
	fun get(): MutableUser = user.copy() // 방어적 복제
}

class UserRepository {
	private val storedUsers: MutableMap<Int, String> = 
		mutableMapOf()
		
	fun loadAll(): Map<Int, String> { // 업캐스팅
		return storedUsers
	}
}

정리

var 보다는 val를 사용하는 것이 좋다.
mutable 프로퍼티/객체보다는 immutable 프로퍼티/객체를 사용하는 것이 좋다.
변경이 필요하다면 immutable 데이터 클래스로 copy를 활용하는 것이 좋다.
컬렉션에 상태를 저장해야 한다면 mutable 컬렉션보다는 읽기 전용을 사용하는 것이 좋다.
변이 지점을 적절히 설계하고 불필요한 변이 지점은 만들지 않는 것이 좋다.
mutable 객체를 외부에 노출하지 않는 것이 좋다.