간결한 API를 선호하는 여러가지 이유가 있다
-
작은 인터페이스는 배우고 유지보수하기 쉬움
-
변경을 가할 때는 기존의 것을 숨기는 것보다 새로운 것을 노출하는 것이 쉬움
- 외부에서 사용하고 있는 요소들은 변경하기 어렵고 (사용하고 있는 모든 부분이 영향을 받기 때문에), 가시성과 관련된 제한을 변경하는 것은 더 어렵다.
또한, 클래스의 상태를 나타내는 프로퍼티를 외부에서 변경할 수 있다면 클래스는 자신의 상태를 보장할 수 없다. 규약을 모르는 사람들은 클래스의 상태를 마음대로 변경할 수 있으므로 클래스의 불변성이 무너질 가능성이 있다.
세터를 private으로 설정한다면 외부에서 강제로 바꿀 수 없기 때문에 많이 사용된다.
일반적으로 코틀린에서는 구체 접근자의 가시성을 제한해서 모든 프로퍼티를 캡슐화하는 것이 좋다. 서로서로 의존하는 프로퍼티가 있을 때는 객체 상태를 보호하는 것이 더 중요하다.
가시성이 제한될수록 클래스의 변경을 쉽게 추적할 수 있으며, 프로퍼티의 상태를 더 쉽게 이해할 수 있다.
이는 동시성(concurrency)을 처리할 때 중요하다. 상태 변경은 병렬 프로그래밍에서 문제가 되기 때문에 많은 것을 제한할수록 안전해진다.
가시성 한정자 사용하기
내부적인 변경없이 작은 인터페이스를 유지하고 싶다면, 외부에서 접근할 수 없게 가시성을 제한하면 된다.
클래스의 멤버의 경우 4개의 가시성 한정자가 있다.
- public(default): 어디에서나 볼 수 있음
- private: 클래스 내부에서만 볼 수 있음
- proteced: 클래스와 서브클래스 내부에서만 볼 수 있음
- internal: 모듈 내부에서만 볼 수 있음
톱레벨 요소에는 세 가지 가시성 한정자를 사용할 수 있다.
- public(default): 어디에서나
- private: 같은 파일 내부에서만
- internal: 모듈 내부에서만
참고로 모듈과 패키지는 다르다. 모듈이란 함께 컴파일되는 코틀린 소스를 의미
ex) 그레이들 소스 세트, 메이븐 프로젝트, 인텔리제이 IDEA 모듈, 앤트(Ant) 태스트 한 번으로 컴파일되는 파일 세트
모듈이 다른 모듈에 의해서 사용될 가능성이 있다면? -> internal 로 공개하고 싶지 않은 요소 숨기기
요소가 상속을 위해 설계, 클래솽 서브클래스에서만 사용되게 하고프면? -> protected 사용
참고로 코틀린은 지역적으로만 사용되고 있는 요소는 private으로 만드는 것이 좋다는 컨벤션을 알려준다.
물론 이러한 규칙은 데이터를 저장하도록 설계된 클래스(DTO)에는 적용하지 않는게 좋다. 데이터를 저장하도록 설계된 클래스는 숨길 이유가 없기 때문이다. 따라서 프로퍼티를 사용할 수 있게 눈에 띄게 만드는 것이 좋으며, 필요하지 않는 경우 그냥 프로퍼티를 제거하는 것이 좋다
한 가지 큰 제한은 API를 상속할 때 오버라이드해서 가시성을 제한할 수는 없다. 이는 서브클래스가 슈퍼클래스로도 사용될 수 있기 때문이다. 이것이 상속보다 컴포지션을 선호하는 대표적인 이유이다.
정리
요소의 가시성은 최대한 제한적이게, 단순하게 가자
- 인터페이스가 작을수록 이를 공부하고 유지하는 것이 쉽다.
- 최대한 제한이 되어 있어야 변경하기 쉽다.
- 클래스의 상태를 나타내는 프로퍼티가 노출되어 있다면 클래스가 자신의 상태를 책임질 수 없다.
- 가시성이 제한되면 API 변경을 쉽게 추적할 수 있다.
