- 가능한 한 간결한 API를 선호
- 작은 인터페이스는 배우기 쉽고 유지하기 쉬움
- 보이는 요소 자체가 적다면, 유지보수하고 테스트할 것이 적음
- 변경을 가할 때는 기존의 것을 숨기는 것보다 새로운 것을 노출하는 것이 쉬움
- 따라서 처음에는 작은 API로서 개발을 하도록 강제하는 것이 더 좋을 수 있음
- 클래스의 상태를 나타내는 프로퍼티를 외부에서 변경할 수 있다면, 클래스는 자신의 상태를 보장할 수 없음
- 세터만 private으로 만드는 코드는 굉장히 많이 사용됨
private set- 코틀린에서는 이처럼 구체 접근자의 가시성을 제한해서 모든 프로퍼티를 캡슐화하는 것이 좋음
- 가시성이 제한될수록 클래스의 변경을 쉽게 추적할 수 있으며, 프로퍼티의 상태를 더 쉽게 이해할 수 있음. 이는 동시성(concurrency)을 처리할 때 중요함
- 따라서 많은 것을 제한할수록 병렬 프로그래밍을 할 때 안전해짐
- 내부적인 변경 없이 작은 인터페이스를 유지하고 싶다면, 가시성(visibility)을 제한하면 됨
- 가시성을 제한해서 외부에서 집근할 수 없게 만드는 것이 좋음
- 클래스 멤버의 경우
- public(디폴트): 어디에서나 볼 수 있음.
- private: 클래스 내부에서만 볼 수 있음.
- protected: 클래스와 서브클래스 내부에서만 볼 수 있음.
- internal: 모듈 내부에서만 볼 수 있음.
- 톱레벨 요소
- public(디폴트): 어디에서나 볼 수 있음
- private: 같은 파일 내부에서만 볼 수 있음
- nternal: 모듈 내부에서 만 볼 수 있음
- 모듈과 패키지를 혼동하는 개발자들이 있는데, 의미가 전혀 다름
- 코틀린에서 모듈이란 함께 컴파일되는 코틀린 소스를 의미
- 그레이들(Gradle) 소스 세트
- 메이븐(Maven) 프로젝트
- 인텔리제이(IntelliJ)IDEA모듈
- 앤트(Ant) 태스크 한 번으로 컴파일되는 파일 세트
- 요소가 상속을 위해 설계되어 있고, 클래스와 서브클래스에서만 사용되게 만들고 싶다면 protected를 사용함
- 코틀린은 지역적으로만 사용되고 있는 요소는 private으로 만드는 것이 좋다는 컨벤션을 다음과 같이 제공해 줌
- 이러한 규칙은 데이터를 저장하도록 설계된 클래스(데이터 모델 클래스, DTO)에는 적용하지 않는 것이 좋음
- 데이터를 저장하도록 설계된 클래스는 숨길 이유가 없기 때문
- 프로퍼티를 사용할 수 있게 눈에 띄게 만드는 것이 좋으며, 필요하지 않은 경우 그냥 프로퍼티를 제거하는 것이 좋음
- API를 상속할 때 오버라이드해서 가시성을 제한할 수는 없음
- 서브클래스가 슈퍼클래스로도 사용될 수 있기 때문
- 상속보다 컴포지션을 사용하는 대표적인 이유
- 요소의 가시성은 최대한 제한적인 것이 좋음
- 인터페이스가 작을수록 이를 공부하고 유지하는것이 쉬움
- 최대한 제한이 되어 있어야 변경하기 쉬움
- 클래스의 상태를 나타내는 프로퍼티가 노출되어 있다면, 클래스가 자신의 상태를 책임질 수 없음
- 가시성이 제한되면 API의 변경을 쉽게 추적할 수 있음