컴포넌트의 내부 구현을 숨기자

어설프게 설계된 컴포넌트와 잘 설계된 컴포넌트의 가장 큰 차이는 바로 클래스 내부 데이터와 내부 구현 정보를 외부 컴포넌트로부터 얼마나 잘 숨겼느냐이다.

 

오직 API를 통해서만 다른 컴포넌트와 소통하고 서로의 내부 동작 방식에는 전혀 개의치 않게 설계를 해야한다.

이것이 정보 은닉, 혹은 캡슐화라고 불리는 소프트웨어 설계의 근간이 되는 원리이다.

 

그럼 어떤 장점을 얻게 될까?

 

시스템 개발 속도를 높여준다. 여러 컴포넌트를 병렬로 개발할 수 있기 때문이다.

성능 최적화에 도움을 준다. 각 컴포넌트가 서로 영향을 주지 않기 때문에, 필요한 컴포넌트만 최적화할 수 있다.

소프트웨어 재사용성을 높인다. 외부에 거의 의존하지 않는 컴포넌트라면 다른 낯선 개발환경에서도 유용히 쓰일 수 있다.

큰 시스템을 제작하는 난이도를 낮춰준다. 시스템 전체가 완성 되지 않아도 컴포넌트별로 동작을 검증할 수 있다.

 

 

장점은 알아봤는데 그러면 어떻게 외부 컴포넌트로부터 잘 숨길 수 있을까?

자바는 정보 은닉을 위한 다양한 장치를 제공한다. 그중 접근 제어 메커니즘이 있다.

바로 클래스, 인터페이스, 멤버의 접근 범위를 정해주는 것이다.

 

기본 원칙은 간단하다. 모든 클래스와 멤버의 접근성을 가능한 한 좁혀야 한다.

즉, 소프트웨어가 올바로 동작하는 범위 안에서 항상 가장 낮은 접근 수준을 부여해야 한다는 뜻이다.

 

1. 톱레벨 클래스와 인터페이스에는 package-private와 public 두가지 접근 범위를 부여할 수 있다. (package-private는 아무 것도 쓰지 않으면 된다.)

public일 필요가 없는 클래스의 접근 수준을 package-private하게 좁혀주면 된다.

public 접근 범위

package-private 접근범위

2. 멤버(필드, 메서드, 중첩 클래스, 중첩 인터페이스)에 부여할 수 있는 접근 수준은 네 가지다.

private, package-private, protected, public

이 또한 마찬가지다. private로 접근 수준을 좁혀 놓고, 필요한 것들만 접근 수준을 풀어주도록 하자. (만약 접근 수준을 너무 많이 풀어주고 있는 자신을 발견한다면, 자신의 시스템에서 컴포넌트를 더 분해해야 하는건 아닌지 다시 고민해보자)

 

ref. Effective Java 3/E, 조슈어 블로크 저