item 15 leekyunghee - JAVA-JIKIMI/EFFECTIVE-JAVA3 GitHub Wiki

• 설계가 잘된 컴포넌트는 클래스 내부 데이터와 내부 구현 정보를 얼마나 잘 숨겼는지 이다.
• 내부 구현을 완벽히 숨겨 구현과 API를 깔끔히 분리한다.
• API를 통해서만 다른 컴포넌트와 소통하며 서로의 내부 동작 방식에는 전혀 개의치 않는다.

정보 은닉, 캡슐화

• 시스템을 구성하는 컴포넌트들을 서로 독립시켜서 개발, 테스트, 최적화, 적용, 분석, 수정을 개별적으로 할 수 있다.
• 여러 컴포넌트를 병렬로 개발
• 각 컴포넌트를 빨리 파악하여 디버깅할 수 있음
• 성능 최적화에 도움
• 재사용성 향상 - 외부에 거의 의존하지 않고 독자적으로 동작할 수 있으므로
• 대규모 시스템을 제작하는 난이도를 낮춘다. 완성되지 않더라도 개별 컴포넌트의 동작을 검증

• 접근 제어 메커니즘은 클래스, 인터페이스, 멤버의 접근성(접근 허용 범위)을 명시한다.
• Object의 protected 메서드인 clone의 동작 방식을 결정한다.
• 접근 제한자를 제대로 활용하는 것이 정보 은닉의 핵심

모든 클래스와 멤버의 접근성을 가능한 한 좁혀야 한다.

• 가장 바깥이라고 의미하는 톱레벨 클래스와 인터페이스에 부여할 수 있는 접근 기준은 package-private와 public
• 톱레벨 클래스나 인터페이스를 public으로 선언하면 공개 API가 되며 private으로 선언하면 해당 패키지 안에서만 사용

한 클래스에서만 사용하는 private 톱레벨 클래스나 인터페이스는 이를 사용하는 클래스 안에 private static으로 중첩시켜보자.

톱레벨로 두면 같은 패캐지의 모든 클래스가 접근할 수 있지만 private static으로 중첩시키면 바깥 클래스 하나에서만 접근할 수 있다. public일 필요가 없는 클래스의 접근 수준을 package-private 톱레벨 클래스로 좁히는 일이다.

• 상위 클래스의 메서드를 재정의할 때는 그 접근 수준을 상위 클래스에서보다 좁게 설정할 수 없다.
• 상위 클래스의 인스턴스는 하위 클래스의 인스턴스로 대체해 사용할 수 있어야한다는 규칙(리스코프 치환 원칙)을 지키기 위해 필요함.
• 이때 클래스는 인터페이스가 정의한 모든 메서드를 public으로 선언해야 한다.

• 코드를 테스트하려는 목적으로 적당한 수준까지는 넓혀도 됨
• public 클래스의 private 멤버를 package-private까지 풀어주는 것은 허용할 수 있지만 그 이상은 안됨
• API로 만들어서는 안된다.

• 필드가 가변 객체를 참조하거나 final이 아닌 인스턴스 필드를 public으로 선언하면 그 필드에 담을 수 있는 값을 제한할 힘을 잃게됨
• 필드와 관련된 모든 것은 불변식을 보장할 수 없게 되므로 필드가 수정될 때(락 획득) 다른 작업을 할 수 없게 되됨

public 가변 필드를 갖다 붙이는 클래스는 일반적으로 스레드 안전하지 않다. 정적 필드에서도 마찬가지 임

• 해당 클래스가 표현하는 추상 개념을 완성하는 데 꼭 필요한 구성요소로써의 상수라면 public static final 필드로 공개해도 좋다.
• 관례상 이런 상수의 이름은 대문자 알파벳, 단어 사이 (_) 추가
• 반드시 기본 타입 값이나 불변 객체를 참조해야 한다.
• 가변 객체를 참조한다면 final이 아닌 필드에 적용되는 모든 불이익이 그대로 적용된다.
• 다른 객체를 참조하지는 못하지만 참조된 객체 자체는 수정될 수 있으니 결과가 좋지 않을 수 있음.

• 클래스에서 public satic final 배열 필드를 두거나 이 필드를 반환하는 접근자 메서드를 제공해서는 안된다.
• 클라이언트에서 그 배열의 내용을 수정할 수 있게 되므로 보안 허점이 발생.

public static final Thing[] VALUES = { };

private  static final Thing[] PRIVATE_VALUES = { ... };
public static final List<Thing> VALUES = Collections.unmodifiableList(Arrays.asList(PRIVATE_VALUES));

private  static final Thing[] PRIVATE_VALUES = { ... };
public static final Thing[] values() {
    return PRIVATE_VALUES.clone();
}

• 패키지가 클래스들의 묶음이듯 모듈은 패키지들의 묶음이다.
• 모듈은 자신에 속하는 패키지 중 공개(export)할 것들을 관례상 module-info.java 파일에 선언한다.
• protected 혹은 public 멤버라도 해당 패키지를 공개하지 않았다면 모듈 외부에서는 접근할 수 없다.
• 모듈 안에서는 exports로 선언했는지 여부에 아무런 영향도 받지 않는다.
• 모듈 시스템을 활용하면 클래스를 외부에 공개하지 않으면서도 같은 모듈을 이루는 패키지 사이에서는 자유롭게 공유할 수 있다.

암묵적 접근 수준들은 각각 public 수준과 protected 수준과 같으나 그 효과가 모듈 내부로 한정되는 변종인 것이다.

이러한 형태로 공유해야 하는 상황은 흔하지 않다. 패키지들 사이에서 클래스들을 재배치하면 대부분 해결된다.

1. 패키지들을 모듈 단위로 묶고 모듈 선언에 패키지들의 모든 의존성을 명시한다.
2. 소스 트리를 재배치
3. 모듈 안으로 부터 (모듈 시스템을 적용하지 않는) 일반 패키지로의 모든 접근에 특별한 조치를 취해야 한다.

핵심 정리

public일 필요가 없는 클래스의 접근 수준을 package-private 톱레벨 클래스로 좁힌다. public 클래스는 그 패키지의 API인 반면 package-private 톱레벨 클래스는 내부 구현에 속하기 때문이다.

꼭 필요한 것만 골라 최소한의 public API를 설계하자.