본문으로 바로가기

1. public 데이터 필드의 단점

클래스의 데이터 필드를 public으로 공개하면 여러 단점이 존재한다.

 

  • 외부에서 해당 데이터 필드에 직접 접근할 수 있어 캡슐화의 장점을 살릴 수 없다.
  • API를 수정하지 않고는 내부 표현을 바꿀 수 없다.
  • 불변식을 보장할 수 없다.
  • 외부에서 해당 데이터 필드에 접근할 때 부수 작업을 수행할 수 없다.

2. getter

패키지 외부에서 접근할 수 있는 public 클래스가 필드를 공개하면 이를 사용하는 클라이언트가 생겨날 것이며, 클래스의 내부 표현을 마음대로 바꾸기 어려워진다.

 

따라서 데이터 필드를 private으로 캡슐화하고 getter 등의 접근자를 제공함으로써 클래스의 내부 표현 방식을 언제든 바꿀 수 있는 유연성을 얻을 수 있다.

 

그러나 package-private 및 private 중첩 클래스는 데이터 필드를 노출한다고 해도 문제가 없다.

 

  • package-private 클래스를 사용하는 클라이언트는 해당 클래스를 포함하는 패키지의 내부에서만 동작하는 코드이다.
    • 패키지 바깥 코드는 전혀 손대지 않고도 데이터 표현 방식을 수정할 수 있다.
  • private 중첩 클래스는 수정 범위가 해당 클래스를 포함하는 외부 클래스까지로 제한된다.

3. public final 필드

public 클래스의 필드가 final이라면 public으로 직접 노출할 때의 단점이 줄어들기는 하지만 좋은 방법은 아니다.

 

  • 클라이언트들이 해당 필드를 사용하여 의존할 수 있다.
    • API를 변경하지 않고는 내부 표현 방식을 자유롭게 변경하기 어려워진다.
  • 필드를 읽을 때 부수 작업을 수행할 수 없다.
  • 단, 불변식은 보장한다.

요약

public 클래스는 절대 가변 필드를 직접 노출해서는 안 된다.

 

불변 필드라면 노출해도 덜 위험하지만 완전히 안심할 수는 없다. 

 

하지만 package-private 클래스나 private 중첩 클래스에서는 종종 (불변이든 가변이든) 필드를

노출하는 편이 나을 때도 있다.