[이펙티브 자바] Item15. 클래스와 멤버의 접근 권한을 최소화하라.

 

[이펙티브 자바] Item15. 클래스나 멤버의 접근 권한을 최소화하라. 

https://www.inflearn.com/course/%EC%9D%B4%ED%8E%99%ED%8B%B0%EB%B8%8C-%EC%9E%90%EB%B0%94-2/dashboard

이펙티브 자바 완벽 공략 2부 - 인프런 | 강의

이펙티브 자바 1부 강의를 모두 다 듣고, 이제 2부 강의를 듣기 시작했다! 🤗

1부와 마찬가지로 2부도 강의를 듣고 들은 내용을 블로그에 작성해둘 예정이다. 

2부에서는 4장 클래스와 인터페이스, 5장 제네릭에 대해서 학습한다..! 강의 예정은 총 4부까지 있는데 아직 2부까지만 강의가 나왔다..  

언제 3부 나올지는 아직 모르는거 같긴한데... 흠 

아무튼 3부 나오기전까지 2부 다 듣고 1부, 2부 복습하고 있어야지! 

 

 

 

4장. 클래스와 인터페이스 

item15. 클래스와 멤버의 접근 권한을 최소화하라. 

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

잘 설계된 컴포넌트는 모두 내부 구현을 완벽히 숨겨, 구현과 API를 깔끔하게 분리하고 오직 API를 통해서만 다른 컴포넌트와 소통하며 서로의 내부 동작에는 전혀 개의치 않는다. 

이런 방식을 캡슐화라고도 한다. 

 

 

👾 캡슐화, 즉 정보 은닉의 장점 

1️⃣ 시스템 개발 속도를 높인다. 

: 인터페이스 설계를 마치게 되면 인터페이스를 사용하는 쪽과 개발하는 쪽이 둘 다 동시에 개발할 수 있어서 시스템 개발 속도를 높일 수 있다. (물론 팀 협업으로 이루어진다고 생각할 때이다.) 

 

2️⃣ 시스템 관리 비용을 낮춘다. 

: 프로젝트에 처음 투입되었다면 가장 먼저 봐야하는 것은 인터페이스이다. 이제 인터페이스가 없다면 코드 파악이 굉장히 힘들어지는데 인터페이스가 있다면 각 컴포넌트를 좀 더 빨리 파악하여 디버깅 할 수 있고, 다른 컴포넌트로 교체하는 부담도 적어지기 때문이다.

 

3️⃣ 성능 최적화에 도움을 준다.  

: 정보 은닉 자체가 성능을 높여주지는 않지만, 성능 최적화에 도움을 준다. 프로파일링을 통해 최적화할 컴포넌트를 찾고 다른 컴포넌트에 영향을 주지 않고 해당 컴포넌트만 개선할 수 있기 때문이다. 

 

4️⃣ 시스템 개발 난이도를 낮춘다. 

: 전체 큰 시스템을 만들기 전에 개별 컴포넌트를 검증할 수 있기 때문이다. 즉, 시스템 전체가 아직 완성되지 않은 상태에서도 개별 컴포넌트 동작을 검증할 수 있기 때문이다. 

 

 

 

👩‍💻  클래스와 인터페이스의 접근 제한자 사용 원칙 

자바에서는 캡슐화를 위해서 접근 제어 메커니즘을 제공하는데 이는 클래스, 인터페이스, 멤버의 접근성(접근 허용 범위)를 명시한다. 

각 요소의 접근성은 그 요소가 선언된 위치와 접근 제한자로 정해진다. -> 이제 이 접근 제한자를 제대로 활용하는 것이 캡슐화의 핵심이기도 하다!!!

 

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

: 소프트웨어가 올바르게 동작하는 한 항상 가장 낮은 접근 수준을 부여해야 한다. 

 

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

: public으로 선언하면  공개 API가되고, package-private로 선언하면 해당 패키지 안에서만 사용할 수 있다. 

패키지를 외부에서 사용할 이유가 없다면 package-private로 선언하자! 그러면 크라이언트에 아무런 피해 없이도 다음 릴리즈에 수정, 교체, 제거할 수 있다. 반면에 public으로 선언한다면 API가 되기 때문에 하위 호환성을 유지하기 위해서는 영원히 관리해야 한다...😮

 

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

/**
 * item15. 클래스와 멤버의 접근 권한을 최소화하라.
 *  package-private를 사용해도 되지 않을까?
 *  왜냐하면 DefaultMemberService는 MemberService의 구현체로 내부에서만 알아도 되지 않는가? -> 외부(클라이언트)에서는 알 필요가 없지 않나
 */
class DefaultMemberService implements MemberService
{
   private String name;
   
   /**
    * 한 클래스에서만 사용하는 package-private 클래스나 인터페이스는
    * 해당 클래스에 private static으로 중첩 시키자 !
    */
   private static class PrivateStaticClass
   {
      // 별도의 클래스로 존재하던 것을 한 클래스에서만 사용한다면 중첩시키자~ 해서 가져온 것이기 때문에
      // 이렇게 private static으로 중첩시키는 것이 맞다. (DefaultMemberSerivce와 독립적인 관계)
   }
   
   private class PrivateClass
   {
      void doPrint() // 내부 클래스는 자기 자신을 감싸는 외부 클래스의 인스턴스를 가지고 있기 때문에 그냥 name을 사용할 수 있다.
      {
         System.out.println("name = " + name);
      }
   }
   
   public static void main(String[] args)
   {
      // final chapter03.item15.class_and_interface.member.DefaultMemberService chapter03.item15.class_and_interface.member.DefaultMemberService$PrivateClass.this$0
      Arrays.stream(PrivateClass.class.getDeclaredFields()).forEach(System.out::println);
   }
   
}

이렇게 톱레벨로 두면 같은 패키지의 모든 클래스가 접근할 수 있지만, private static으로 중첩시키면 바깥 클래스 하나에서만 접근할 수 있기 때문에 한 클래스에서만 사용하는 클래스나 인터페이스는 해당 클래스에 private static으로 중첩 시키는게 좋다. 

왜냐하면 public일 필요가 없는 클래스의 접근 수준을 package private 톱 레벨 클래스로 좁히면 

public 클래스는 그 패키지의 API인 반면, package-private 톱레벨은 내부 구현에 속하기 때문이다. 

 

 

 

 

👩‍💻  멤버(필드, 메서드, 중첩 클래스/인터페이스)의 접근 제한자 원칙 

 

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

- private

: 멤버를 선언한 톱레벨 클래스에서만 접근할 수 있다.

 

- package-private

: 멤버가 소속된 패키지 안의 모든 클래스에서 접근할 수 있다. 접근 제한자를 명시하지 않았을 때 적용되는 패키지 접근 수준이다. 

 

- protected 

: package-private의 접근 범위를포함하며, 이 멤버를 선언한 클래스의 하위 클래스에서도 접근할 수 있다.  

 

- public 

: 모든 곳에서 접근할 수 있다. 

 

 

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

- private와 package-private는 내부 구현이고, public 클래스의 protected와 public은 공개 API이다. 

 

- public 클래스의 인스턴스 필드는 되도록 public이 아니어야 한다. -> 클래스의 공개 API를 설계한 후에 그 외의 모든 멤버는 private로 만들고 다음 오직 같은 패키지의 다른 클래스가 접근해야 하는 멤버에 한해서만 package-private로 풀어주는 것이 좋다. 

 

- 그리고 단지 코드를 테스트하는 목적으로 private를 package-private로 풀어주는 것은 허용할 수 있지만 테스트를 위해서 멤버를 공개 API로만들어서는 안된다!! 

 

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

 

 

 

😐 모듈 시스템 

자바 9에서는 모듈 시스템이라는 개념이 도입되면서 두 가지의 암묵적 접근 수준이 추가되었다. 

모듈이란 패키지의 패키지라고 할 수 있는데 패키지가 클래스들의 묶음이듯이, 모듈은 패키지들의 묶음이다. 

 

모듈은 자신이 속하는 패키지 중 공개(export)할 것들을 module-info.java파일에 선언한다. protected 또는 public으로 선언된 멤버들이라도 해당 패키지를 공개하지 않는다면 모듈 외부에서는 접근할 수 없다. (물론 모듈 안에서는 exports 여부와는 상관 없다.) 

 

이렇게 모듈 시스템을 활용하면 클래스를 외부에 공개하지 않으면서도 같은 모듈을 이루는 패키지 안에서는 자유롭게 공유할 수 있다. 

하지만 이 모듈의 jar 파일을 자신의 모듈 경로가 아닌 애플리케이션의 클래스패스에 두면 그 모듈 안의 모든 패키지는 마치 모듈이 없는 것처럼 행동한다. 즉, 모듈이 공개했는지 여부와 상관없이 public 클래스가 선언한 모든 멤버를 모듈 밖에서도 접근할 수 있게 된다..! 

 

 

❗ 사실 모듈의 장점을 제대로 누리기 위해서는 설정해야 할 일들이 많다. 

먼저 패키지들을 모듈 단위로 묶고, 모듈 선언에 패키지들의 모든 의존성을 명시해야 하고, 그 다음 소스 트리를 재배치하고.. 모듈 안으로부터 일반 패키지로의 모든 접근에 특별한 조치를 취해야 한다...

모듈을 활용한 대표적인 예가  jdk 인데 jdk 외에도 모듈 개념이 널리 이용되기에는 아직 이른 감이 있고 당분간 사용하지 않는게 좋겠다라고... 책에 써있다..ㅎㅎ 

 

 

 

 

 

 

 

📚 정리 

프로그램 요소의 접근성은 가능한 한 최소한으로 하고
꼭 필요한 것만 골라서 최소한의 public API를 설계해야 한다. 

그 외에는 클래스, 인터페이스, 멤버가 의도치 않게 API로 공개되는 일이 없도록 해야 한다. 

public 클래스는 상수용 public static final 필드 외에는 어떠한 public 필드도 가져서는 안된다!!