이펙티브 자바, 쉽게 정리하기 - item 50. 적시에 방어적 복사본을 만들라

이펙티브 자바, 쉽게 정리하기 - item 50. 적시에 방어적 복사본을 만들라

클래스 내부 수정을 본의아니게 허락하는 경우

static class Period {
        private final Date start;
        private final Date end;

        public Period(Date start, Date end, int version) {
            if (start.compareTo(end) > 0) {
                throw new IllegalArgumentException(
                        start + "가 " + end + "보다 늦다."
                );
            }

            if(version == 1) {
                this.start = start;
                this.end = end;
            }
            else {
                // 방어적 복사본 만들기
                this.start = new Date(start.getTime());
                this.end = new Date(end.getTime());
            }
        }

        public Date start() {
           return start;
        }

        public Date end() {
           return end;
        }
    }

    @Test
    public void periodTestVer1() {
        Date start = new Date();
        start.setYear(2021);
        Date end = new Date();
        end.setYear(2022);

        Period p = new Period(start, end, 1);

        int endYear1 = p.end.getYear();
        Assertions.assertEquals(endYear1, 2022);

        end.setYear(2020); // p의 내부를 수정했다!

        int endYear2 = p.end.getYear();
        Assertions.assertEquals(endYear2, 2020);
    }

• private final Date 라고 잘 선언해주었지만, Date 내부의 필드들이 final 인지는 확인하지 않아서 문제가 생긴다.
  • start() 메서드나 end() 메서드에서 start 필드와 end 필드가 반환 가능하고, 내부 메서드를 통해 값도 수정이 가능하다.
  • Date 타입의 필드가 final 인거지 내부 필드가 final 이 아니다.
• Date 클래스 내부 필드가 가변이라서 의도와 다르게 값이 바뀔 수 있다.
• 자바 8 이후로는 간단히 LocalDateTime 혹은 ZonedDateTime 과 같은 불변 날짜 객체를 사용하면 간단히 해결되는 문제이다.

방어적 복사하기

// 방어적 복사본 만들기
this.start = new Date(start.getTime());
this.end = new Date(end.getTime());

• Period 생성자를 잘 보면 version 에 따라 동작이 달라지는데, version 이 1이 아닐 때는 방어적 복사본을 만든다.
• 파라미터로 입력받은 객체 필드의 내용을 이용해 그냥 새로운 객체를 만든다.
  • 이를 방어적 복사본을 만든다고 한다.

@Test
public void periodTestVer2() {
    Date start = new Date();
    start.setYear(2021);
    Date end = new Date();
    end.setYear(2022);

    Period p = new Period(start, end, 2);

    int endYear1 = p.end.getYear();
    Assertions.assertEquals(endYear1, 2022);

    end.setYear(2020); // p의 내부를 수정했다!

    int endYear2 = p.end.getYear();
    Assertions.assertEquals(endYear2, 2022);
}

• 방어적 복사본을 만든 결과 이제 원치 않는 내부 필드 변경이 일어나지 않는다.
• 파라미터로 준 Date end와 Period 내부에서 쓰는 Date end는 다른 객체이다.

접근자도 방어적 복사하기

public Date start() {
    return new Date(start.getTime());
}

public Date end() {
    return new Date(end.getTime());
}

• 접근자도 방어적 복사 방식으로 반환하면, 이제 더이상 객체가 변경될 우려를 할 필요가 없다
• 필드 자체를 반환하게 되면, 아무리 final 로 선언했더라도 내부 메서드를 통해 변환할 가능성이 있음을 인지하자

방어적 복사를 위한 clone() 사용 생각해보기

• 생성자에서 clone() 을 이용해 방어적 복사본을 생성하는 것은 위험하다.
  • 악의적으로 clone() 을 재정의한 하위 타입을 만날 수도 있다.
  • 누군가 clone() 이 재정의된 하위타입을 인자로 주거나 하는 식으로 이를 우회할 수 있다.
• 반면, 접근자 메서드에서 clone() 을 이용해 방어적 복사본을 생성하는 것은 괜찮다.
  • new Date() 를 새로 작성해줌으로써 우리는 해당 객체가 Date 타입일 것이란걸 알고 있기 때문이다.
  • 기존 필드에서 사용하는 객체가 아니라 clone() 에 의해 만들어진 새 객체를 내려주는 것이다.
  • 그럼에도 위에 말한 문제 때문에 clone()을 사용하는 것은 그다지 권장되진 않기 때문에, 생성자나 정적 팩터리 메서드를 사용하는 것이 더 권장된다.

방어적 복사를 생략해도 되는 상황

• 클래스와 클라이언트를 상호 신뢰할 수 있을 때
• 불변식이 깨지더라도 그 영향이 오직 클라이언트로 국한될 때

래퍼 클래스 패턴은 클라이언트는 래퍼에 넘긴 객체에 여전히 직접 접근할 수 있지만 그 영향을 오직 클라이언트 자신만 받게 된다.

핵심 정리

• 객체를 제공받을 때는 받아들인 객체가 변경되어도 정상적으로 작동할지 생각해보고 정상적으로 작동하지 않을 것 같다면, 잠재적으로 변경되지 않도록 방어적 복사를 하자.
  • 이러한 객체가 Set 혹은 Map에 들어간 뒤에 필드 값이 변경된다면, 불변식이 깨질 수도 있다.
• 되도록 기본 지원 불변 객체를 활용하자. (LocalDateTime)
• 방어적 복사를 하기에는 복사 비용이 너무 크다면, 문서에서 해당 요소를 수정했을 때의 책임은 클라이언트에게 있음을 명시해놓자.