TIL

아이템 30 요소의 가시성을 최소화하라

• API를 설계할 때 간결한 API를 유지해야 한다.
  • 작은 인터페이스는 배우기 쉽고 유지하기 쉽다.
  • 변경을 가할 때 기존의 것을 숨기는 것보다 새로운 것을 노출하는 것이 쉽다.
• 코틀린에선 구체 접근자의 가시성을 제한해서 모든 프로퍼티를 캡슐화하는 것이 중요하다.
  • 프로퍼티를 외부에서 변경할 수 있다면 클래스 불변성을 보장할 수 없다.
  • 아래처럼 세터만 private으로 만드는 코드는 굉장히 많이 사용된다.

class CounterSet<T>(
	private val innerSet: MutableSet<T> = setOf()
) : MutableSet<T> by innerSet {
	var elementsAdded: Int = 0
		private set
	
	// ...
}

• 가시성이 제한될 수록
  • 클래스 변경을 쉽게 추적할 수 있다.
  • 프로퍼티 상태를 더 쉽게 이해할 수 있다.
  • 병렬 프로그래밍을 할 때 안전해진다.

가시성 한정자 사용하기

• 작은 인터페이스를 유지하고 싶다면 가시성을 제한하면 된다.
• 클래스 멤버의 경우 다음 4개 가싱성 한정자를 사용할 수 있다.
  • public(디폴트): 어디에서나 볼 수 있다.
  • private: 클래스 내부에서만 볼 수 있다.
  • protected: 클래스와 서브 클래스 내부에서만 볼 수 있다.
  • internal: 모듈 내부에서만 볼 수 있다.
• 톱레벨 요소에는 세 가지 가시성 한정자를 사용할 수 있다.
  • public, private, internal
• 코틀린에서 모듈이란 함께 컴파일되는 코틀린 소스를 의미한다.
  • Gradle 소스 세트
  • Maven 소스 세트
  • IntelliJ IDEA 모듈
  • Ant 태스크 한 번으로 컴파일되는 파일 세트
• 한 가지 큰 제한은 API 상속 시 오버라이드해서 가시성을 제한할 수는 없다.
  • 서브클래스가 슈퍼클래스로도 사용될 수 있기 때문
  • 때문에 상속보다 컴포지션이 선호된다.

정리

• 인터페이스가 작을수록 공부하고 유지하기 쉽다.
• 최대한 제한이 되어 있어야 변경하기 쉽다.
• 클래스 상태를 나타내는 프로퍼티가 노출되어 있다면 클래스가 자신의 상태를 책임질 수 없다.
• 가시성이 제한되면 API 변경을 쉽게 추적할 수 있다.