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

아이템 15. 클래스와 멤버의 접근 권환을 최소화하라
- 아이템 15. 핵심 정리 - 구현과 API를 분리하는 “정보 은닉”의 장점

아이템 15. 핵심 정리 - 구현과 API를 분리하는 “정보 은닉”의 장점

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

캡슐화와 정보 은닉

이펙티브 자바 2부의 첫 번째 아이템은:

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

이다.

이번 아이템의 핵심은 바로:

캡슐화(Encapsulation)

그리고:

정보 은닉(Information Hiding)

이다.

자바는 접근 제어자를 제공한다.

public
protected
(package-private)
private

이 접근 권한을 어떻게 부여하느냐에 따라:

외부 공개 범위
변경 가능성
유지보수성
결합도

가 달라진다.

즉 이번 아이템은:

무엇을 공개하고 무엇을 숨길 것인가

에 대한 설계 이야기다.

왜 캡슐화가 중요한가?

캡슐화는 단순히 “코드를 예쁘게 만드는 기술”이 아니다.

실제로는:

개발 속도 향상
유지보수 비용 감소
성능 최적화 용이성
재사용성 증가
대규모 시스템 관리

와 직접 연결된다.

1. 개발 속도를 높인다

캡슐화를 잘 하면 자연스럽게 인터페이스 중심 설계가 된다.

예를 들어:

PaymentService

인터페이스가 있으면:

사용하는 쪽은 인터페이스만 보고 개발 가능
구현하는 쪽은 실제 로직 구현 가능

하다.

병렬 개발 가능

예:

A팀 → 인터페이스 사용
B팀 → 구현체 작성

가능해진다.

즉:

동시에 개발 가능

해진다.

혼자 개발할 때는 체감이 덜할 수도 있다

하지만 규모가 커질수록:

약속된 접점

이 반드시 필요하다.

그 역할이 바로 인터페이스다.

2. 유지보수 비용을 낮춘다

캡슐화가 잘 되어 있으면:

구조 파악이 쉬움
디버깅이 쉬움
교체가 쉬움

이라는 장점이 생긴다.

프로젝트 처음 들어갔을 때를 생각해보자

인터페이스가 없으면:

어디서부터 봐야 하는지 모름

인터페이스 중심 구조라면?

시스템의:

핵심 흐름
의존 관계
역할 분리

가 훨씬 빨리 보인다.

디버깅도 쉬워진다

문제가 발생했을 때:

어느 모듈 문제인지

빠르게 좁힐 수 있다.

교체도 쉬워진다

예:

MysqlRepository

를:

RedisRepository

로 바꿔도

인터페이스만 동일하면 된다.

결국 핵심은 의존성 감소

캡슐화는:

구현 세부사항 의존 제거

를 목표로 한다.

3. 성능 최적화에도 유리하다

캡슐화가 직접 성능을 올리는 것은 아니다.

하지만:

병목 지점 찾기

가 쉬워진다.

모듈이 분리되어 있기 때문

예:

DB 병목인가?
캐시 병목인가?
MQ 병목인가?
API 병목인가?

를 빠르게 파악 가능하다.

즉 최적화 범위를 줄일 수 있다

전체 시스템이 아니라:

특정 모듈만 집중 개선 가능

해진다.

4. 재사용성이 올라간다

캡슐화가 잘 된 모듈은 다른 프로젝트에서도 재사용 가능하다.

예시

NotificationService

내부 구현 숨김

Slack
Email
KakaoTalk

구현은 숨기고:

send(message)

만 공개한다.

결과

다른 프로젝트에서도 그대로 재사용 가능하다.

5. 큰 시스템 개발 난이도를 낮춘다

이건 사실:

Divide and Conquer

즉:

분할 정복

전략과 연결된다.

시스템을 작은 모듈로 나눈다

예:

Payment
User
Notification
Settlement
Auth

그러면?

복잡한 시스템도:

작은 문제들의 집합

으로 바뀐다.

이것이 모듈화의 힘이다

접근 제어자의 핵심 철학

이번 아이템의 핵심 철학은 아주 단순하다.

필요한 것만 공개하라

즉:

최소 공개 원칙

이다.

가능하면 private

정말 필요한 경우만:

protected
public

사용한다.

왜 public은 위험한가?

public은:

외부와의 계약(API)

이 되기 때문이다.

한 번 공개하면?

마음대로 변경하기 어렵다.

왜냐하면:

외부 코드가 의존하기 시작

하기 때문이다.

특히 라이브러리/프레임워크는 치명적

public API 변경은:

하위 호환성 문제

를 만든다.

그래서 공개 범위는 최소화해야 한다

private이 중요한 이유

private은:

언제든 내부 구현 변경 가능

하다.

즉 리팩토링 자유도가 높다

자료구조 교체 가능
알고리즘 교체 가능
최적화 가능
내부 정책 변경 가능

외부 영향 없음

왜냐하면 외부에서 접근하지 못하기 때문이다.

캡슐화의 진짜 의미

많은 사람들이 캡슐화를:

getter/setter 만드는 것

정도로 오해한다.

하지만 진짜 핵심은 다르다

변경 가능한 것을 숨기는 것

이다.

결국 목표는 변경 격리

변화가:

밖으로 전파되지 않게 만드는 것

이 핵심이다.

실무에서 자주 보이는 안 좋은 예시

public String name;
public int age;

문제점

누구든:

아무 값 대입 가능
검증 우회 가능
상태 오염 가능

캡슐화 완전 붕괴

더 좋은 방식

private String name;