추상화의 기본 단위인 클래스와 인터페이스는 자바 언어의 심장과도 같다. 그래서 자바 언어에는 클래스와 인터페이스 설계에 사용하는 강력한 요소가 많이 있다.
이번 장에서는 이런 요소를 적절히 활용하여 클래스와 인터페이스를 쓰기 편하고, 견고하며, 유연하게 만드는 방법을 안내한다.
[아이템 15] 클래스와 멤버의 접근 권한을 최소화하라
좋은 설계와 어설픈 설계의 차이는 내부 데이터와 내부 구현 정보를 외부 컴포넌트로부터 얼마나 잘 숨겼느냐에 따라서 드러난다. 좋은 설계는 은닉성을 지키며, 구현과 API를 깔끔히 분리한다. 오직 API를 통해서만 다른 컴포넌트와 소통하며 서로의 내부 동작 방식에는 전형 개의치 않는다. 이것을 정보 은닉, 혹은 캡슐화라고 부른다. 이는 소프트웨어 설계의 근간이 되는 원리다.
정보 은닉의 장점은 개발, 테스트, 최적화, 적용, 분석, 수정을 개별적으로 할 수 있게 해주는 것과 연관되어 있다.
정보 은닉의 구체적인 장점
- 시스템 개발 속도를 높인다. 여러 컴포넌트를 병렬로 개발할 수 있기 때문이다.
- 시스템 관리 비용을 낮춘다. 각 컴포넌트를 더 빨리 파악하여 디버깅할 수 있고, 다른 컴포넌트로 교체하는 부담도 적기 때문이다.
- 정보 은닉 자체가 성능을 높여주지는 않지만, 성능 최적화에 도움을 준다. 완성된 시스템을 프로파일링해 최적화할 컴포넌트를 정한 다음 다른 컴포넌트에 영향을 주지 않고 해당 컴포넌트만 최저화할 수 있기 때문이다.
- 소프트웨어의 재사용성을 높인다. 외부에 의존하지 않고 독자적으로 동작할 수 있는 컴포넌트라면 그 컴포넌트와 함께 개발되지 않은 낯선 환경에서도 유용하게 쓰일 가능성이 크기 때문이다.
- 큰 시스템을 제작하는 난이도를 낮춘다. 시스템 전체가 아직 완성되지 않은 상태에서도 개별 컴포넌트의 동작을 검증할 수 있기 때문이다.
정보 은닉의 기본 원칙은 간단하다. 모든 클래스와 멤버의 접근성을 가능한 한 좁혀야 한다.
멤버 (필드, 메소드, 중첩 클래스, 중첩 인터페이스) 에 부여할 수 있는 접근 수준
- private : 멤버를 선언한 톱레벨 클래스에서만 접근할 수 있다.
- package-private : 멤버가 소속된 패키지 안의 모든 클래스에서 접근할 수 있다. 접근 제한자를 명시하지 않았을 때 적용되는 패키지 접근 수준이다. 단, 인터페이스의 멤버는 기본적으로 public이 적용된다.
- protected : package-private의 접근 범위를 포함하며, 이 멤버를 선언한 클래스의 하위 클래스에서도 접근할 수 있다.
- public : 모든 곳에서 접근할 수 있다.
접근 수준을 고려한 설계
설계 비법으로는 공개 API를 세심히 설계한 후, 그 외의 모든 멤버는 private으로 만들고, 그런 다음 오직 같은 패키지의 다른 클래스가 접근해야 하는 멤버에 한하여 (private 제한자를 제거해) package-private이나 protected로 풀어주자.
주의 사항 하나.
public 클래스에서는 멤버의 접근 수준을 package-private에서 protected로 변경하는 순간 그 멤버에 접근할 수 있는 대상 범위가 엄청나게 넓어진다. 따라서 protected 멤버의 수는 적을수록 좋다.
주의 사항 둘.
상위 클래스의 메소드를 재정의할 때는 그 접근 수준을 상위 클래스에서보다 좁게 설정할 수 없다.
주의 사항 셋.
public 클래스의 인스턴스 필드는 되도록 public이 아니여야 한다. (아이템 16) public 가변 필드를 갖는 클래스는 일반적으로 스레드에서 안전하지 않다.
다만 예외가 하나 있다. 해당 클래스가 표현하는 추상 개념을 완성하는데 꼭 필요한 구성요소로써의 상수라면 public static final 필드로 공개해도 좋다. 이런 필드는 반드시 기본 타입 값이나 불변 객체를 참조해야 한다. (아이템 17) 가변 객체를 참조한다면 final이 아닌 필드에 적용되는 모든 불이익이 그대로 적용된다. 다른 객체를 참조하지는 못하지만, 참조된 객체 자체는 수정될 수 있으니 끔찍할 결과를 초래할 수도 있는 것이다.
길이가 0이 아닌 배열은 모두 변경 가능하니 주의하자. 따라서 클래스에서 public static final 배열 필드를 두거나 이 필드를 반환하는 접근자 메소드를 제공해서는 안된다.
// 보안 허점이 숨어있다.
public static final Thing[] VALUES = {....};
어떤 IDE가 생성하는 접근자는 private 배열 필드의 참조를 반환하여 이 같은 문제를 일으키니 주의하자.
해결책 하나.
앞 코드의 public 배열을 private으로 만들고 public 불변 리스트를 추가하는 것이다.
private static final Thing[] PRIVATE_VALUES = {...};
public static final List<Thing> VALUES =
Collections.unmodifiableList(Arrays.asList(PRIVATE_VALUES));
해결책 둘.
배열을 private으로 만들고 그 복사본을 반환하는 public 메소드를 추가하는 방법이다. (방어적 복사)
private static final Thing[] PRIVATE_VALUES = {...};
public static final Thing[] values() {
return PRIVATE_VALUES.clone();
}
핵심 정리
프로그램 요소의 접근성은 가능한 한 최소한으로 하라. 꼭 필요한 것만 골라 최소한의 public API를 설계하자. 그 외에는 클래스, 인터페이스, 멤버가 의도치 않게 API로 공개되는 일이 없어야 한다. public 클래스는 상수용 public static final 필드 외에는 어떠한 public 필드도 가져서는 안된다. public static final 필드가 참조하는 객체가 불변인지 확인하라.
[아이템 16] public 클래스에서는 public 필드가 아닌 접근자 메서드를 사용하라
퇴보한 클래스는 public 접근자를 가져서는 안된다.
class Point{
public double x;
public double y;
}
접근자와 변경자(mutator) 메소드를 활용해 데이터를 캡슐화 해보자.
class Point{
private double x;
private double y;
public double getX(){
return x;
}
....
public void setX(double x){
this.x = x;
}
....
}
public 클래스라면 이 방식이 확실히 맞다. 패키지 바깥에서 접근할 수 있는 클래스라면 접근자를 제공함으로써 클래스 내부 표현 방식을 언제든 바꿀수 있는 유연성을 얻을 수 있다. public 클래스가 필드를 공개하면 이를 사용하는 클라이언트가 생겨날 것이므로 내부 표현 방식을 마음대로 바꿀 수 없게 된다.
하지만 package-private 클래스 혹은 private 중첩 클래스라면 데이터 필드를 노출한다 해도 하등의 문제가 없다.
불변 클래스를 노출한 public 클래스
public final class Time{
private static final int HOURS_PER_DAY = 24;
private static final int MINUTES_PER_HOUR = 60;
public final int hour;
public final int minute;
public Time(int hour, int minute){
if(hour < 0 || hour >= HOURS_PER_DAY) {Exception};
....
this.hour = hour;
this.minute = minute;
}
....
}
public 클래스의 필드가 불변이라면 직접 노출할 때의 단점이 조금은 줄어들지만, 여전히 좋은 생각이 아니다. API를 변경하지 않고는 표현 방식을 바꿀 수 없고, 필드를 읽을 때 부수 작업을 수행할 수 없다는 단점은 여전하다. 단, 불변식은 보장할 수 있게 된다. 과연 좋은 클래스일지는 모르겠지만 말이다.
핵심 정리
public 클래스는 절대 가변 필드를 직접 노출해서는 안된다. 불변 필드라면 노출해도 덜 위허하지만 완전히 안심할 수는 없다. 하지만 package-private 클래스나 private 중첩 클래스에서는 종종 필드를 노출하는 편이 나을 때도 있다.
[아이템 17] 변경 가능성을 최소화하라
불변 클래스란 간단히 말해 그 인스턴스의 내부 값을 수정할 수 없는 클래스다. 불변 인스턴스에 간직된 정보는 고정되어 객체가 파괴되는 순간까지 절대 달라지지 않는다. 자바 플랫폼 라이브러리에도 다양한 불변 클래스가 있다. String, BigInteger, BigDecimal이 여기 속한다.
이 클래스들을 불변으로 설게한 데는 그럴만한 이유가 있다. 불변 클래스는 가변 클래스보다 설계하고 구현하고 사용하기 쉬우며, 오류가 생길 여지도 적고 훨씬 안전하다.
클래스를 불변으로 만드는 규칙 하나.
객체의 상태를 변경하는 메소드를 제공하지 않는다.(setter)
클래스를 불변으로 만드는 규칙 둘.
클래스를 확장할 수 없도록 한다. 하위 클래스에서 부주의하게 혹은 나쁜 의도로 객체의 상태를 변하게 만드는 사태를 막아준다. 상속을 막는 대표적인 방법은 클래스를 final로 선언하는 것이다.
클래스를 불변으로 만드는 규칙 셋.
모든 필드를 final로 선언한다. 시스템이 강제하는 수단을 이용해 설계자의 의도를 명확히 드러내는 방법이다. 새로 생성된 인스턴스를 동기화 없이 다른 스레드로 건네도 문제없이 동작하게끔 보장하는 데도 필요하다.
클래스를 불변으로 만드는 규칙 넷.
모든 필드를 private 으로 선언한다. 필드가 참조하는 가변 객체를 클라이언트에서 직접 접근해 수정하는 일을 막아준다. 기술적으로는 기본 타입 필드나 불변 객체를 참조하는 필드를 pulbic final로만 선언해도 불변 객체가 되지만, 이렇게 하면 다음 릴리스에서 내부 표현을 바꾸지 못하므로 권하지는 않는다.
클래스를 불변으로 만드는 규칙 다섯.
자신 외에는 내부의 가변 컴포넌트에 접근할 수 없도록 한다. 클래스에 가변 객체를 참조하는 필드가 하나라도 있다면 클라이언트에서 그 객체의 참조를 얻을 수 없도록 해야 한다. 이런 필드는 절대 클라이언트가 제공한 객체 참조를 가리키게 해서는 안되며, 접근자 메소드가 그 필드를 그대로 반환해서도 안된다. 생성자, 접근자, readObject 메소드 모두에서 방어적 복사를 수행하라.
불변 객체의 장점 하나.
불변 객체는 단순하다. 불변 객체는 생성된 시점의 상태를 파괴될 때까지 그대로 간직한다.
불변 객체의 장점 둘.
불변 객체는 근본적으로 쓰레드에 안전하여 따로 동기화할 필요가 없다. 여러 쓰레드가 동시에 사용해도 절대 훼손되지 않는다.
불변 객체의 장점 셋.
불변 객체는 안심하고 공유할 수 있다. 그 어떤 쓰레드도 다른 쓰레드에 영향을 줄 수 없기 때문이다.
불변 객체의 장점 넷.
불변 객체는 자유롭게 공유할 수 있음은 물론, 불변 객체끼리는 내부 데이터를 공유할 수 있다.
불변 객체의 장점 다섯.
겍체를 만들 때 다른 불변 객체들을 구성요소로 사용하면 이점이 많다. 값이 바뀌지 않는 구성요소들로 이뤄진 객체라면 그 구조가 아무리 복잡하더라도 불변식을 유지하기 훨씬 수월하기 때문이다.
불변 객체의 장점 여섯.
불변 객체는 그 자체로 실패 원자성을 제공한다. 상태가 절대 변하지 않으니 잠깐이라도 불일치 상태에 빠질 가능성이 없다.
여기서 실패 원자성이란 메소드에서 예외가 발생하더라도 그 객체는 여전히 유효한 상태여야 한다는 성질이다.
불변 객체의 단점 하나.
값이 다르면 반드시 독립된 객체로 만들어야 한다. 값이 가짓수가 많다면 이들을 모두 만드는 데 큰 비용을 치러야 한다. 예컨대 백만 비트짜리 BigInteger에서 비트 하나를 바꿔야 한다고 해보자.
BigInteger moby = ...;
moby = moby.flipBit(0);flipBit 메소드는 새로운 BigInteger 인스턴스를 생성한다. 원본과 단지 한 비트만 다른 백만 비트짜리 인스턴스를 말이다. 이 연산은 BigInteger의 크기에 비례해 시간과 공간을 잡아먹는다. BitSet도 BigInteger처럼 임의 길이의 비트 순열을 표현하지만, BigInteger와는 달리 가변이다. BitSet 클래스는 원하는 비트 하나만 상수 시간 안에 바꿔주는 메소드를 제공한다.
BitSet moby = ...;
moby.flip(0);
핵심 정리
- 클래스는 꼭 필요한 경우가 아니라면 불변이여야 한다.
- 불변으로 만들 수 없는 클래스라도 변경할 수 있는 부분을 최소한으로 줄이자.
- 다른 합당한 이유가 없다면 모든 필드는 private final이어야 한다.
- 생성자는 불변식 설정이 모두 완료된, 초기화가 완벽히 끝난 상태의 객체를 생성해야 한다.
[아이템 18] 상속보단 컴포지션을 사용하라
상속은 코드를 재사용하는 강력한 수단이다. 하지만, 잘못 사용하면 오류를 내기 쉬운 소프트웨어를 만들게 된다.
상속은 클래스가 다른 클래스를 확장하는 구현 상속을 말하는 것이며, 클래스가 인터페이를 구현하거나 인터페이스가 다른 인터페이스를 확장하는 인터페이스 상속에 대한 이야기는 아니다.
상위 클래스는 릴리스마다 내부 구현이 달라질 수 있으며, 그 여파로 코드 한 줄 건드리지 않은 하위 클래스가 오작동할 수 있다.
잘못된 상속
public class InstrumentedHashSet<E> extends HashSet<E> {
// 추가된 원소의 수
private int addCount = 0;
public InstrumentedHashSet(){}
public InstrumentedHashSet(int initCap, float loadFactor){
super(initCap, loadFactor);
}
@Override
public boolean add(E e) {
addCount++;
return super.add(e);
}
@Override
public boolean addAll(Collection<? extends E> c) {
addCount += c.size();
return super.addAll(c);
}
public int getAddCount() {
return addCount;
}
}
InstrumentedHashSet<String> s = new InstrumentedHashSet<>();
s.addAll(List.of("틱", "탁탁", "펑"));
위와 같이 InstrumentedHashSet을 구현하고, addAll을 해주면 getAddCount()의 결과가 3을 반환하리라 생각하겠지만 6을 반환한다.
그 이유는 기존 HashSet의 addAll메서드 내부에서 add메서드를 호출한다는 것이다. 그 결과 addAll에서 3이 증가하고, 각 원소 마다 add가 호출되어 총 3번의 add가 실행되고 총 6이 되는 것이다.
위의 문제는 재정의에서 문제가 발생하였다. 그렇다면 재정의 대신 새로운 메서드를 추가하면 괜찮을까? 훨씬 안전한 방식은 맞지만, 위험은 여전히 있다.
다음 릴리즈에서 상위 클래스에 새로운 메서드가 추가 되었는데, 우연히도 하위 클래스에 추가한 메소드와 동일하지만 반환 타입이 다르다면 컴파일조차 되지 않을 것이다. 이 외에도 다양하게 추가한 메소드는 상위 클래스의 메소드가 요구하는 규약을 만족하지 못할 가능성이 크다.
상속 대신 컴포지션
import java.util.Collection;
import java.util.Set;
public class InstrumentedSet<E> extends ForwardingSet<E> {
private int addCount = 0;
public InstrumentedSet(Set<E> s) {
super(s);
}
@Override
public boolean add(E e) {
addCount++;
return super.add(e);
}
@Override
public boolean addAll(Collection<? extends E> c) {
addCount += c.size();
return super.addAll(c);
}
public int getAddCount() {
return addCount;
}
}
재사용할 수 있는 전달 클래스
import java.util.Collection;
import java.util.Iterator;
import java.util.Set;
public class ForwardingSet<E> implements Set<E> {
private final Set<E> s;
public ForwardingSet(Set<E> s) {
this.s = s;
}
public void clear() {
s.clear();
}
public boolean contains(Object o) {
return s.contains(o);
}
public boolean isEmpty() {
return s.isEmpty();
}
public int size() {
return s.size();
}
public Iterator<E> iterator() {
return s.iterator();
}
public boolean add(E e) {
return s.add(e);
}
public boolean remove(Object o) {
return s.remove(o);
}
public boolean containsAll(Collection<?> c) {
return s.containsAll(c);
}
public boolean addAll(Collection<? extends E> c) {
return s.addAll(c);
}
public boolean removeAll(Collection<?> c) {
return s.removeAll(c);
}
public boolean retainAll(Collection<?> c) {
return s.retainAll(c);
}
public Object[] toArray() {
return s.toArray();
}
public <T> T[] toArray(T[] a) {
return s.toArray(a);
}
@Override
public boolean equals(Object o) {
return s.equals(o);
}
@Override
public int hashCode() {
return s.hashCode();
}
@Override
public String toString() {
return s.toString();
}
}
InstrumentedSet은 HashSet의 모든 기능을 정의한 Set 인터페이스를 활용해 설계되어 견고하며 유연성이 높다.
위 코드에서 Set 인터페이스를 구현했고, Set의 인스턴스를 인수로 받는 생성자를 하나 제공한다. 임의의 Set에 계측 기능을 덧씌워 새로운 Set으로 만드는 것이 이 클래스의 핵심이다.
다른 Set인스턴스를 감싸고 있다는 뜻에서 InstrumentedSet은 래퍼 클래스라 하며, 다른 Set에 계측 기능을 덧씌운다는 뜻에서 데코레이터 패턴(Decorator pattern)이라고 한다. 래퍼 클래스는 단점이 거의 없다. 단, 콜백 프레임워크와는 어울리지 않다.
그 이유는 자신의 참조를 다른 객체에 넘겨서 다음 호출(콜백) 때 사용하도록 한 콜백 프래임워크에서 내부 객체는 자신을 감싸고 있는 래퍼의 존재를 모르니 자신의 참조를 넘기고, 콜백 때는 래퍼가 아닌 내부 객체를 호출하게 되기 때문이다.
상속을 쓰기전 고려사항 하나.
확장하려는 클래스의 API에 아무런 결함이 없는가?
상속을 쓰기전 고려사항 둘.
결함이 있다면, 이 결함이 새로운 클래스의 API까지 전파돼도 괜찮은가?
컴포지션으로는 이런 결함을 숨기는 새로운 API를 설계할 수 있지만, 상속은 상위 클래스의 API를 그 결함까지 그대로 승계한다.
핵심 정리
상속은 강력하지만 캡슐화를 해친다는 문제가 있다. 상속은 상위 클래스와 하위 클래스가 순수한 is-a 관계일 때만 써야한다. is-a 관계일 때도 안심할 수만은 없는 게, 하위 클래스의 패키지가 상위 클래스와 다르고, 상위 클래스가 확장을 고려해 설계되지 않았다면 여전히 문제가 될 수 있다. 상속의 취약점을 피하려면 상속 대신 컴포지션과 전달을 사용하자.
특히 래퍼 클래스로 구현할 적당한 인터페이스가 있다면 더욱 그렇다. 래퍼 클래스는 하위 클래스보다 견고하고 강력하다.
'books > 이펙티브 자바 3판' 카테고리의 다른 글
| [이펙티브 자바 : 2장] 모든 객체의 공통 메소드 (0) | 2020.06.27 |
|---|---|
| [이펙티브 자바 : 1장] 객체 생성과 파괴 (0) | 2020.06.27 |
댓글