필드를 모으는 것 말고 아무 기능이 없는 클래스를 만들 때가 있다.
1 2 3 4 | class Poing { public double x; public double y; } |
이런 클래스는 데이터 필드를 직접 조작할 수 있어서 캡슐화의 이점을 누릴 수가 없다. API를 변경하지 않고서는 내부 표현을 변경할 수 없고, 불편식도 강제할 수 없고, 필드를 사용하는 순간에 어떤 동작이 실행되도록 만들 수도 없다. 객체 지향 개념에 충실하고자 하는 프로그래머에게 이런 클래스는 저주와 같다. private 필드와 public 접근자 메서드
getter, setter이 있어야 하고, 변경 가능 클래스라면 생성자와 getter, setter도 제공해야 한다.
선언된 패키지 밖에서도 사용 가능한 클래스에는 접근자 메서드를 제공해야한다. 그래야 클래스가 자유로이 수정할 수 있게 된다. public 클래스의 데이터 필드를 공개 하게 되면, 그 내부 표현을 변경할 수 없게 된다. 변경하면 이미 작성된 클라이언트 코드를 깨뜨리게 된다.
package-private(default) 클래스나 private 중첩 클래스는 데이터 필드를 공개하더라도 잘못이라 말할 수 없다. 클래스가 추상화하려는 내용을 제대로 기술하기만 한다면 말이다.
● 이 접근 법은 클래스 정의로 보나 클라이언트 코드로보나, 접근자 메서드보다는 시각적으로 깔끔해보인다.
● 클라이언트 코드가 내부 표현에 종속된다는 문제가 있긴 하지만, 클라이언트 코드가 같은 패키지 않에 있을 수 밖에 없다는 점을 고려해야한다.
● 클래스 내부 표현을 변경하더라도 패키지 외부 코드는 변경되지 않을 것이다. private 중첩 클래스의 경우에는, 그 클래스의 바깥 클래스 외부의 코드는 아무 영향도 받지 않을 것이다.
요약하자면 public 클래스는 변경 가능 필드를 외부로 공개하면 안 된다. 변경 불가능 필드인 경우에는 외부로 공개하더라도 많이 위험하진 않지만, 그럴 필요가 있는지는 여전히 의문이다. 하지만 package-private나 private 로 선언된 중첩 클래스의 필드는 그 변경 가능 여부와는 상관없이 외부로 공개하는 것이 바람직할 때도 있다.
'Effective Java > 3장 클래스와 인터페이스' 카테고리의 다른 글
Effective Java#15 변경 가능성을 최소화 하라 (0) | 2018.11.24 |
---|---|
Effective Java#13 클래스와 멤버의 접근 권한은 최소화 하라 (0) | 2018.11.24 |