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

2024. 10. 4. 23:08·1️⃣ 백앤드/이펙티브 자바

1. 잘 설계된 컴포넌트

잘 설계된 컴포넌트는 내부 구현 정보를 외부 컴포넌트로부터 완벽히 숨겨, 구현과 API 를 깔끔히 분리했다. 오직 API 를 통해서만 다른 컴포넌트와 소통하며, 서로의 내부 동작 방식에는 관심이 없다. 이것을 정보 은닉 또는 캡슐화라고 부른다.

1-1. 정보 은닉의 장점

여러 컴포넌트를 병렬로 개발할 수 있기 때문에, 시스템 개발 속도를 높일 수 있다.
각 컴포넌트를 더 빨리 파악하여 디버깅 할 수 있다.
최적화할 컴포넌트가 있다면, 다른 컴포넌트에 영향을 주지 않고 해당 컴포넌트만 성능 최적화할 수 있다.
독자적으로 작동할 수 있는 컴포넌트라면, 낯선 환경에서도 쓰일 가능성이 높아 소프트웨어 재사용성을 높일 수 있다.
개별 컴포넌트의 동작을 검증할 수 있어 큰 시스템의 제작 난이도를 낮춰준다.

 

자바는 이러한 정보 은닉을 위해 다양한 장치 (클래스, 인터페이스, 멤버의 접근성) 를 제공한다. 그 중, 접근 제한자 (private, protected, public) 를 제대로 활용하는 것이 정보 은닉의 핵심이다. 멤버 접근 수준에는 아래와 같이 네 종류가 있다.

 

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

톱 레벨 클래스 (최상위 클래스) 와 인터페이스에 부여할 수 있는 접근 수준은 package-private 과 public 두 가지다. public 으로 선언하면 공개 API 가 되고, package-private 으로 선언하면 해당 패키지 안에서만 사용 가능하다. 패키지 외부에서 쓸 이유가 없다면 package-private 으로 선언하자. 최대한 접근성을 좁혀 추후 릴리즈에 수정, 교체에 엮인 클라이언트가 없도록 만들자.

소프트웨어 설계의 근간이 되는 정보 은닉. 캡슐화

또한, 한 클래스에서만 사용하는 package-private 톱 레벨 클래스나 인터페이스는 이를 사용하는 클래스 안에 private static 으로 중첩시켜보자. 같은 패키지 내 모든 클래스가 아닌, 바깥 클래스에서만 접근할 수 있도록 말이다.

public class OuterClass {

    // OuterClass에서만 사용하는 HelperClass를 private static으로 선언
    private static class HelperClass {
        public void helperMethod() {
            System.out.println("HelperClass method is called");
        }
    }

    // OuterClass 내부에서 HelperClass와 MyInterface를 사용하는 메서드
    public void outerMethod() {
        // HelperClass 인스턴스 생성
        HelperClass helper = new HelperClass();
        helper.helperMethod();
    }

    public static void main(String[] args) {
        // OuterClass에서 내부 메서드 호출
        OuterClass outer = new OuterClass();
        outer.outerMethod();
    }
}

 

이렇게 한 클래스에서만 사용하는 클래스를 톱 레벨로 두는 대신, private static으로 중첩시켜서 관리하면, 클래스의 캡슐화가 더 강해지고 의도치 않은 접근을 막을 수 있다.

 

멤버 (필드, 메서드, 중첩 클래스, 중첩 인터페이스) 접근 수준에는 아래와 같이 네 종류가 있다.

class MyClass {
    // package-private (아무 접근 제한자도 없으므로 패키지 내에서만 접근 가능)
    int packagePrivateVar;
    
    // public (어디서든 접근 가능)
    public int publicVar;
    
    // private (해당 클래스 내에서만 접근 가능)
    private int privateVar;
    
    // protected (같은 패키지 또는 상속받은 클래스에서 접근 가능)
    protected int protectedVar;
}

 

클래스의 공개 API 를 세심히 설계한 후, 그 외 모든 멤버는 private 으로 만들고, 같은 패키지의 다른 클래스가 접근해야 한다면 private 접근 제한자를 제거해 package-private 으로 풀어주자. 특히, public 클래스에서 멤버의 접근 수준을 package-private 에서 protected 로 바꾸는 순간, 하위 클래스도 접근이 가능해지므로 해당 멤버에 접근할 수 있는 대상 범위가 넓어져, 영원히 엮여있어 지원이 되어야한다.

 즉 protected 멤버의 수는 적을수록 좋다. 

 

하지만, 단 한가지. 상위 클래스의 메서드를 재정의할 때는 접근 수준을 더 좁게 설정할 수는 없다. 또한, 테스트 코드를 작성하기 위해 접근 수준을 넓히려 할 때에도 private 멤버를 package-private 까지 풀어주는 것만 허용한다.

 

1-3. public 클래스의 인스턴스 필드는 되도록 public 이 아니어야 한다.

필드가 가변 객체를 참조하고 있다거나, final 로 선언되어 있지도 않은데 public 으로 선언한다면 그 필드에 담을 수 있는 값을 제한할 힘을 잃게 된다. 불변식을 보장할 수 없다는 것이다. 또한, public 가변 필드를 갖는 클래스는 일반적으로 스레드 안전하지 않다. 여러 스레드가 동시에 이 필드에 접근해 수정할 수 있기 때문이다. 이는 정적 필드에서도 마찬가지이나, 추상 개념을 완성하는데 꼭 필요한 상수라면, public static final 필드로 공개해도 된다.

// 보안 허점이 존재
public static final Thing[] VALUES = { ... } ;

 

그렇다고 위 처럼 배열 필드를 두거나, 이 필드를 반환하는 접근자 메서드를 제공해서는 안된다. 배열의 내용을 수정할 수 있기 때문이다. 해결책은 두 가지가 있다.

 

첫 번째 해결책은, 코드의 public 배열을 private 으로 만들고, public 불변 리스트를 추가하는 것이다.

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

 

두 번째 해결책은, 배열을 private 으로 만들고 그 복사본을 반환하는 public 메서드를 추가하는 방법이다.

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

 

2. 자바 9 모듈 시스템

자바 9에서, 모듈 시스템이라는 개념이 도입되면서 암묵적 접근 수준이 추가되었다. 패키지는 클래스의 묶음이듯, 모듈은 패키지의 묶음이다. 모듈은 자신이 속한 패키지 중, 공개할 것들을 (관례상 module-info.java) 선언해 protected, public 멤버라 할지라도 패키지를 공개하지 않았다면 모듈 외부에서 접근할 수 없게 한다. 따라서 클래스를 외부에 공개하지 않으면서도, 같은 모듈 내 패키지 사이에서는 자유롭게 공유할 수 있도록 할 수 있다.

module com.example.myapp {
    requires java.sql; // java.sql 모듈을 필요로 한다.
    exports com.example.myapp.service; // com.example.myapp.service 패키지를 외부에 공개한다.
}

'1️⃣ 백앤드 > 이펙티브 자바' 카테고리의 다른 글

[아이템17] 변경 가능성을 최소화하라  (1) 2024.10.06
[아이템16] public 클래스에서는 public 필드가 아닌 접근자 메서드를 사용하라  (0) 2024.10.05
[아이템14] Comparable 을 구현할지 고려하라  (1) 2024.09.25
[아이템13] clone 재정의는 주의해서 진행하라  (0) 2024.09.25
[아이템12] toString 을 항상 재정의하라  (1) 2024.09.25
'1️⃣ 백앤드/이펙티브 자바' 카테고리의 다른 글
  • [아이템17] 변경 가능성을 최소화하라
  • [아이템16] public 클래스에서는 public 필드가 아닌 접근자 메서드를 사용하라
  • [아이템14] Comparable 을 구현할지 고려하라
  • [아이템13] clone 재정의는 주의해서 진행하라
HOZINU
HOZINU
주니어 백앤드 개발자의 세상만사 이모저모. 주로 개발 이야기를 다룸.
  • HOZINU
    백엔드 탐험 일지
    HOZINU
  • 전체
    오늘
    어제
  • 블로그 메뉴

    • ⛪ HOME
    • 🌍 GITHUB
    • 카테고리 (73)
      • 1️⃣ 백앤드 (72)
        • 이펙티브 자바 (72)
      • 2️⃣ CS (0)
        • 운영체제 (0)
        • 네트워크 기초 (0)
        • 네트워크 응용 (0)
        • SSL & PKI (0)
        • 기타 (0)
      • 3️⃣ 코딩테스트 (0)
      • 4️⃣ 개인공부 (0)
        • MSA (0)
        • REDIS (0)
      • 5️⃣ 일상이야기 (1)
  • 인기 글

  • 태그

    캡슐화
    멤버클래스
    빌더
    싱글턴
    finalizer
    표준예외
    맥북
    정보은닉
    의존객체
    optional
    equals
    컴포지션
    정적 팩터리 메서드
    try-with-resources
    Comparable
    로타입
    Cleaner
    계층구조
    CLONE
    hashcode
  • 최근 댓글

  • 최근 글

  • hELLO· Designed By정상우.v4.10.2
HOZINU
[아이템15] 클래스와 멤버의 접근 권한을 최소화하라
상단으로

티스토리툴바