답변.

자바에서는 필드, 메서드 및 클래스에 대한 접근을 제어하기 위해 접근 제어자를 사용합니다: private, default (패키지-프라이빗), protected, public.

문제의 역사:

초기 버전의 자바는 엄격한 객체 캡슐화를 사용했습니다. 유연성을 위해 완전한 폐쇄성과 확장성(상속 및 패키지 내 접근)을 지원하기 위해 다양한 접근 수준이 도입되었습니다.

문제점:

잘못된 접근 제어자 선택은 캡슐화 위반, 상속 문제, 테스트 불가능성 또는 데이터가 실수로 공개되어 발생하는 보안 결함으로 이어질 수 있습니다.

해결책:

아키텍처에서 허용하는 가장 폐쇄적인 접근 제어자를 사용하세요. 일반적으로 필드는 private로 설정하고, getter/setter를 통해 접근합니다. 메서드는 API의 일부인 경우에만 public으로 설정하며, 확장을 위해서는 protected로 설정합니다.

코드 예:

public class Person {
    private String name; // 비공개 필드
    protected int age; // 패키지 및 서브클래스에서 접근 가능
    String email; // 패키지-프라이빗
    public String getName() { return name; }
}

주요 특징:

private — 클래스 내부에서만 접근 가능
패키지-프라이빗 (수정자 없음) — 같은 패키지의 모든 클래스에서 접근 가능
protected — 다른 패키지의 서브클래스에서도 접근 가능
public — 모두에게 접근 가능

함정 질문.

로컬 변수에 접근 제어자를 적용할 수 있나요?

아니요. 접근 제어자는 클래스, 메서드, 필드/내부 클래스에만 적용되며, 로컬 변수에는 적용되지 않습니다.

메서드 내부에 공개(public) 수정자로 클래스를 만들 수 있나요?

아니요. 로컬 클래스는 접근 제어자와 함께 선언될 수 없으며, 항상 메서드 내부에서만 접근 가능합니다.

다른 패키지의 서브클래스에서 protected 구성원에 접근할 수 있나요?

네, protected 구성원은 다른 패키지에 있더라도 서브클래스에서 접근 가능하지만, 다른 패키지의 일반 클래스에서는 접근할 수 없습니다.

일반적인 오류 및 안티 패턴

public 필드 사용(캡슐화 위반)
"우연한" 패키지-프라이빗(생략된 수정자)
필요 없이 protected 메서드를 과도하게 노출
애플리케이션의 다양한 부분 간 정보를 전달하기 위해 public static 필드를 남용

실제 사례

부정적인 사례

모든 클래스 필드가 우연히 public으로 선언되어 다른 클래스에서 직접 접근하게 되어 변경 사항 추적이 어렵습니다.

장점:

데이터에 빠르고 쉽게 접근 가능

단점:

접근 제어의 어려움. 검증/유효성 검사 로직 없음
데이터를 쉽게 손상시킬 수 있음

긍정적인 사례

모든 필드는 private이며, 공개 메서드는 유효성을 검사하여 접근을 제어하고, 필요한 부분만 상속을 위해 protected로 설정합니다.