-
[Effective Java] 아이템16: public 클래스에서는 public 필드가 아닌 접근자 메서드를 사용하라Language/Java 2022. 6. 24. 23:55
class Point { public double x; public double y; }
위의 클래스는 데이터 필드를 직접 접근할 수 있어, 캡슐화의 이점을 제공하지 못 한다.
API를 수정하지 않고는 내부 표현을 바꿀 수 없고, 불변식을 보장할 수 없으며, 외부에서 필드에 접근할 때 부수 작업을 수행할 수도 없다.class Point { private double x; private double y; public Point(double x, double y) { this.x = x; this.y = y; } public double getX() { return x; } public double getY() { return y; } public void setX(double x) { this.x = x; } public void setY(double y) { this.y = y; } }
위와 같이 필드는 private으로 하고, public 접근자를 추가하여 데이터를 캡슐화할 수 있다.
public 클래스에서라면 이 방식이 맞다.✔️ public 클래스
패키지 바깥에서 접근할 수 있는 클래스라면, 필드를 private으로 하고 public 접근자를 제공하는 것이 좋다.
이렇게 하면 클래스 내부 표현 방식을 언제든 바꿀 수 있는 유연성을 얻을 수 있다.만약 public 클래스의 필드가 불변이라면, 직접 노출할 때의 단점이 줄어들기는 하지만 좋은 생각은 아니다.
API를 변경하지 않고는 표현 방식을 바꿀 수 없고, 필드를 읽을 때 부수 작업을 수행할 수 없다.✔️ package-private 클래스, private 중첩 클래스
package-private 클래스 혹은 private 중첩 클래스는 필드를 노출해도 상관 없다.
그 클래스가 표현하려는 추상 개념만 올바르게 표현해주면 된다.이 방식은 클래스 선언 면에서나 이를 사용하는 클라이언트 코드 면에서나 접근자 방식보다 훨씬 깔끔하다.
핵심 정리
- public 클래스는 절대 가변 필드를 직접 노출해서는 안 된다.
- 불변 필드라면 노출해도 덜 위험하지만 완전히 안심할 수는 없다.
- 하지만 package-private 클래스나 private 중첩 클래스에서는 종종 (불변이든 가변이든) 필드를 노출하는 편이 나을 때도 있다.
728x90'Language > Java' 카테고리의 다른 글
[Effective Java] 아이템18: 상속보다는 컴포지션을 사용하라 (0) 2022.07.02 [Effective Java] 아이템17: 변경 가능성을 최소화하라 (0) 2022.06.29 [Effective Java] 아이템15: 클래스와 멤버의 접근 권한을 최소화하라 (0) 2022.06.22 [Effective Java] 아이템14:Comparable을 구현할지 고려하라 (0) 2022.06.20 [Effective Java] 아이템13: clone 재정의는 주의해서 진행하라 (0) 2022.06.16