혜성처럼 빛나는 정보

자바에서 문자열은 가장 많이 쓰이는 타입 중 하나가 아닐까 싶다. 그만큼 적절하게 사용하는 방법을 알아 둔다면 큰 도움이 될 수 있다. 이번에는 어떠한 경우에 문자열 사용을 피해야 하는지와 문자열 연결에서 주의해야 할 점을 알아보자.

문자열은 다른 값 타입을 대신하기에 적합하지 않다. 많은 사람이 파일, 네트워크, 키보드 입력으로부터 데이터를 받을 때 주로 문자열을 사용한다. 자연스러워 보이지만, 입력받을 데이터가 진짜 문자열일 때만 그렇게 하는 게 좋다. 받은 데이터가 수치형이라면 int, float, BigInteger 등 적당한 수치 타입으로 변환해야 한다. 예나 아니요 같은 질문의 답이라면 적절한 열거 타입이나 boolean으로 변환해야 한다. 일반화해 이야기하자면 기본 타입이든 참조 타입이든 적절한 값 타입이 있다면 그것을 사용하고 없다면 새로 하나 작성하자. 의외로 지켜지지 않는 경우가 많다. 문자열은 열거 타입을 대신하기에 적합하지 않다. 상수를 열거할 때는 문자열보다는 열거 타입이 월등히 낫다. 문자열은 혼합 타입을 대신하기에 적합하지 않다. 여러 요소가 혼합된 데이터를 하나의 문자열로 표현하는 것은 대체로 좋지 않은 생각이다. 예를 들어 "String compoundKey = className + "#" + i.next();" 와 같은 방식은 단점이 많은 방식이다. 혹여라도 두 요소를 구분해주는 문자 #이 두 요소 중 하나에서 쓰였다면 혼란스러운 결과를 초래한다. 각 요소를 개별로 접근하려면 문자열을 파싱해야 해서 느리고, 귀찮고, 오류 가능성도 커진다. 적절한 equals, toString, compareTo 메서드를 제공할 수 없으며, String이 제공하는 기능에만 의존해야 한다. 그래서 차라리 전용 클래스를 새로 만드는 편이 낫다. 이런 클래스는 보통 private 정적 멤버 클래스로 선언한다. 문자열은 권한을 표현하기에 적합하지 않다. 권한을 문자열로 표현하는 경우가 종종 있다. 예를 들어 스레드 지역변수 기능을 설계한다고 해보자. 그 이름처럼 각 스레드가 자신만의 변수를 갖게 해주는 기능이다. 자바가 이 기능을 지원하기 시작한 때는 자바 2부터로, 그전에는 프로그래머가 직접 구현해야 했다. 그 당시 이 기능을 설계해야 했던 여러 프로그래머가 독립적으로 방법을 모색하다가 종국에는 똑같은 설계에 이르렀다. 바로 클라이언트가 제공한 문자열 키로 스레드별 지역변수를 식별한 것이다. 이 방식의 문제는 스레드 구분용 문자열 키가 전역 이름공간에서 공유된다는 점이다. 이 방식이 의도대로 동작하려면 각 클라이언트가 고유한 키를 제공해야 한다. 그런데 만약 두 클라이언트가 서로 소통하지 못해 같은 키를 쓰기로 결정한다면, 의도치 않게 같은 변수를 공유하게 된다. 결국 두 클라이언트 모두 제대로 기능하지 못할 것이다. 보안도 취약하다. 악의적인 클라이언트라면 의도적으로 같은 키를 사용하여 다른 클라이언트의 값을 가져올 수도 있다. 이 API는 문자열 대신 위조할 수 없는 키를 사용하면 해결된다. 이 키를 권한이라고도 한다. 이렇게 키를 사용하는 방법은 문자열 기반 API의 문제 두 가지를 모두 해결해주지만, 개선할 여지가 있다. 고민해보자. 

문자열에 대한 또 다른 이야기를 해보자. 자주 사용하는 문자열 연산에 관한 이야기이다. 문자열 연결 연산자(+)는 여러 문자열을 하나로 합쳐주는 편리한 수단이다. 그런데 한 줄짜리 출력값 혹은 작고 크기가 고정된 객체의 문자열 표현을 만들 때라면 괜찮지만, 본격적으로 사용하기 시작하면 성능 저하를 감내하기 어렵다. 문자열 연결 연산자로 문자열 n개를 잇는 시간은 n 제곱에 비례한다. 문자열은 불변이라서 두 문자열을 연결할 경우 양쪽의 내용을 모두 복사해야 하므로 성능 저하는 피할 수 없는 결과다. 예를 들어 다음 메서드는 청구서의 품목을 전부 하나의 문자열로 연결해준다.

public String statement() {
	String result = "";
	for (int i = 0; i < numItems(); i++)
		result += lineForItem(i);
	return result;
}

품목이 많을 경우 이 메서드는 심각하게 느려질 수 있다. 성능을 포기하고 싶지 않다면 String 대신 StringBuilder를 사용하자.

public String statementWithStringBuilder() {
	StringBuilder sb = new StringBuilder(numItems() * LINE_WIDTH);
	for (int i = 0; i < numItems(); i++)
		sb.append(lineForItem(i));
	return sb.toString();
}

자바 6 이후 문자열 연결 성능을 다방면으로 개선했지만, 이 두 메서드의 성능 차이는 여전히 크다. 품목을 100개로 하고 lineForItem이 길이 80인 문자열을 반환하게 하여 테스트해보니 StringBuilder를 사용했을 때가 6.5배나 빨랐다. statement 메서드의 수행 시간은 품목 수의 제곱이 비례해 늘어나고 StringBuilder를 사용했을 경우는 선형으로 늘어나므로, 품목 수가 늘어날수록 성능 격차도 점점 벌어질 것이다. StringBuilder를 사용한 예제에서 StringBuilder를 선언할 때, 전체 결과를 담기에 충분한 크기로 초기화한 점을 잊지 말자. 하지만 기본값을 사용하더라도 여전히 5.5배나 빠르다.

요약하자면,

더 적합한 데이터 타입이 있거나 새로 작성할 수 있다면, 문자열을 쓰고 싶은 유혹을 뿌리치자. 또한 문자열 연결에 대한 원칙은 간단하다. 성능에 신경 써야 한다면 많은 문자열을 연결할 때는 문자열 연결 연산자(+)를 피하자. 대신 StringBuilder의 append 메서드를 사용하라. 문자 배열을 사용하거나 문자열을 연결하지 않고 하나씩 처리하는 방법도 있다.

자바를 사용하면서 primitive타입과 primitive타입에 대응하는 래핑된 object 타입 중 어떤 것을 선택할지는 간단해 보이지만, 중요한 문제이다. 기본적으로 성능을 생각하면 heap 영역에 영향이 없는 primitive 타입을 선택하지만, 어쩔 수 없이 (없는 값의 기본을 null로 해야 명세에 부합하여 사이드 이펙트가 없을 때) 래퍼 클래스를 사용하는 경우도 있었다. 이번에는 이 부분에 대해 더 자세히 알아보자.

자바에서는 int, double, boolean과 같은 기본 타입에 대응하는 박싱된 기본 타입 (Integer, Double, Boolean 등) 들이 있다. 오토박싱과 오토언박싱 덕분에 두 타입을 크게 구분하지 않고 사용할 수는 있지만, 차이가 사라지는 것은 아니다. 둘 사이에는 분명한 차이가 있으니 어떤 타입을 사용하는지는 상당히 중요하다. 주의해서 선택해야 한다는 말이다. 기본 타입과 박싱된 기본 타입의 주된 차이는 크게 세 가지다. 첫 번째, 기본 타입은 값만 가지고 있으나, 박싱된 기본 타입은 값에 더해 식별성이란 속성을 갖는다. 달리 말하면 박싱된 기본 타입의 두 인스턴스는 값이 같아도 서로 다르다고 식별될 수 있다. 두 번째, 기본 타입의 값은 언제나 유효하나, 박싱된 기본 타입은 유효하지 않은 값, 즉 null을 가질 수 있다. 세 번째, 기본 타입이 박싱된 기본 타입보다 시간과 메모리 사용 면에서 더 효율적이다. 이상의 세 가지 차이 때문에 주의하지 않고 사용하면 진짜로 문제가 발생할 수 있다. Integer값을 오름차순으로 정렬하는 비교자를 보자. Integer는 그 자체로 순서가 있으니 이 비교자가 실질적인 의미는 없지만, 흥미로운 점을 하나 보여준다.

Comparator<Integer> naturalOrder = (i, j) -> (i < j) ? -1 : (i == j ? 0 : 1);

별다른 문제를 찾기 어렵고, 실제로 이것저것 테스트해봐도 잘 통과한다. 예컨대 Collections.sort에 원소 백만 개짜리 리스트와 이 비교자를 넣어 돌려도 아무 문제가 없다. 리스트에 중복이 있어도 상관없다. 하지만 심각한 결함이 숨어 있으니 이 결함을 눈으로 확인하고 싶다면 naturalOrder.compare(new Integer(42), new Integer(42))의 값을 출력해보자. 두 Integer 인스턴스의 값이 42로 같으므로 0을 출력해야 하지만, 실제로는 1을 출력한다. 즉, 첫 번째 Integer가 두 번째보다 크다고 주장한다. 원인이 뭘까? naturalOrder의 첫 번째 검사(i <j)는 잘 작동한다. 여기서 i와 j가 참조하는 오토박싱된 Integer 인스턴스는 기본 타입 값으로 변환된다. 그런 다음 첫 번째 정숫값이 두 번째 값보다 작은지를 평가한다. 만약 작지 않다면 두 번째 검사(i == j)가 이뤄진다. 그런데 이 두 번째 검사에서는 두 객체 참조의 식별성을 검사하게 된다. 비록 값은 같더라도 i와 j가 서로 다른 Integer 인스턴스라면 이 비교의 결과는 false가 되고, 비교자는 1을 반환한다. 즉, 첫 번째 Integer 값이 두 번째보다 크다는 것이다. 이처럼 박싱된 기본 타입에 == 연산자를 사용하면 오류가 일어난다. 실무에서 이와 같이 기본 타입을 다루는 비교자가 필요하다면 Comparator.naturalOrder()를 사용하자. 비교자를 직접 만들면 비교자 생성 메서드나 기본 타입을 받는 정적 compare 메서드를 사용해야 한다. 그렇더라도 이 문제를 고치려면 지역변수 2개를 두어 각각 박싱된 Integer 매개변수의 값을 기본 타입 정수로 저장한 다음, 모든 비교를 이 기본 타입 변수로 수행해야 한다. 이렇게 하면 오류의 원인인 식별성 검사가 이뤄지지 않는다.

Comparator<Integer> naturalOrder = (iBoxed, jBoxed) -> {
	int i = iBoxed, j = jBoxed;
	return i < j ? -1 : (i == j ? 0 : 1);
};

Integer와 int를 비교할때를 보면, 거의 예외 없이 기본 타입과 박싱된 기본 타입을 혼용한 연산에서는 박싱된 기본 타입의 박싱이 자동으로 풀린다. 그리고 null 참조를 언박싱하면 NullPointerException이 발생한다. 이 예에서 보듯, 이런 일은 어디서든 벌어 질 수 있다. 해법은 i를 int로 바꿔주면 된다. 또한, 실수로 for문을 돌면서 더하는 연산을 할때, sum의 값을 박싱된 기본 타입으로 선언하면 박싱과 언박싱이 반복해서 일어나기 때문에, 치명적으로 느려지는것을 체감할 수 있다. 모든 문제의 원인은 하나다. 프로그래머가 기본 타입과 박싱된 기본 타입의 차이를 무시한 대가를 치른 것이다. 그렇다면 박싱된 기본 타입은 언제 써야 하는가? 적절히 쓰이는 경우가 몇 가지 있다. 첫 번째, 컬렉션의 원소, 키, 값으로 쓴다. 컬렉션은 기본 타입을 담을 수 없으므로 어쩔 수 없이 박싱된 기본 타입을 써야만 한다. 더 일반화해 말하면, 매개변수화 타입이나 매개변수화 메서드의 타입 매개변수로는 박싱된 기본 타입을 써야 한다. 자바 언어가 타입 매개변수로 기본 타입을 지원하지 않기 때문에다. 예컨대 변수를 ThreadLocal<int> 타입으로 선언하는 건 불가능하며, 대신 ThreadLocal<Integer>를 써야 한다. 마지막으로, 리플렉션을 통해 메서드를 호출할 때도 박싱된 기본 타입을 사용해야 한다.

요약하자면,

기본 타입과 박싱된 기본 타입 중 하나를 선택해야 한다면 가능하면 기본 타입을 사용하라. 기본 타입은 간단하고 빠르다. 박싱된 기본 타입을 써야 한다면 주의를 기울이자. 오토박싱이 박싱된 기본 타입을 사용할 때의 번거로움을 줄여주지만, 그 위험까지 없애주지는 않는다. 두 박싱된 기본 타입을 == 연산자로 비교한다면 식별성 비교가 이뤄지는데, 이는 원한 게 아닐 가능성이 크다. 같은 연산에서 기본 타입과 박싱된 기본 타입을 혼용하면 언박싱이 이뤄지며, 언박싱 과정에서 NullPointerException을 던질 수 있다. 마지막으로, 기본 타입을 박싱하는 작업은 필요 없는 객체를 생성하는 부작용을 낳을 수 있다.

출처: 이펙티브 자바 3판

개발을 하면서 항상 정답이 안보이는 메서드 시그니처에 관한 이야기

메서드 이름을 신중히 짓자. 항상 표준 명명 규칙을 따르자. 이해할 수 있고, 같은 패키지에 속한 다른 이름들과 일관되게 짓는 게 최우선 목표다. 그다음 목표는 개발자 커뮤니티에서 널리 받아들여지는 이름을 사용하는 것이다. 긴 이름은 피하자. 애매하면 자바 라이브러리의 API 가이드를 참조하자. 자바 라이브러리가 워낙 방대하다 보니 일관되지 않은 이름도 제법 많이 있지만, 대부분은 납득할 만한 수준이다. 편의 메서드를 너무 많이 만들지 말자. 모든 메서드는 각각 자신의 소임을 다해야 한다. 메서드가 너무 많은 클래스는 익히고, 사용하고, 문서화하고, 테스트하고, 유지보수하기 어렵다. 인터페이스도 마찬가지다. 메서드가 너무 많으면 이를 구현하는 사람과 사용하는 사람 모두를 고통스럽게 한다. 클래스나 인터페이스는 자신의 각 기능을 완벽히 수행하는 메서드로 제공해야 한다. 아주 자주 쓰일 경우에만 별도의 약칭 메서드를 두자. 확신이 서지 않으면 만들지 말자. 매개변수 목록은 짧게 유지하자. 최대 4개 이하가 좋다. 일단 4개가 넘어가면 매개변수를 전부 기억하기가 쉽지 않다. API에 이 제한을 넘는 메서드가 많다면 프로그래머들은 API 문서를 옆에 끼고 개발해야 할 것이다. IDE를 사용하면 수고를 많이 덜 수 있지만, 여전히 매개변수 수는 적은 쪽이 훨씬 낫다. 같은 타입의 매개변수 여러 개가 연달아 나오는 경우가 특히 위험하다. 사용자가 매개변수 순서를 기억하기 어려울뿐더러, 실수로 순서를 바꿔 입력해도 그대로 컴파일되고 실행된다. 단지 의도와 다르게 동작할 뿐이다. 과하게 긴 매개변수 목록을 짧게 줄여주는 기술 세 가지가 있다. 첫 번째, 여러 메서드로 쪼갠다. 쪼개진 메서드 각각은 원래 매개변수 목록의 부분집합을 받는다. 잘못하면 메서드가 너무 많아질 수 있지만, 공통점이 없는 기능들이 분리되고 기능을 원자적으로 쪼개 제공함으로서 오히려 메서드 수를 줄여주는 효과도 있다. java.util.List 인터페이스가 좋은 예다. 리스트에서 주어진 원소의 인덱스를 찾아야 하는데, 전체 리스트가 아니라 지정된 범위의 부분리스트에서의 인덱스를 찾는다고 해보자. 이 기능을 하나의 메서드로 구현하려면 부분리스트의 시작, 부분리스트의 끝, 찾을 원소까지 총 3개의 매개변수가 필요하다. 그런데 List는 그 대신 부분리스트를 반환하는 subList 메서드와 주어진 원소의 인덱스를 알려주는 indexOf 메서드를 별개로 제공한다. subList가 반환한 부분리스트 역시 완벽한 List이므로 두 메서드를 조합하면 원하는 목적을 이룰 수 있다. 결과적으로 강함과 유연함이 절묘하게 균형을 이룬 API가 만들어진 것이다. 매개변수 수를 줄여주는 기술 두 번째는 매개변수 여러 개를 묶어주는 클래스를 만드는 것이다. 이런 클래스는 정적 맴버 클래스로 둔다. 특히 잇따른 매개변수 몇 개를 독립된 하나의 개념으로 볼 수 있을 때 추천하는 기법이다. 예를 들어 카드게임을 클래스로 만든다고 해보자. 그러면 메서드를 호출할 때 카드의 숫자와 무늬를 뜻하는 두 매개변수를 항상 같은 순서로 전달할 것이다. 따라서 이 둘을 묶는 클래스를 만들어 하나의 매개변수로 주고받으면 API는 물론 클래스 내부 구현도 깔끔해질 것이다. 세 번째는 앞서의 두 기법을 혼합한 것으로, 객체 생성에 사용한 빌더 패턴을 메서드 호출에 응용한다고 보면 된다. 이 기법은 매개변수가 많을 때, 특히 그 중 일부는 생략해도 괜찮을 때 도움이 된다. 먼저 모든 매개변수를 하나로 추상화한 객체를 정의하고, 클라이언트에서 이 객체의 세터 메서드를 호출해 필요한 값을 설정하게 하는 것이다. 이때 각 세터 메서드는 매개변수 하나 혹은 서로 연관된 몇 개만 설정하게 한다. 클라이언트는 먼저 필요한 매개변수를 다 설정한 다음, execute 메서드를 호출해 앞서 설정한 매개변수들의 유효성을 검사한다. 마지막으로, 설정이 완료된 객체를 넘겨 원하는 계산을 수행한다. 매개변수의 타입으로는 클래스보다는 인터페이스가 더 낫다. 매개변수로 적합한 인터페이스가 있다면 그 인터페이스를 직접 사용하자. 예를 들어 메서드에 HashMap을 넘길 일은 전혀 없다. 대신 Map을 사용하자. 그러면 HashMap뿐 아니라 TreeMap, ConcurrentHashMap, TreeMap의 부분맵 등 어떤 Map 구현체도 인수로 건넬 수 있다. 심지어 아직 존재하지 않는 Map도 가능하다. 인터페이스 대신 클래스를 사용하면 클라이언트에게 특정 구현체만 사용하도록 제한하는 꼴이며, 혹시라도 입력 데이터가 다른 형태로 존재한다면 명시한 특정 구현체의 객체로 옮겨 담느라 비싼 복사 비용을 치러야 한다. 또한 boolean보다는 원소 2개짜리 열거 타입이 낫다. 열거 타입을 사용하면 코드를 일고 쓰기가 더 쉬워진다. 나중에 선택지를 추가하기도 쉽다. 예를 들어 화씨온도와 섭씨온도를 원소로 정의한 열거 타입이 있을때, 온도계 클래스의 정적 팩터리 메서드가 이 열거 타입을 입력받아 적합한 온도계 인스턴스를 생성해준다고 해보자. 이럴때 확실히 열거 타입을 명시하는게 객체를 생성할때 하는 일을 명확히 알려준다. 또한, 온도 단위에 대한 의존성을 개별 열거 타입 상수의 메서드 안으로 리팩터링해 넣을 수도 있다. 예컨대 double 값을 받아 섭씨온도로 변환해주는 메서드를 열거 타입 상수 각각에 정의해둘 수도 있다.

요약하자면,

우선순위를 따지자면, 같은 패키지에 속한 다른 이름들과 일관되게 표준 명명규칙을 따르는게 첫번째다.

애매하면, 자바 라이브러리를 확인하거나 다른 유명한 오픈소스를 참조하자. 매개변수는 4개 이하로 만들자. 매개변수 타입은 인터페이스가 좋다.

출처: 이펙티브 자바 3판

자바는 안전한 언어이긴 하지만, 더욱 안전하게 사용하기 위해 지켜야 할 것들이 많다. 이번 글은 자바를 더욱 안전하게 사용하기 위한 가이드이다.

자바는 C, C++ 같은 언어에서 흔히 보이는 버퍼 오버런, 배열 오버런, 와일드 포인터 같은 메모리 충돌 오류에서 안전하다. 자바로 작성한 클래스는 시스템의 다른 부분에서 무슨 짓을 하든 그 불변식이 지켜진다. 메모리 전체를 하나의 거대한 배열로 다루는 언어에서는 누릴 수 없는 강점이다. 하지만 아무리 자바라 해도 다른 클래스로부터의 침범을 아무런 노력 없이 다 막을 수 있는 건 아니다. 그러니 클라이언트가 불변식을 깨뜨리려 혈안이 되어 있다고 가정하고 방어적으로 프로그래밍해야 한다. 실제로도 악의적인 의도를 가진 사람들이 시스템의 보안을 뚫으려는 시도가 늘고 있다. 평범한 프로그래머도 순전히 실수로 클래스를 오작동하게 만들 수 있다. 어떤 경우든 적절치 않은 클라이언트로부터 클래스를 보호하는데 충분한 시간을 투자하는 게 좋다. 어떤 객체든 그 객체의 허락 없이는 외부에서 내부를 수정하는 일은 불가능하다. 하지만 주의를 기울이지 않으면 자기도 모르게 내부를 수정하도록 허락하는 경우가 생긴다. 예를 들어, 기간을 표현하는 Period클래스는 얼핏 불변처럼 보이지만, Date자체가 가변적이기 때문에 불변식을 깨뜨릴 수 있다. 다행히 자바 8 이후로는 Date 대신 불변인 Instant, LocalDateTime, ZonedDateTime을 사용하면 된다. Date는 낡은 API이니 새로운 코드를 작성할 때는 더 이상 사용하면 안 된다. 하지만 앞으로 쓰지 않는다고 이 문제에서 해방되는 건 아니다. Date처럼 가변인 낡은 값 타입을 사용하던 시절이 워낙 길었던 탓에 여전히 많은 API와 내부 구현에 그 잔재가 남아 있다. 이번 아이템은 예전에 작성된 낡은 코드들을 대처하기 위한 것이다. 외부 공격으로부터 Period 인스턴스의 내부를 보호하려면 생성자에서 받은 가변 매개변수 각각을 방어적으로 복사해야 한다. 그런 다음 Period 인스턴스 안에서는 원본이 아닌 복사본을 사용한다. 이렇게 사용하면, 앞서 공격은 더 이상 Period에 위협이 되지 않는다. 매개변수의 유효성을 검사하기 전에 방어적 복사본을 만들고, 이 복사본으로 유효성을 검사한 점에 주목하자. 순서가 부자연스러워 보이겠지만 반드시 이렇게 작성해야 한다. 멀티스레딩 환경이라면 원본 객체의 유효성을 검사한 후 복사본을 만드는 그 찰나의 취약한 순간에 다른 스레드가 원본 객체를 수정할 위험이 있기 때문이다. 방어적 복사를 매개변수 유효성 검사 전에 수행하면 이런 위험에서 해방될 수 있다. 컴퓨터 보안 커뮤니티에서는 이를 검사시점/사용 시점 공격 혹은 영어 표기를 줄여서 TOCTOU 공격이라 한다. 방어적 복사에 Date의 clone 메서드를 사용하지 않은 점에도 주목하자. Date는 final이 아니므로 clone이 Date가 정의한 게 아닐 수 있다. 즉, clone이 악의를 가진 하위 클래스의 인스턴스를 반환할 수도 있다. 예컨대 이 하위 클래스는 start와 end 필드의 참조를 private 정적 리스트에 담아뒀다가 공격자에게 이 리스트에 접근하는 길을 열어줄 수도 있다. 결국 공격자에게 Period 인스턴스 자체를 송두리째 맡기는 꼴이 된다. 이런 공격을 막기 위해서는 매개변수가 제3자에 의해 확장될 수 있는 타입이라면 방어적 복사본을 만들 때 clone을 사용해서는 안 된다. 생성자를 수정하면 앞서 공격은 막아낼 수 있지만, Period 인스턴스는 아직도 변경 가능하다. 접근자 메서드가 내부의 가변 정보를 직접 드러내기 때문이다. 새로운 접근자까지 갖추면 Period는 완벽한 불변으로 거듭난다. 아무리 악의적인 혹은 부주의한 프로그래머라도 시작 시각이 종료 시각보다 나중일 수 없다는 불변식을 위배할 방법은 없다. Period 자신 말고는 가변 필드에 접근할 방법이 없으니 확실하다. 모든 필드가 객체 안에 완벽하게 캡슐화되었다. 생성자와 달리 접근자 메서드에서는 방어적 복사에 clone을 사용해도 된다. Period가 가지고 있는 Date 객체는 java.util.Date임이 확실하기 때문이다. 그렇더라도 인스턴스를 복사하는 데는 일반적으로 생성자나 정적 팩터리를 쓰는게 좋다. 매개변수를 방어적으로 복사하는 목적이 불변 객체를 만들기 위해서만은 아니다. 메서드든 생성자든 클라이언트가 제공한 객체의 참조를 내부의 자료구조에 보관해야 할 때면 항시 그 객체가 잠재적으로 변경될 수 있는지를 생각해야 한다. 변경될 수 있는 객체라면 그 객체가 클래스에 넘겨진 뒤 임의로 변경되어도 그 클래스가 문제없이 동작할지를 따져보라. 확신할 수 없다면 복사본을 만들어 저장해야 한다. 예컨대 클라이언트가 건네준 객체를 내부의 Set 인스턴스에 저장하거나 Map 인스턴스의 키로 사용한다면, 추후 그 객체가 변경될 경우 객체를 담고 있는 Set 혹은 Map의 불변식이 깨질 것이다. 내부 객체를 클라이언트에 건네주기 전에 방어적 복사본을 만드는 이유도 마찬가지다. 클래스가 불변이든 가변이든, 가변인 내부 객체를 클라이언트에 반환할 때는 반드시 심사숙고해야 한다. 안심할 수 없다면 방어적 복사본을 반환해야 한다. 이상의 모든 작업에서 되도록 불변 객체들을 조합해 객체를 구성해야 방어적 복사를 할 일이 줄어든다는 교훈을 얻을 수 있다. 방어적 복사에는 성능 저하가 따르고, 항상 쓸 수 있는 것도 아니다. 호출자가 컴포넌트 내부를 수정하지 않으리라 확신하면 방어적 복사를 생략할 수 있다. 이러한 상황이라도 호출자에서 해당 매개변수나 반환 값을 수정하지 말아야 함을 명확히 문서화하는 게 좋다.



요약하자면,
클래스가 클라이언트로부터 받는 혹은 클라이언트로 반환하는 구성요소가 가변이라면 그 요소는 반드시 방어적으로 복사해야 한다. 복사 비용이 너무 크거나 클라이언트가 그 요소를 잘못 수정할 일이 없음을 신뢰한다면 방어적 복사를 수행하는 대신 해당 구성요소를 수정했을 때의 책임이 클라이언트에 있음을 문서에 명시하도록 하자.

출처: 이펙티브 자바 3판