아이템15. 클래스와 멤버의 접근 권한을 최소화하라

핵심 정리 - 구현과 API를 분리하는 "정보 은닉"의 장점

- 시스템 개발 속도를 높인다. (여러 컴포넌트를 병렬로 개발할 수 있기 때문에)

- 시스템 관리 비용을 낮춘다. (컴포넌트를 더 빨리 파악할 수 있기 때문에)

- 성능 최적화에 도움을 준다. (프로파일링을 통해 최적화할 컴포넌트를 찾고 다른 컴포넌트에 영향을 주지 않고 해당 컴포넌트만 개선할 수 있기 때문에)

- 소프트웨어 재사용성을 높인다. (독자적인 컴포넌트라면)

- 시스템 개발 난이도를 낮춘다. (전체를 만들기 전에 개별 컴포넌트를 검증할 수 있기 때문에)

 

핵심 정리 - 클래스와 인터페이스의 접근 제한자 사용 원칙

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

- 톱레벨 클래스와 인터페이스에 package-private 또는 public을 쓸 수 있다.

    ㆍpublic으로 선언하면 API가 되므로 하위 호환성을 유지하려면 영원히 관리해야 한다.

    ㆍ패키지 외부에서 쓰지 않을 클래스나 인터페이스라면 package-private으로 선언한다.

- 한 클래스에서만 사용하는 package-private 클래스나 인터페이스는 해당 클래스에 private static으로 중첩시키자

  (아이템24)

 

- 탑레벨에는 public, package-private 말고는 쓸 수 없다. 

    ㆍinterface와 class에는 private, protected 를 쓸 수 없다.

- 구현체는 package-private으로 둔다.

    ㆍ인터페이스를 보길 바란다.

 

- private static class로 중첩시키자?

class DefaultMemberService implements MemberService{

    private String name;

    private static class PrivateStaticClass {   // 아무런 레퍼런스가 없다.    // 별개의 클래스

    }

    private class PrivateClass {    // 외부 인스턴스(DefaultMemberService)를 참조

        void doPrint() {
            System.out.println(name);
        }
    }

}

- static class

    ㆍ별개의 클래스이다. 독립적이다.

- class

    ㆍ외부 인스턴스, 즉 DefaultMemberService를 참조한다.

    ㆍ외부 인스턴스의 필드를 접근해서 쓸 수 있다.

 

핵심 정리 - 멤버(필드, 메서드, 중첩 클래스/인터페이스)의 접근 제한자 원칙

- private과 package-private은 내부 구현

- public 클래스의 protected와 public은 공개 API

- 코드를 테스트하는 목적으로 private을 package-private으로 풀어주는 것은 허용할 수 있다.

  하지만 테스트만을 위해서 멤버를 공개 API로 만들어서는 안 된다.(테스트를 같은 패키지에 만든다면 그럴 필요도 없다.)

    ㆍpublic getter를 만들바에는 필드를 package-private 으로 풀어줘라.

- public 클래스의 인스턴스 필드는 되도록 public이 아니어야 한다. (아이템16)

- 클래스에서 public static final 배열을 두거나 이 필드를 반환하는 접근자 메서드를 제공해서는 안된다.

 

public static final String[] NAME = "whiteship";

- 배열일 경우에는 변경할 수 있다는 것에 유의할 것!

 

- protected 필드의 경우 class가 상속될 경우, 쓰일 수 있다! - 범위가 넓어진다.

 

완벽 공략 요약

- p98, Serializable, "완벽 공략 13, 객체 직렬화" 참고

- p98, 리스코프 치환 원칙, "완벽 공략 26" 참고

- p99, 스레드 안전 (Thread Safe), "완벽 공략 28" 참고

- p99, 불변 객체, "완벽 공략 24, Value 기반의 클래스" 참고

- p100,  자바 9 모듈 시스템

 

완벽 공략 - 자바 플랫폼 모듈 시스템1

- JSR-376 스팩으로 정의한 자바의 모듈 시스템

- 안정성 : 순환 참조 허용하지 않음, 실행시 필요한 모듈 확인, 한 패키지는 한 모듈에서만 공개할 수 있음

- 캡슐화 : public 인터페이스나 클래스라 하더라도, 공개된 패키지만 사용할 수 있다.

                 내부 구현을 보호하는 수단으로 사용할 수 있다. ( 하지만 모듈이 아닌 곳에서 참조한다면... )

- 확장성 : 필요한 자바 플랫폼 모듈만 모아서 최적의 JRE를 구성할 수 있다.

                 작은 기기에서 구동할 애플리케이션을 개발할 때 유용하다.

 

완벽 공략 - 자바 플랫폼 모듈 시스템2

- 제공하는 모듈 쪽에서도, 사용하는 모듈 쪽에서도 서로를 선언해줘야 한다. (export, requires)

- 모듈은 모듈에서만 쓸 때 의미가 있다.