[Effective Java 규칙13] 클래스와 멤버의 접근 권한은 최소화하라

[Effective Java 규칙13] 클래스와 멤버의 접근 권한은 최소화하라

Effective Java 2/E 책과 구글링을 통해 내용을 정리하고 개인적인 견해가 포함된 글입니다.

잘 설계된 모듈은 구현 세부사항을 전부 API 뒤쪽에 감춘다. 모듈들은 API를 통해서만 서로 통신하며, 각자 내부적으로 어떻게 동작하는지 신경 쓰지 않는다.

이러한 개념은 정보 은닉/캡슐화라고 알려져 있는 소프트웨어 설계의 기본적인 원칙 가운데 중 하나이다. 

캡슐화가 시스템을 구성하는 모듈 사이의 의존성을 낮춰서, 각자 개별적으로 개발하고, 테스트하고, 변경할 수 있게 한다. 그러면 각각의 모듈을 병렬적으로 개발하여 시스템 개발 속도가 올라가게 되고, 유지보수도 쉽게할 수 있다. 정보 은닉 원칙이 좋은 성능을 보장하지는 않지만, 효과적인 성능 튜닝을 가능하게 한다.

이렇게 만든 모듈은 재사용하기에도 용이하다. 모듈간 의존성이 낮기때문에 다른 소프트웨어 개발에도 유용하게 쓰일 수 있다. 

각 클래스와 멤버는 가능한 접근 불가능하게 만들어야 한다. 최상위 클래스와 인터페이스는 public 과 package-private 두가지로 설정할 수 있는데 public은 말그대로 전역으로 사용할 수 있고, package-private은 패키지내에서만 사용할 수 있다. 가능한 최상위 레벨 클래스나 인터페이스는 package-private로 선언해야 한다. 이렇게 선언하면 API의 일부가 아니라 구현 세부사항에 속하게 되므로, 다음번 릴리즈에 클라이언트 코드를 깨뜨릴 걱정 없이 자유롭게 변경하거나 삭제하거나 대체할 수 있다. public으로 선언하면 호환성을 보장하기 위해 해당 개체를 계속 지원해야 한다.

필드, 메서드, 중첩클래스, 중첩 인터페이스와 같은 멤버의 접근권한은 아래 4개로 설정 가능하다

private  :  최상위 레벨 클래스 내부에서만 접근 가능

package-private  :  같은 패키지 내의 아무 클래스에서 사용 가능하다. 기본 접근 권한으로 알려져 있으며, 아무것도 붙이지 않으면 이 권한이 주어진다

protected  :  해당 클래스 및 하위 클래스, 선언된 클래스와 같은 패키지에 있는 클래스에서 사용할 수 있다.

public  :  전역으로 사용 가능

public api를 제외하고는 대부분 private으로 선언하게 되는데 같은 패키지 내의 다른 클래스가 반드시 사용하는 멤버인 경우 package-private로 만들어야 한다. private과 package-private은 클래스의 구현 세부사항이며 공개 API의 일부가 아니다.

그리고 객체 필드의 경우 절대로 public으로 선언하면 안된다. 왜냐하면 변경 가능한 public 필드를 가진 클래스는 다중 스레드에 안전하지 않기 때문이다. 

요약하면,

접근 권한은 가능한 낮춰라.

최소한의 public api를 설계한 다음, 다른 모든 클래스, 인터페이스, 멤버는 API에서 제외해야 한다. 

public static final을 제외한 어떤 필드도 public 필드로 선언하지 말아야 한다. 그리고 public static final 필드가 참조하는 객체는 변경 불가능 객체로 만들어야 한다.

Single Dex 시절에는 Getter Setter를 남발하지말라(성능 차이가 60% 정도 감소)라고 가이드가있었는데 사라짐

Multi Dex 나오고나서부터는 고민할 필요는 없음.

//TODO

Serializable vs Parcelable 차이점과 속도차이 장단점 지켜야할 규칙등을 찾아서 정리하기