클래스가 다른 클래스를 확장하는 구현 상속의 경우 확장할 목적으로 설계되었고 문서화도 잘 된 클래스(아이템 19)일 때는 안전하지만,

다른 패키지의 구체 클래스를 상속하는 것은 위험하다. (클래스가 인터페이스를 구현하거나 인터페이스가 다른 인터페이스를 확장하는 인터 페이스 상속은 상관 없음)

 

 

상속을 사용하지 않는 이유 중 하나는, 메서드 호출과 달리 상속은 캡슐화를 깨뜨린다. 

예를 들어, 상위 클래스는 릴리스마다 내부 구현이 달라질 수 있으며 , 그 여파로 하위 클래스가 오동작할 수 있다.

 

아래와 같이 HashSet을 상속하여 InstrumentedHashSet을 구현했다고 하자.

package com.example.sypark9646.item18;

import java.util.Collection;
import java.util.HashSet;

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의 addCount를 직접 접근한 값과 size를 가져오는 것에 대한 결과는 매우 다름을 알 수 있다.

package com.example.sypark9646.item18;

import java.util.List;
import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;

public class InstrumentedHashSetTest {

    @DisplayName("HashSet addAll override test")
    @Test
    void testInstrumentedHashSetTest() {
        InstrumentedHashSet<String> instrumentedHashSet = new InstrumentedHashSet<>();
        instrumentedHashSet.addAll(List.of("1", "2", "3"));

        Assertions.assertEquals(3, instrumentedHashSet.size());
        Assertions.assertEquals(3, instrumentedHashSet.getAddCount()); // 6
    }
}

 

이러한 결과가 나온 이유는, size의 경우 아래와 같이 map의 사이즈를 그대로 가져오기 때문에 제대로 된 크기가 나오는 것이다.

getAddCount의 경우는 addAll과 add에서 각각 값을 더하고 있다.

그런데, InstrumentedHashSet에서 상속하고 있는 addAll은 add 메서드를 사용하여 구현되어 있기 때문에 중복으로 값을 더하게 된다.

 

이 문제를 피하기 위한 근본적인 방법은 기존 클래스를 확장하는 대신, 새로운 클래스를 만들고 private 필드로 기존 클래스의 인스턴스를 참 조하는 `컴포지션` 방식이다. 새 클래스의 인스턴스 메서드들은 (private 필드로 참조하는) 기존 클래스의 대응하는 메서드를 호출 하여 그 결과를 반환(전달, forwarding)하기 때문에, 새로운 클래스는 기존 클래스의 내부 구현 방식의 영향에서 벗어나기 때문에 기존 클래스에 새로운 메서드가 추가되더라도 영향 받지 않는다. (ex. Guava는 모든 컬렉션 인터페이스용 전달 메서드를 전부 구현해뒀다)

그렇다면 위 InstrumentedHashSet을 컴포지션과 전달 방식으로 다시 구현해 보자.

package com.example.sypark9646.item18;

import java.util.Collection;
import java.util.Set;

public class InstrumentedHashSet<E> extends ForwardingSet<E> {

    private int addCount = 0;

    public InstrumentedHashSet(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;
    }
}

 

여기서 ForwardingSet은 전달 메서드만으로 이뤄진 재사용 가능한 전달 클래스이다.

package com.example.sypark9646.item18;

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();
    }
}
    @DisplayName("HashSet addAll Composition test")
    @Test
    void testCompositionInstrumentedHashSet() {
        InstrumentedHashSet<String> compositionInstrumentedHashSet = new InstrumentedHashSet<>(new TreeSet<>());
        compositionInstrumentedHashSet.addAll(List.of("1", "2", "3"));

        Assertions.assertEquals(3, compositionInstrumentedHashSet.size());
        Assertions.assertEquals(3, compositionInstrumentedHashSet.getAddCount());
    }

위의 ForwardingSet의 addAll은 set을 사용하고 있는데, 디버깅 해 보면 아래와 같이 사용한 Set의 인스턴스(TreeSet)의 addAll을 사용하게 되고, 

addAll이 add 메서드를 사용하더라도 TreeSet의 add 메서드를 사용하게 된다. (ForwardingSet의 add가 사용되는 것이 아님)

따라서 중복으로 addCount에 더해질 일이 없다.

 

다른 Set 인스턴스를 감싸고(wrap) 있다는 뜻에서 InstrumentedSet 같은 클래스를 래퍼 클래스라 하며,

다른 Set에 계측 기능을 덧씌운다는 뜻에서 데코레이터 패턴(Decorator pattern)이라고 한다.

2021/02/27 - [책을 읽자/Design Patterns] - Decorator Pattern

 

Decorator Pattern

 

sysgongbu.tistory.com

컴포지션과 전달의 조합은 넓은 의미로 위임(delegation)이라고 부른다. (래퍼 객체가 내부 객체에 자기 자신의 참조를 넘기는 경우)

래퍼 클래스는 단점이 거의 없다. 단, 래퍼 클래스가 콜백(callback) 프레임워크와는 어울리지 않는다는 점만 주의하면 된다.

콜백 프레임워크에서 는 자기 자신의 참조를 다른 객체에 넘겨서 다음 호출(콜백) 때 사용하도록 하는데, 내부 객체는 자신을 감싸고 있는 래퍼의 존재를 모르니 대신 자신(this)의 참조를 넘기고, 콜백 때는 래퍼가 아닌 내부 객체를 호출하게 된다. 이를 SELF 문제라고 한다.

 

 

상속은 반드시 하위 클래스가 상위 클래스의 `진짜` 하위 타입인 상황에서만 쓰여야 한다. (is-a 관계+상위 클래스가 확장을 고려해 설계 되었을 때)
자바 플랫폼 라이브러리에서 스택은 벡터가 아니므로 Stack은 Vector를 확장해서 는 안됐으며, 마찬가지로 속성 목록도 해시테이블이 아니므로 Properties도 Hashtable을 확장해서는 안 됐다. 두 사례 모두 컴포지션을 사용했다면 더 좋았을 것이다.

 

 

아래는 java.util.Stack을 컴포지션을 이용하여 리팩토링 해 본 코드이다.

package com.example.sypark9646.item18;

import java.util.EmptyStackException;
import java.util.Vector;

public class CustomStack<E> extends ForwardingVector<E> {

    public CustomStack(Vector<E> vector) {
        super(vector);
    }

    public E push(E item) {
        addElement(item);

        return item;
    }

    public synchronized E pop() {
        E obj;
        int len = size();

        obj = peek();
        removeElementAt(len - 1);

        return obj;
    }

    public synchronized E peek() {
        int len = size();

        if (len == 0) {
            throw new EmptyStackException();
        }
        return elementAt(len - 1);
    }

    public boolean empty() {
        return size() == 0;
    }

    public synchronized int search(Object o) {
        int i = lastIndexOf(o);

        if (i >= 0) {
            return size() - i;
        }
        return -1;
    }

    // private static final long serialVersionUID = 1224463164541339165L;
}
package com.example.sypark9646.item18;

import java.util.Collection;
import java.util.Comparator;
import java.util.Enumeration;
import java.util.Iterator;
import java.util.List;
import java.util.ListIterator;
import java.util.Spliterator;
import java.util.Vector;
import java.util.function.Consumer;
import java.util.function.Predicate;
import java.util.function.UnaryOperator;

public class ForwardingVector<E> extends Vector<E> {

    private final Vector<E> vector;

    public ForwardingVector(Vector<E> vector) {
        this.vector = vector;
    }

    public synchronized void copyInto(Object[] anArray) {
        vector.copyInto(anArray);
    }

    public synchronized void trimToSize() {
        vector.trimToSize();
    }

    public synchronized void ensureCapacity(int minCapacity) {
        vector.ensureCapacity(minCapacity);
    }

    public synchronized void setSize(int newSize) {
        vector.setSize(newSize);
    }

    public synchronized int capacity() {
        return vector.capacity();
    }

    public synchronized int size() {
        return vector.size();
    }

    public synchronized boolean isEmpty() {
        return vector.isEmpty();
    }

    public Enumeration<E> elements() {
        return vector.elements();
    }

    public boolean contains(Object o) {
        return vector.contains(o);
    }

    public int indexOf(Object o) {
        return vector.indexOf(o);
    }

    public synchronized int indexOf(Object o, int index) {
        return vector.indexOf(o, index);
    }

    public synchronized int lastIndexOf(Object o) {
        return vector.lastIndexOf(o);
    }

    public synchronized int lastIndexOf(Object o, int index) {
        return vector.lastIndexOf(o, index);
    }

    public synchronized E elementAt(int index) {
        return vector.elementAt(index);
    }

    public synchronized E firstElement() {
        return vector.firstElement();
    }

    public synchronized E lastElement() {
        return vector.lastElement();
    }

    public synchronized void setElementAt(E obj, int index) {
        vector.setElementAt(obj, index);
    }

    public synchronized void removeElementAt(int index) {
        vector.removeElementAt(index);
    }

    public synchronized void insertElementAt(E obj, int index) {
        vector.insertElementAt(obj, index);
    }

    public synchronized void addElement(E obj) {
        vector.addElement(obj);
    }

    public synchronized boolean removeElement(Object obj) {
        return vector.removeElement(obj);
    }

    public synchronized void removeAllElements() {
        vector.removeAllElements();
    }

    public synchronized Object clone() {
        return vector.clone();
    }

    public synchronized Object[] toArray() {
        return vector.toArray();
    }

    public synchronized <T> T[] toArray(T[] a) {
        return vector.toArray(a);
    }

    public synchronized E get(int index) {
        return vector.get(index);
    }

    public synchronized E set(int index, E element) {
        return vector.set(index, element);
    }

    public synchronized boolean add(E e) {
        return vector.add(e);
    }

    public boolean remove(Object o) {
        return vector.removeElement(o);
    }

    public void add(int index, E element) {
        vector.insertElementAt(element, index);
    }

    public synchronized E remove(int index) {
        return vector.remove(index);
    }

    public void clear() {
        vector.removeAllElements();
    }

    public synchronized boolean containsAll(Collection<?> c) {
        return vector.containsAll(c);
    }

    public boolean addAll(Collection<? extends E> c) {
        return vector.addAll(c);
    }

    public boolean removeAll(Collection<?> c) {
        return vector.removeAll(c);
    }

    public boolean retainAll(Collection<?> c) {
        return vector.retainAll(c);
    }

    public boolean removeIf(Predicate<? super E> filter) {
        return vector.removeIf(filter);
    }

    public synchronized boolean addAll(int index, Collection<? extends E> c) {
        return vector.addAll(index, c);
    }

    @Override
    public synchronized boolean equals(Object o) {
        return vector.equals(o);
    }

    @Override
    public synchronized int hashCode() {
        return vector.hashCode();
    }

    @Override
    public synchronized String toString() {
        return vector.toString();
    }

    public synchronized List<E> subList(int fromIndex, int toIndex) {
        return vector.subList(fromIndex, toIndex);
    }

    public synchronized ListIterator<E> listIterator(int index) {
        return vector.listIterator(index);
    }

    public synchronized ListIterator<E> listIterator() {
        return vector.listIterator();
    }

    public synchronized Iterator<E> iterator() {
        return vector.iterator();
    }

    public synchronized void forEach(Consumer<? super E> action) {
        vector.forEach(action);
    }

    public synchronized void replaceAll(UnaryOperator<E> operator) {
        vector.replaceAll(operator);
    }

    public synchronized void sort(Comparator<? super E> c) {
        vector.sort(c);
    }

    public Spliterator<E> spliterator() {
        return vector.spliterator();
    }
}

 

위 CustomStack을 테스트 해 본 결과는 아래와 같다.

package com.example.sypark9646.item18;

import static org.assertj.core.api.AssertionsForClassTypes.assertThatThrownBy;
import java.util.EmptyStackException;
import java.util.Stack;
import java.util.Vector;
import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;

public class CustomStackTest {

    @DisplayName("stack 동작 비교 테스트")
    @Test
    void testCustomStack() {
        CustomStack<String> customStack = new CustomStack<>(new Vector<>());
        Stack<String> stack = new Stack<>();

        customStack.push("1");
        customStack.push("2");
        customStack.push("3");

        stack.push("1");
        stack.push("2");
        stack.push("3");

        Assertions.assertAll(
            () -> Assertions.assertEquals(stack.search("3"), customStack.search("3")),
            () -> Assertions.assertEquals(stack.search("10"), customStack.search("10")),
            () -> Assertions.assertEquals(stack.peek(), customStack.peek()),
            () -> Assertions.assertEquals(stack.pop(), customStack.pop()),
            () -> Assertions.assertEquals(stack.pop(), customStack.pop()),
            () -> Assertions.assertEquals(stack.pop(), customStack.pop())
        );
    }

    @DisplayName("empty stack exception 테스트")
    @Test
    void testCustomStack_WhenEmptyStackCallsPeek_ThrowException() {
        CustomStack<String> customStack = new CustomStack<>(new Vector<>());

        Assertions.assertTrue(customStack.empty());
        assertThatThrownBy(customStack::peek).isInstanceOf(EmptyStackException.class);
    }
}

불변 클래스란 인스턴스의 내부 값을 수정할 수 없는 클래스를 말한다.

불변 클래스는 가변 클래스보다 설계 및 구현이 쉬우며, 오류가 생길 여지도 적고 훨씬 안전하다.

클래스를 불변으로 만들기 위해서는 아래 규칙을 따라야 한다.

1) 객체의 상태를 변경하는 메서드(변경자)를 제공하지 않는다.

 

2) 클래스를 확장할 수 없도록 한다. 

하위 클래스에서 부주의하게 혹은 나쁜 의도로 객체의 상태를 변하게 만드는 사태를 막아준다. 

상속을 막는 대표적인 방법은 클래스를 final로 선언하는 것이다.

또는 모든 생성자를 private 혹은 package-private으로 만들고 public 정적 팩터리를 제공하는 방법도 있다.

 

3) 모든 필드를 final로 선언한다. 

새로 생성된 인스턴스를 동기화 없이 다른 스레드로 건네도 문제없이 동작하게끔 보장하기도 한다.

 

4) 모든 필드를 private으로 선언한다. 

필드가 참조하는 가변 객체를 클라이언트에서 직접 접근해 수정하는 일을 막아준다.

 

5) 자신 외에는 내부의 가변 컴포넌트에 접근할 수 없도록 한다.

클래스에 가변 객체를 참조하는 필드가 하나라도 있다면 클라이언트에서 그 객체의 참조를 얻을 수 없도록 해야 한다. => 방어적 복사로 제공

이런 필드는 절대 클라이언트가 제공한 객체 참조를 가리키게 해서는 안 되며, 접근자 메서드가 그 필드를 그대로 반환해서도 안 된다.

생성자, 접근자, readobject 메서드(아이템 88) 모두에서 방어적 복사를 수행해야 한다.

 

 

 

자바 플랫폼 라이브러리에도 다양한 불변 클래스가 있다. String, 기본 타입의 박싱된 클래스들, Biginteger, BigDecimal이 여기 속한다.

거의 아래와 같이 연산 후에 인스턴스 자신은 수정하지 않고 새로운 인스턴스를 만들어 반환하게 된다.

이처럼 피 연산자에 함수를 적용해 그 결과를 반환하지만, 피 연산자 자체는 그대로인 프로그래밍 패턴을 함수형 프로그래밍이라 한다.

이와 달리, 절차적 혹은 명령형 프로그래밍에서는 메서드에서 피 연산자인 자신을 수정해 자신의 상태가 변하게 된다.

 

 

 

불변 객체는 근본적으로 스레드 안전하여 따로 동기화할 필요 없다.

불변 객체에 대해서는 그 어떤 스레드도 다른 스레드에 영향을 줄 수 없으니 불변 객체는 안심하고 공유할 수 있다.

따라서 불변 클래스라면 한번 만든 인스턴스를 최대한 재활용하기를 권한다.

가장 쉬운 재활용 방법은 자주 쓰이는 값들을 상수(public static final)로 제공 하는 것이다.

 

이 방식을 조금 더 활용할 수 있는 방법은 캐싱이다.

불변 클래스는 자주 사용되는 인스턴스를 캐싱하여 같은 인스턴스를 중복 생성하지 않게 해 주는 적정 팩터리(아이템 1)를 제공할 수 있다.

이 외에도 박싱된 기본타입 Integer/Long(-128~127) 등도 특정 값들을 캐싱해 두고 있다.

이런 정적 팩터리를 사용하면 여러 클라이언트가 인스턴스를 공유하여 메모리 사용량과 가비지 컬렉션 비용이 줄어든다.

새로운 클래스를 설계할 때 public 생성자 대신 정적 팩터리를 만들어두면, 클라이언트를 수정하지 않고도 필요에 따라 캐시 기능을 나중에 덧붙일 수 있다.

 

불변 객체를 자유롭게 공유할 수 있다는 점은 방어적 복사(아이템 50)도 필요 없다는 결론으로 자연스럽게 이어진다.

아무리 복사해봐야 원본과 똑같으니 복사 자체가 의미가 없고, 굳이 clone 메서드나 복사 생성자(아이템 13)를 제공하지 않는게 좋다.

그러니까 String 클래스의 복사 생성자는 굳이 사용하지 말자(아이템 6)

 

 

불변 객체는의 또 하나의 장점은 불변 객체끼리 내부 데이터를 공유할 수 있다는 점이다.

예를 들어 Biginteger 클래스는 내부에서 값의 부호 sign(int) 와 크기 magnitude(int[])를 따로 표현한다.

이때, negate 메서드는 크기가 같고 부호만 반 대인 새로운 Biginteger를 생성하는데, 이때 배열은 비록 가변이지만 복사하지 않고 원본 인스턴스와 공유해도 된다. 그 결과 새로 만든 Biginteger 인스턴스도 원본 인스턴스가 가리키는 내부 배열을 그대로 가리킨다.

 

 

객체를 만들 때 다른 불변 객체들을 구성요소로 사용하면 불변식을 유지하기 쉬워진다.

예를 들어, 불변 객체는 맵의 키와 집합(Set)의 원소로 쓰기 좋다. 맵이나 집합은 안에 담긴 값이 바뀌면 불변식이 허물어지는데, 불변 객체를 사용하면 그런 걱정은 하지 않아 도 된다.

불변 객체는 그 자체로 실패 원자성을 제공한다(아이템 76). 즉, 메서드에서 예외가 발생한 후에도 그 객체는 여전히 (메서드 호출 전과 똑같은) 유효한 상태라는 것이다. 불변 객체의 메서드는 내부 상태를 바꾸지 않으므로 상태가 절대 변하지 않는다.

불변 클래스에도 단점은 있다. 값이 다르면 반드시 독립된 객체로 만들어야 한다는 것이다.

아래 BigInteger.flipBit를 보자. 이 메서드에서는 원본과 한 비트만 다른 새로운 인스턴스를 반환한다.

이 연산은 Biginteger의 크기에 비례해 시간과 공간을 잡아먹는다.

이와 달리 BitSet.filt도 임의 길이의 비트 순열을 표현하지만, Biginteger와는 달리 가변이고, 이 때문에 원하는 비트 하나만 상수 시간 안에 바꿔줄 수 있다.

 

불변 객체는 원하는 객체를 완성하기까지의 단계가 많고, 중간 단계에서 만들어진 객체들이 모두 버려진다면 성능 문제가 발생할 수 있다. 

이 문제를 해결하기 위해서는, 흔히 쓰일 다단계 연산(multistep operation)들을 예측하여 기본 기능으로 제공하는 방법이 있다.

(다단계 연산을 기본으로 제공한다면 더 이상 각 단계마다 객체를 생성하지 않아도 된다)

 

클라이언트들이 원하는 복잡한 연산들을 정확히 예측할 수 있다면 package-private의 가변 동반 클래스만으로 충분하지만,

그렇지 않다면 이 클래스를 public으로 제공하는 게 최선이다. (String 클래스의 가변 동반 클래스 StringBuilder/StringBuffer 처럼)

 

 

 

Biginteger와 BigDecimal의 경우 불변 객체가 final이어야 하지만 그렇게 설계되지 못하여 클래스의 메서드들은 모두 재정의할 수 있게 설계되었다. 따라서 만약 신뢰할 수 없는 클라이언트로부터 Biginteger나 BigDecimal의 인스턴스를 인수로 받는다면 주의해야 한다.

이 값들이 불변이어야 클래스의 보안을 지킬 수 있다면, 인수로 받은 객체가 `진짜` Biginteger/BigDecimal 인지 반드시 확인해고, 신뢰할 수 없다고 확인되면 이 인수들은 가변이라 가정하고 아래와 같이 방어적으로 복사해 사용해야 한다(아이템 50).

public static Biginteger safeInstance(BigInteger val) { 
	return val.getClass() == Biginteger.class ? val : new BigInteger(val.toByteArray());
}

 

 

불변 클래스의 규칙에 따르면 모든 필드가 final이고 어떤 메서드도 그 객체를 수정할 수 없어야 하긴 하지만, 성능을 위해 "어떤 메서드도 객체의 상태 중 외부에 비치는 값을 변경할 수 없다" 로 살짝 완화할 수 있다.

단, 직렬화할 때는 추가로 주의할 점이 있다.

Serializable을 구현하는 불변 클래스의 내부에 가변 객체를 참조하는 필드가 있다면
readObject나 readResolve 메서드를 반드시 제공하거나
ObjectOutputStream.writeUnshared와 ObjectInputstream.readUnshared 메서드를 사용해야 한다.
그렇지 않으면 공격자가 이 클래스로부터 가변 인스턴스를 만들어낼 수 있다(아이템 88)

 


 

정리하자면, 클래스는 꼭 필요한 경우가 아니라면 불변이어야 한다. 그러니까 setter의 접근 제어자를 잘 설정하자.

String과 Biginteger처럼 무거운 값 객체도 불변으로 만들 수 있는지 생각 해 보고,

성능 때문에 어쩔 수 없다면(아이템 67) 불변 클래스와 쌍을 이루는 가변 동반 클래스를 public 클래스로 제공하도록 하자.

불변으로 만들 수 없는 클래스의 경우는 변경할 수 있는 부분을 최소한으로 줄이고, 그 외에는 모두 final로 선언하자.

 

생성자는 불변식 설정이 모두 완료된, 초기화가 완벽히 끝난 상태의 객체를 생성해야 한다. 

확실한 이유가 없다면 생성자와 정적 팩터리 외에는 그 어떤 초기화 메서드도 public으로 제공해서는 안 된다.

객체를 재활용할 목적으로 상태를 다시 초기화하는 메서드도 안 된다. (복잡성만 커지고 성능 이점은 거의 없다 ex. java.util.concurrent.CountDownLatch)


요 내용과 비슷한 것이 일급 컬렉션이라는 것이다. 이번 과제는 일급 컬렉션을 아래 조건에 맞게 구현하는 것이었다.

github.com/dolly0920/Effective_Java_Study/issues/35

 

ITEM 17. 변경 가능성을 최소화하라 · Issue #35 · dolly0920/Effective_Java_Study

지난 스터디에서도 이야기했지만, 일급 컬렉션이라고 하는 것을 활용하면 불변성을 보장하면서도 상태와 행위를 한 군데서 관리할 수 있는 이점이 있다는 이야기가 잠시 나왔습니다. item 17은

github.com

 

먼저 일급 컬렉션에 대해 알아보자면, 아래와 같다.

규칙 8: 일급 콜렉션 사용
이 규칙의 적용은 간단하다.
콜렉션을 포함한 클래스는 반드시 다른 멤버 변수가 없어야 한다.
각 콜렉션은 그 자체로 포장돼 있으므로 이제 콜렉션과 관련된 동작은 근거지가 마련된셈이다.
필터가 이 새 클래스의 일부가 됨을 알 수 있다.

필터는 또한 스스로 함수 객체가 될 수 있다.
또한 새 클래스는 두 그룹을 같이 묶는다든가 그룹의 각 원소에 규칙을 적용하는 등의 동작을 처리할 수 있다.
이는 인스턴스 변수에 대한 규칙의 확실한 확장이지만 그 자체를 위해서도 중요하다.
콜렉션은 실로 매우 유용한 원시 타입이다.
많은 동작이 있지만 후임 프로그래머나 유지보수 담당자에 의미적 의도나 단초는 거의 없다. - 소트웍스 앤솔로지 객체지향 생활체조편

출처: https://jojoldu.tistory.com/412

 

쉽게 말하면, 컬렉션을 가지고 있는 클래스를 하나 만들어서 클래스가 멤버 변수를 verify 하도록 하고, 컬렉션은 외부에서 바꿀 수 없도록 하자는 것이다. => 위에서 봤듯이, 컬렉션은 외부에서 참조가능 할 경우 final을 붙여도 안에 들어있는 값들이 변경될 수 있으니까

 

먼저 학교의 경우 enum으로 관리할 수 있도록 했다. (학과도 만들면 좋긴 했지만... 너무 귀찮았음) 

package com.example.sypark9646.item17.model;

public enum University {
    CATHOLIC("가톨릭대"),
    KONKUK("건국대"),
    KUONGGI("경기대"),
    KYUNGHEE("경희대"),
    KOREA("고려대"),
    KWANGWOON("광운대"),
    KOOKMIN("국민대"),
    SEOUL("서울대"),
    SOGANG("서강대"),
    SUNGKYUNKWAN("성균관대");


    private String name;

    University(String name) {
        this.name = name;
    }

    public String getName() {
        return name;
    }
}

 

Admission 클래스는 지원하는 학교 1개에 대한 객체인데,

좀 더 재밌는 요소를 부여해 보고 싶어서 RandomUtils를 이용해서 지원 후 랜덤으로 합격 결과가 정해질 수 있도록 했다.

이 때, equals와 hashcode를 재정의 하여 학과가 같으면 같은 Admission -> duplicate 를 검출할 수 있도록 했다.

package com.example.sypark9646.item17.model;

import com.example.sypark9646.item17.utils.Messages;
import com.example.sypark9646.item17.utils.RandomUtils;
import lombok.AccessLevel;
import lombok.Getter;
import lombok.NoArgsConstructor;

@NoArgsConstructor(access = AccessLevel.PRIVATE)
public class Admission {

    private University university;
    private String department;
    @Getter
    private boolean isAccepted;

    public Admission(University university, String department) {
        this.university = university;
        this.department = department;
        this.isAccepted = RandomUtils.getRandomBoolean();
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) {
            return true;
        }

        if (o == null) {
            return false;
        }

        if (!(o instanceof Admission)) {
            return false;
        }

        Admission admission = (Admission) o;
        return this.university == admission.university;
    }

    @Override
    public int hashCode() {
        return university.hashCode();
    }

    @Override
    public String toString() {
        String acceptance = isAccepted ? Messages.PASS.getMessage() : Messages.FAIL.getMessage();

        return new StringBuilder("")
            .append(university.getName())
            .append("학교 ")
            .append(this.department)
            .append(" 지원 결과")
            .append(acceptance)
            .append("입니다.")
            .toString(); // string 으로 하는게 더 좋을까...?
    }
}

 

Util 클래스의 경우 item04에서 배웠듯이 생성자를 private으로 만들어 두어서 인스턴스화 되는 것을 막았다.

package com.example.sypark9646.item17.utils;

import java.util.Random;
import lombok.AccessLevel;
import lombok.NoArgsConstructor;

@NoArgsConstructor(access = AccessLevel.PRIVATE)
public class RandomUtils {

    private static Random random = new Random();

    public static boolean getRandomBoolean() {
        return random.nextBoolean();
    }
}

 

그 다음으로는 Admission을 담고 있는 리스트만을 필드로 가지고 있는 일급컬렉션 Admissions을 정의해 보았다.

Admission 클래스의 필드는 외부에서 접근 불가능하도록 private으로 둠으로써 불변 클래스로 만들었고,

객체를 생성할 때 validation을 진행하며 조건에 맞지 않을 경우 IllegalArgumentException을 반환하도록 했다.

여기서 사용하는 contains는 equals, HashSet은 equals와 hashCode의 재정의에 따라 동작하게 된다.

package com.example.sypark9646.item17.model;

import java.util.HashSet;
import java.util.List;
import java.util.concurrent.atomic.AtomicBoolean;
import com.example.sypark9646.item17.utils.Messages;
import lombok.AccessLevel;
import lombok.NoArgsConstructor;

@NoArgsConstructor(access = AccessLevel.PRIVATE)
public class Admissions {

    public static final int MAX_APPLY_SIZE = 6;
    private List<Admission> admissions;

    public Admissions(List<Admission> admissions) {
        validateSize(admissions);
        validateDuplicate(admissions);
        this.admissions = admissions;
    }

    private void validateSize(List<Admission> admissions) {
        if (admissions.size() > MAX_APPLY_SIZE) {
            throw new IllegalArgumentException(Messages.SIZE_ERROR_MESSAGE.getMessage());
        }
    }

    private void validateDuplicate(List<Admission> admissions) {
        HashSet<Admission> noDuplicateAdmissions = new HashSet<>(admissions);
        if (admissions.size() != noDuplicateAdmissions.size()) {
            throw new IllegalArgumentException(Messages.DUPLICATE_ERROR_MESSAGE.getMessage());
        }
    }

    public void showResult() {
        boolean isAccepted = admissions.stream().anyMatch(Admission::isAccepted);

        getAcceptedResult();
        String message =
            isAccepted ? Messages.SHOW_RESULT_PASS_MESSAGE.getMessage()
                : Messages.SHOW_RESULT_NO_PASS_MESSAGE.getMessage();
        System.out.println(message);
    }

    public void getAcceptedResult() {
        System.out.println(Messages.PASS_LIST.getMessage());
        System.out.println(Messages.DELIMITER.getMessage());
        AtomicBoolean isAccepted = new AtomicBoolean(false);

        admissions.forEach(
            admission -> {
                if (admission.isAccepted()) {
                    System.out.println(admission);
                    isAccepted.set(true);
                }
            }
        );

        if (!isAccepted.get()) {
            System.out.println(Messages.NO_PASS_LIST.getMessage());
        }
        System.out.println(Messages.DELIMITER.getMessage());
    }

    public void getDeclinedResult() {
        System.out.println(Messages.FAIL_LIST.getMessage());
        System.out.println(Messages.DELIMITER.getMessage());
        AtomicBoolean isDeclined = new AtomicBoolean(false);

        admissions.forEach(
            admission -> {
                if (!admission.isAccepted()) {
                    System.out.println(admission);
                    isDeclined.set(true);
                }
            }
        );

        if (!isDeclined.get()) {
            System.out.println(Messages.NO_FAIL_LIST.getMessage());
        }
        System.out.println(Messages.DELIMITER.getMessage());
    }
}

 

리턴되는 메세지들은 미리 static으로 하나만 올려두고 싶어서 enum으로 정의해뒀다.

package com.example.sypark9646.item17.utils;

public enum Messages {
    PASS("합격"),
    FAIL("불합격"),
    PASS_LIST("합격한 대학 목록입니다"),
    FAIL_LIST("불합격한 대학 목록입니다"),
    DELIMITER("- - -"),
    NO_PASS_LIST("합격한 대학이 없습니다."),
    NO_FAIL_LIST("불합격한 대학이 없습니다."),
    SHOW_RESULT_NO_PASS_MESSAGE("지원한 학교에 모두 떨어졌습니다. 재수 학원을 추천합니다..."),
    SHOW_RESULT_PASS_MESSAGE("합격을 축하합니다! 반수는 어떨까요...?"),
    DUPLICATE_ERROR_MESSAGE("같은 대학의 같은 학과를 다른 전형으로 지원하는 것은 불가능합니다."),
    SIZE_ERROR_MESSAGE("지원할 수 있는 학교 및 학과는 0개 이상 6개 이하입니다.")
    ;


    private String message;

    Messages(String message) {
        this.message = message;
    }

    public String getMessage() {
        return message;
    }
}

 

EarlyAdmission에서는 최종적으로 결과를 리턴할 수 있도록 했다.

Admission을 컴포지션으로 넣음으로써 결과 리턴 시 admission의 메소드들을 사용하게 했다.

package com.example.sypark9646.item17;

import java.time.LocalDate;
import java.util.List;
import com.example.sypark9646.item17.model.Admission;
import com.example.sypark9646.item17.model.Admissions;
import lombok.AccessLevel;
import lombok.NoArgsConstructor;

@NoArgsConstructor(access = AccessLevel.PRIVATE)
public class EarlyAdmission {

    private String name;
    private LocalDate birth;
    private Admissions admissions;

    public EarlyAdmission(String name, LocalDate birth, List<Admission> admissionList) {
        this.name = name;
        this.birth = birth;
        this.admissions = new Admissions(admissionList);
    }

    public void showResult() {
        System.out.println(name+"님의 지원 결과");
        admissions.showResult();
    }

    public void getAcceptedResult() {
        System.out.println(name+"님의 지원 결과");
        admissions.getAcceptedResult();
    }

    public void getDeclinedResult() {
        System.out.println(name+"님의 지원 결과");
        admissions.getDeclinedResult();
    }
}

 

테스트 결과는 아래와 같다

package com.example.sypark9646.item17;

import static org.assertj.core.api.AssertionsForClassTypes.assertThatThrownBy;
import java.time.LocalDate;
import java.util.ArrayList;
import java.util.List;
import com.example.sypark9646.item17.model.Admission;
import com.example.sypark9646.item17.model.University;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;

public class EarlyAdmissionTest {

    @DisplayName("정상 동작 테스트")
    @Test
    void testEarlyAdmission() {
        List<Admission> admissions = new ArrayList<>();
        admissions.add(new Admission(University.CATHOLIC, "컴퓨터공학과"));
        admissions.add(new Admission(University.KONKUK, "컴퓨터공학과"));
        admissions.add(new Admission(University.KOREA, "컴퓨터공학과"));
        admissions.add(new Admission(University.KYUNGHEE, "컴퓨터공학과"));
        admissions.add(new Admission(University.SEOUL, "컴퓨터공학과"));
        admissions.add(new Admission(University.SOGANG, "컴퓨터공학과"));

        LocalDate birth = LocalDate.of(1996, 4, 6);

        EarlyAdmission earlyAdmission = new EarlyAdmission("박소연", birth, admissions);

        System.out.println("[Show Result]");
        earlyAdmission.showResult();
        System.out.println();

        System.out.println("[Get Accepted Result]");
        earlyAdmission.getAcceptedResult();

        System.out.println("[Get Declined Result]");
        earlyAdmission.getDeclinedResult();
    }

    @DisplayName("invalid size 테스트")
    @Test
    void testEarlyAdmission_WhenInvalidSize_ThrowException() {
        List<Admission> admissions = new ArrayList<>();
        admissions.add(new Admission(University.CATHOLIC, "컴퓨터공학과"));
        admissions.add(new Admission(University.KONKUK, "컴퓨터공학과"));
        admissions.add(new Admission(University.KOREA, "컴퓨터공학과"));
        admissions.add(new Admission(University.KYUNGHEE, "컴퓨터공학과"));
        admissions.add(new Admission(University.SEOUL, "컴퓨터공학과"));
        admissions.add(new Admission(University.SOGANG, "컴퓨터공학과"));
        admissions.add(new Admission(University.SUNGKYUNKWAN, "컴퓨터공학과"));

        LocalDate birth = LocalDate.of(1996, 4, 6);

        assertThatThrownBy(() -> {
            EarlyAdmission earlyAdmission = new EarlyAdmission("박소연", birth, admissions);
        }).isInstanceOf(IllegalArgumentException.class);
    }

    @DisplayName("duplicate admission 테스트")
    @Test
    void testEarlyAdmission_WhenDuplicateAdmission_ThrowException() {
        List<Admission> admissions = new ArrayList<>();
        admissions.add(new Admission(University.CATHOLIC, "컴퓨터공학과"));
        admissions.add(new Admission(University.KONKUK, "컴퓨터공학과"));
        admissions.add(new Admission(University.KOREA, "컴퓨터공학과"));
        admissions.add(new Admission(University.KYUNGHEE, "컴퓨터공학과"));
        admissions.add(new Admission(University.SEOUL, "컴퓨터공학과"));
        admissions.add(new Admission(University.SEOUL, "수학과"));

        LocalDate birth = LocalDate.of(1996, 4, 6);

        assertThatThrownBy(() -> {
            EarlyAdmission earlyAdmission = new EarlyAdmission("박소연", birth, admissions);
        }).isInstanceOf(IllegalArgumentException.class);
    }
}
잘 설계된 컴포넌트는 모든 내부 구현을 완벽히 숨겨, 구현과 API를 깔끔히 분리한다. 오직 API를 통해서만 다른 컴포넌트와 소통하며 서로의 내부 동작 방식에는 전혀 개의치 않는다. 정보 은닉, 혹은 캡슐화라고 하는 이 개념은 소프트웨어 설계의 근간이 되는 원리다

 

자바는 정보 은닉을 위한 다양한 장치를 제공한다. 그중 접근 제어 메커니즘은 클래스, 인터페이스, 멤버의 접근 허용 범위를 명시한다.

접근 제어 매커니즘을 쉽게 말하자면 모든 클래스와 멤버의 접근성을 가능한 한 좁혀야 한다는 원리이다.

 

가장 바깥의 클래스를 톱레벨 클래스라고 할 때, 이 톱 레벨 클래스의 인터페이스에 부여할 수 있는 접근 수준은 package-private(default)과 public 두 가지다.

톱레벨 클래스나 인터페이스 를 public으로 선언하면 공개 API가 되며, package-private으로 선언하면 해당 패키지 안에서만 이용할 수 있다.

패키지 외부에서 쓸 이유가 없다면 package-private으로 선언하자. 그러면 내부 구현이 되어 언제든 수정할 수 있다. 하지만, public으로 선언하게 되면 공개 API가 되므로 하위 호환을 위해 영원히 관리해줘야만 한다. (public 클래스는 그 패키지의 API인 반면, package-private 톱레벨 클래스는 내부 구현이기 때문)

 

 

한 클래스에서만 사용하는 package-private 톱레벨 클래스나 인터페이스는 이를 사용하는 클래스 안에 private static으로 중첩시켜보자(아이템 24). => private static inner class 로 만들자. (톱 레벨로 두면 같은 패키지의 모든 클래스가 접근할 수 있지만, private static 으로 중첩시키면 바깥 클래스 하나에서만 접근할 수 있기 때문)

 

 


멤버(필드, 메서드, 중첩 클래스, 중첩 인터페이스)에 부여할 수 있는 접근 수 준은 네 가지다. 접근 범위가 좁은 것부터 보면,

  • private: 멤버를 선언한 톱레벨 클래스에서만 접근할 수 있다.
  • package-private(default): 멤버가 소속된 패키지 안의 모든 클래스에서 접근할 수 있다.
  • protected: package-private의 접근 범위를 포함하며, 이 멤버를 선언한 클래스의 하위 클래스에서도 접근할 수 있다
  • public: 모든 곳에서 접근할 수 있다 (인터페이스 멤버는 default가 public이다)

https://stackoverflow.com/questions/215497/what-is-the-difference-between-public-protected-package-private-and-private-in

 

 

private과 package-private 멤버는 모두 해당 클래스의 구현에 해당하므로 보통은 공개 API에 영향을 주지 않는다. 단, Serializable을 구현한 클래스에서는 그 필드들도 의도치 않게 공개 API가 될 수도 있다(아이템 86,87).

 

public 클래스의 protected 멤버 또한 공개 API이므로 영원히 지원돼야 한다. 또한 내부 동작 방식을 API 문서에 적어 사용자에게 공개해야 할 수도 있다(아이템 19). 따라서 protected 멤버의 수는 적을수록 좋다.

 

그런데 멤버 접근성을 좁히지 못하게 방해하는 제약이 하나 있다. 상위 클래스의 메서드를 재정의할 때는 그 접근 수준을 상위 클래스에서 보다 좁게 설정 할 수 없다는 것이다. 이 제약은 상위 클래스의 인스턴스는 하위 클래스의 인스턴스로 대체해 사용할 수 있어야 한다는 규칙(리스코프 치환 원칙, 아이템 10)을 지키기 위해 필요하다. 이 규칙을 어기면 하위 클래스를 컴파 일할 때 컴파일 오류가 난다. 클래스가 인터페이스를 구현하는 건 이 규칙의 특별한 예로 볼 수 있고, 이때 클래스는 인터페이스가 정의한 모든 메서드를 public으로 선언해야 한다.

 

단지 코드를 테스트하려는 목적으로 클래스, 인터페이스, 멤버의 접근 범위 를 넓힐 때에는, public 클래스의 private 멤버를 package-private까지 풀어주는 것은 허용할 수 있지만, 그 이상은 하지 않도록 하자. (테스트 코드를 테스트 대상과 같은 패키지에 두면 package-private 요소에 접근할 수 있으니까 굳이 더 열어주지 않아도 된다)

 

public 클래스의 인스턴스 필드는 되도록 public이 아니어야 한다(아이템 16). 하지만 상수라면 public static final 필드로 공개해도 좋다.

 

 

길이가 0이 아닌 배열은 모두 변경 가능하니 주의하자. 따라서 클래스에서 public static final 배열 필드를 두거나 이 필드를 반환하는 접근자 메서드를 제공해서는 안 된다. 이런 필드나 접근자를 제공한다면 클라이언트에서 그 배열 의 내용을 수정할 수 있게 된다. 

public static final Thing[] VALUES = { ... };

이 경우 해결 방법은 2가지가 있다.

1) 앞 코드의 public 배열을 private으로 만들고 public 불변 리스트를 추가

private static final Thing[] PRIVATE_VALUES = { ... }; 
public static final List<Thing> VALUES = Collections.unmodifiableList(Arrays.asList(PRIVATE_VALUES));

2) 배열을 private으로 만들고 그 복사본을 반환하는 public 메서드를 추가하는 방법(방어적 복사)

private static final Thing[] PRIVATE_VALUES = { ... }; 
public static final Thing[] values() { return PRIVATE_VALUES.clone(); }

 

 

자바 9부터는 모듈 시스템이라는 개념이 도입되면서 두 가지 암묵적 접근 수준이 추가되었다.

패키지가 클래스들의 묶음이듯, 모듈은 패키지들의 묶음이다.

모듈은 자신에 속하는 패키지 중 공개(export)할 것들을 선언하는데, protected 혹은 public 멤버라도 해당 패키지를 공개하지 않았다면 모듈 외부에서는 접근할 수 없다. (모듈 안에서는 exports로 선언했는지 여부에 영향X)

모듈 시스템을 활용 하면 클래스를 외부에 공개하지 않으면서도 같은 모듈을 이루는 패키지 사이에서는 자유롭게 공유할 수 있다.

 

모듈에 적용되는 새로운 두 접근 수준은 매우 주의하도록 하자.

만약 모듈의 JAR 파일을 자신의 모듈 경로가 아닌 애플리케이션의 클래스패스(classpath)에 두면 그 모듈 안의 모든 패키지는 마치 모듈이 없는 것처럼 행동한다. 즉, 모듈이 공개했는지 여부와 상관없이 public 클래스가 선언한 모든 public 혹은 protected 멤버를 모듈 밖에서도 접근할 수 있게 된다. => 새로 등장한 이 접근 수준을 적극 활용한 대표적인 예가 바로 JDK 자체이다. (자바 라이브러리에서 공개하지 않은 패키지들은 해당 모듈 밖에서는 절대로 접근 불가하다.)



public 클래스의 경우 필드를 public으로 두지 말고, 모두 private + public 접근자(getter)를 추가하도록 하자.

특히 절대 가변 필드를 직접 노출해서는 안 된다. 불변 필드라면 노출해도 덜 위험하지만 완전히 안심할 수는 없다.

 

package-private 클래스 혹은 private 중첩 클래스의 경우는 데이터 필드를 노출하더라도 문제 없다.

클라이언트 코드가 이 클래스 내부 표현에 묶이기는 하나, 클라이언트도 어차피 이 클래스를 포함하는 패키지 안에서만 동작하는 코드이기 때문이다.

따라서 패키지 바깥 코드는 전혀 손대지 않고도 데이터 표현 방식을 바꿀 수 있다.

private 중첩 클래스의 경우 라면 수정 범위가 더 좁아져서 이 클래스를 포함하는 외부 클래스까지로 제한 된다.

 

 

 

언뜻 보면 public 에서 바로 접근해서 고치나 private+public 접근자로 setXX형태로 고치나 결국 로직상으로는 동일하다고 느껴질 수 있다.

public class Point {
    public int x;
    public int y;
}
public class Point {
    private int x;
    private int y;

    public void setX(int x) {
        this.x = x;
    }

    public void setY(int y) {
        this.y = y;
    }
}

위의 방식처럼 point.x = 10 으로 설정하는 것과 아래와 같이 point.setX(10) 으로 설정하는 것이

결국 로직상으로는 동일한데, 왜 다들 안된다고 하는 것인지.. 궁금해져서 조금 알아 보았다.

 

1) 동작의 캡슐화 - 나중에 더 쉽게 추가 기능(유효성 검사 등)을 추가 할 수 있다

   public void setSpeed(int speed) {
     if ( speed > 100 ) {
       this.speed = 100;
     } else {
       this.speed = speed;
     }
   }

2) 대체 표현(setX)을 사용하여 속성을 노출하는 동안 속성의 내부 표현(x)을 숨긴다 -> 구현 변경 사항을 숨길 수 있다.

- before

      private boolean alive = true;

      public boolean isAlive() { return alive; }
      public void setAlive(boolean alive) { this.alive = alive; }

- after

      private int hp; // change!

      public boolean isAlive() { return hp > 0; } // old signature 
      //method looks the same, no change in client code
      public void setAlive(boolean alive) { this.hp = alive ? 100 : 0; }

3) getter와 setter는 polymorphic하고 필드는 그렇지 않다.

      public class Animal{
        public void setSound(Animal a) {

          if (a instanceof Dog) {         // Checking animal type
            System.out.println("Bark");
          } else if (a instanceof Cat) {     // Checking animal type
            System.out.println("Meowww");
          }
        }
      }

4) getter / setter가 값이 아닌 `람다식으로 전달`될 수 있다.
5) getter / setter에 `서로 다른 액세스 수준을 허용` 할 수 있다.
6) getter / setter에 대해 `lazyloading`이 가능해진다.
7) `디버깅`이 편리해진다. (중단 점을 여러 필드 참조에서 걸지 않고 하나의 메서드에만 걸면 되니까)

 

여러 장점들이 있지만 한 줄로 정리하자면, 추상화와 캡슐화가 setter을 사용하는 가장 큰 이유인 것 같다.
(그치만 뒷 장에서도 나오듯이 setter도 결국 필드 값을 바꾸는 것이기 때문에 사용을 자제 해야겠다)

 

 

 

자바 플랫폼 라이브러리에도 public 클래스의 필드를 직접 노출하지 말라는 규칙을 어기는 사례가 종종 있다.

1) java.awt.package.Point

2) java.awt.package.Dimension

 

 

Point를 상속하는 PointExtension 클래스를 만들어 봤다.

package com.example.sypark9646.item16;

import java.awt.Point;

public class PointExtension extends Point {
    double x, y;
}
    @DisplayName("java.awt.package.Point 상속 테스트")
    @Test
    void pointExtensionTest() {
        PointExtension pointExtension = new PointExtension();
        System.out.println(pointExtension.x + "" + pointExtension.y);

        // pointExtension.x = 10;
        // pointExtension.y = 10;
        pointExtension.move(10, 10); // 0, 0
        Assertions.assertAll(
            () -> Assertions.assertNotEquals(pointExtension.x, 10), // 0
            () -> Assertions.assertNotEquals(pointExtension.y, 10) // 0
        );

        Assertions.assertAll(
            () -> Assertions.assertEquals(10.0, pointExtension.getX()), // 10.0
            () -> Assertions.assertEquals(10.0, pointExtension.getY()) // 10.0
        );
    }

위의 경우 직접 접근 하게 되면 pointExtension의 값을 사용하게 되고, move나 getter는 point class의 함수를 사용하게 된다.

 

reference

stackoverflow.com/questions/1568091/why-use-getters-and-setters-accessors

 

Why use getters and setters/accessors?

What's the advantage of using getters and setters - that only get and set - instead of simply using public fields for those variables? If getters and setters are ever doing more than just the simp...

stackoverflow.com

stackoverflow.com/questions/11071407/advantage-of-set-and-get-methods-vs-public-variable

 

Advantage of set and get methods vs public variable

Possible Duplicate: Why use getters and setters? Is there any advantage to making methods to access private variables in your class instead of making the variable public? For example is the s...

stackoverflow.com

 

Comparable 인터페이스에는 compareTo 메서드가 있는데, Object의 equals와 유사하기 때문에 어떤 점이 다른지를 중점으로 보면 되겠다.

compareTo는 단순 동치성 비교에 더해 순서까지 비교할 수 있으며, 제네릭하다.

=> Comparable을 구현했다는 것은 그 클래스의 인스턴스들에는 자연적인 순서 (natural order)가 있음을 뜻한다.

Comparable을 구현하게 되면 검색, 극단값 계산,자동 정렬되는 컬렉션 관리 등을 쉽게 할 수 있기 때문에, 자바 플랫픔 라이브러리의 모든 값 클래스와 열거 타입(아이템 34)이 Comparable을 구현하고 있다.

 

비교를 활용하는 클래스의 예로는 정렬된 컬렉션인 TreeSet과 TreeMap,

검색과 정렬 알고리즘을 활용하는 유틸리티 클래스인 Collections와 Arrays가 있다.

 

 

Comparable.compare

compareTo 메서드의 일반 규약은 equals의 규약과 비슷하다.

이 객체와 주어진 객체의 순서를 비교한다.
이 객체가 주어진 객체보다 작으면 음의 정수를, 같으면 0을, 크면 양의 정수를 반환한다.
이 객체와 비교할 수 없는 타입의 객체가 주어지면 ClassCastException을 던진다.

다음 설명에서 sgn(표현식) 표기는 수학에서 말하는 부호 함수(signum function)를 뜻하며,
표현식의 값이 음수, 0, 양수일 때 -1, 0, 1을 반환하도록 정의했다.

- Comparable을 구현한 클래스는 모든 x, y에 대해 sgn(x.compareTo(y)) =- -sgn(y. compareTo(x))여야 한다
(따라서 x.compareTo(y)는 y.compareTo(x)가 예외를 던질 때에 한해 예외를 던져야 한다).

- Comparable을 구현한 클래스는 추이성을 보장해야 한다.
즉, (x.compareTo(y) > 0 g y.compareTo(z) > 0)이면 x.compareTo(z) > 0이다.

- Comparable을 구현한 클래스는 모든 z에 대해 x.compareTo(y) == 0이면 sgn(x. compareTo(z)) == sgn(y.compareTo(z)) 다.

- (x.compareTo(y) == 0) == (x. equals(y))여야 한다. => 필수는 아니지만 꼭 지키는 게 좋다
Comparable을 구현하고 이 권고를 지키지 않는 모든 클래스는 그 사실을 명시해야 한다.

다음과 같이 명시하면 적당할 것이다.
“주의: 이 클래스의 순서는 equals 메서드와 일관되지 않다.”

 

모든 객체에 대해 전역 동치관계를 부여하는 equals 메서드와 달리, compareTo 는 타입이 다른 객체를 신경 쓰지 않아도 된다.

(타입이 다른 객체가 주어지면 간단히 ClassCastException을 던져도 된다. 또는 다른 타입 사이의 비교할 때에는 공통 인터페이스 사용)

 

compareTo 규약을 좀 더 자세히 살펴보자.

 

1) Comparable을 구현한 클래스는 모든 x, y에 대해 sgn(x.compareTo(y)) =- -sgn(y. compareTo(x))여야 한다 - 반사성

두 객체 참조 의 순서를 바꿔 비교해도 예상한 결과가 나와야 한다는 의미이다.

 

 

2) Comparable을 구현한 클래스는 추이성을 보장해야 한다 - 추이성

추이성은 equals 에서도 살펴봤던 개념인데, 쉽게 말하면 첫 번째가 두 번째보다 크고 두 번째가 세 번째보다 크면, 첫 번째는 세 번째보다 커야 한다는 뜻이다.

 

 

3) Comparable을 구현한 클래스는 모든 z에 대해 x.compareTo(y) == 0이면 sgn(x. compareTo(z)) == sgn(y.compareTo(z)) - 반사성

크기가 같은 객체들끼리는 어떤 객체와 비교하더라도 항상 같아야 한다는 의미이다.

 

위 세 규약은 equals 규약에서 봤던 반사성, 대칭성, 추이성에 대한 내용이다. 그래서 주의사항도 똑같다.

기존 클래스를 확장한 구체 클래스에서 새로운 값 컴포넌트를 추가 했다면 compareTo 규약을 지킬 방법이 없다.

우회법도 같다. Comparable을 구현 한 클래스를 확장해 값 컴포넌트를 추가하고 싶다면, 컴포지션을 이용한다.

 

 

4) (x.compareTo(y) == 0) == (x. equals(y))여야 한다.

compareTo 메서드로 수행한 동치성 테스트의 결과가 equals와 같아야 한다는 의미이다.

compareTo의 순서와 equals의 결과가 일과되지 않은 클래스도 여전히 동작은 하기 때문에 꼭 지켜야 하는 것은 아니지만,

지키지 않을 경우 이 클래스의 객체를 정렬된 컬렉션에 넣으면 해당 컬렉션이 구현한 인터페이스(Collection, Set, 혹은 Map)에 정의된 동 작과 엇박자를 낼 것이다.

(이 인터페이스들은 equals 메서드의 규약을 따르지만, 정렬된 컬렉션들은 동치성을 비교할 때 equals 대신 compareTo를 사용)

 

compareTo와 equals가 일관되지 않는 BigDecimal 클래스를 예로 생각해보자.

BigDecimal.equals
BigDecimal.compareTo

 

HashSet은 equals로 비교하고, TreeSet은 compareTo를 사용한다.

따라서 아래와 같이 동작하게 된다.

package com.example.sypark9646.item14;

import java.math.BigDecimal;
import java.util.HashSet;
import java.util.TreeSet;
import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;

public class EqualsAndCompareToCollectionTest {

		@Test
		@DisplayName("HashSet와 TreeSet의 동작 방식을 비교한다")
		void equalsAndCompareToCollectionTest(){
				HashSet<BigDecimal> hashSet = new HashSet<>();
				TreeSet<BigDecimal> treeSet = new TreeSet<>();

				hashSet.add(new BigDecimal("1.0"));
				hashSet.add(new BigDecimal("1.00"));

				treeSet.add(new BigDecimal("1.0"));
				treeSet.add(new BigDecimal("1.00"));

				Assertions.assertEquals(2, hashSet.size()); // true
				Assertions.assertEquals(1, treeSet.size()); // true
		}
}

위 BigDecimal 1.0과 1.00은 equals 메서드로 비교 하면 서로 다르기 때문에 HashSet은 원소를 2개 갖게 된다.

하지만 compareTo 메서드로 비교하 면 두 BigDecimal 인스턴스가 똑같기 때문에 TreeSet의 원소는 1개이다.

 

Comparable은 타입을 인수로 받는 제네릭 인터페이스이므로 compareTo 메서드의 인수 타입은 컴파일타임에 정해진다.

  • 입력 인수의 타입을 확인하거나 형변환 필요X
  • 인수의 타입이 잘못됐다면 컴파일 자체가 X
  • null을 인수로 넣어 호출하면 NullPointerException을 던지도록 한다.

 

compareTo 메서드는 각 필드가 동치인지 비교하는 게 아니라 그 순서를 비교한다.

객체 참조 필드를 비교하려면 compareTo 메서드를 재귀적으로 호출한다. Comparable을 구현하지 않은 필드나 표준이 아닌 순서로 비교해 야 한다면 비교자(Comparator)를 대신 사용한다.

 

compareTo를 구현할 때에는 자바 7의 일반적으로 박싱된 기본 타입 클래스들에 새로 추가된 정적 메서드 compare를 이용하자.

(<와 > 를 사용하는 이전 방식은 헷갈리고 오류를 유발한다.)

 

자바 8부터는 Comparator 인터페이스가 일련의 비교자 생성 메서드(comparator construction method)의 팀을 꾸려 메서드 연쇄 방식으로 비교자를 생성할 수 있게 되었다. 그리고 이 비교자들을 compareTo 메서드를 구현하는 데 활용할 수 있다. (약간의 성능 저하는 있다)

class PhoneNumber {
	private int areaCode, prefix, lineNum;

	public int compareToWithCompare(PhoneNumber pn) {
		int result = Integer.compare(areaCode, pn.areaCode); // 가장 중요한 필드

		if (result == 0) {
			result = Integer.compare(prefix, pn.prefix); // 두 번째로 중요한 필드
			if (result == 0) {
				result = Integer.compare(lineNum, pn.lineNum); // 세 번째로 중요한 필드
			}
		}
		return result;

	}
    
    
	// comparinglnt는 람다 (lambda)를 인수로 받는다 - 입력 인수의 타입(PhoneNumber pn)을 명시함 주의
	private static final Comparator<PhoneNumber> COMPARATOR = Comparator.comparingInt((PhoneNumber pn) -> pn.areaCode) // 가장 중요한 필드
			.thenComparingInt(pn -> pn.prefix) // 두 번째로 중요한 필드
			.thenComparingInt(pn -> pn.lineNum); // 세 번째로 중요한 필드
	

	public int compareToWithComparator(PhoneNumber pn) {
		return COMPARATOR.compare(this, pn);
	}
}

 

이 때 주의할 점은, Comparator의 compare을 정의할 때 `값의 차`를 기준으로 사용하곤 하는데, 사용하지 않도록 하자. 

왜냐하면 정수 오버플로우를 일으키거나 IEEE 754 부동소수점 계산 방식에 따른 오류를 낼 수 있다. 따라서 위에서 정의했듯이, Integer.compare 또는 Comparator.comparingInt 를 사용하도록 하자.

static Comparator<Object> hashCodeOrder = new Comparator() { 
	public int compare(Object o1, Object o2) { 
    	return o1.hashCode() - o2.hashCode(); // 오버플로우 발생 가능
	} 
};

 

 

 

 

 

Cloneable

Cloneable은 복제해도 되는 클래스임을 명시하는 용도의 mixin interface(아이템 20)지만, 의도한 목적을 제대로 이루지 못했다.

 

가장 큰 문제는 clone 메서드가 선언된 곳이 Cloneable이 아닌 Object이고, 그마저도 protected라는 데 있다.

그래서 Cloneable을 구현하는 것만으로는 외부 객체에서 clone 메서드를 호출할 수 없다.

리플렉션(아이템 65)을 사용하면 가능하지만, 100% 성공하는 것도 아니다. (해당 객체가 접근 허용된 clone 메서드를 제공한다는 보장X)

 

메서드 하나 없는 Cloneable 인터페이스는 Object의 protected 메서드인 clone의 동작 방식을 결정한다.

Cloneable을 구현한 클래스의 인스턴스에서 clone을 호출하면 그 객체의 필드들을 하나하나 복사한 객체를 반환하며, 그렇지 않은 클래스의 인스턴스에서 호출하면 CloneNotSupportedException을 던진다.

=> 인터페이스를 구현한다는 것은 일반적으로 해당 클래스가 그 인터페이스에서 정의한 기능을 제공 한다고 선언하는 행위인데, Cloneable의 경우에는 상위 클래스에 정의된 protected 메서드의 동작 방식을 변경했다. (따라하지 말자..)

 

Object.clone

Cloneable을 구현한 클래스는 clone 메서드를 public으로 제공하며, 복제생성지를 호출하지 않고도 객체를 생성할 수 있게 되는 것이다.

생성지를 호출하지 않고도 객체를 생성할 수 있게 되는 것이기 때문에 위험하다고 할 수 있다.

 

위 Object.clone에서 기술된 매커니즘을 자세히 보자.

이 객체의 복사본을 생성해 반환한다. ‘복사’의 정확한 뜻은 그 객체를 구현한 클래스에 따라 다를 수 있다.
일반적인 의도는 다음과 같다.

어떤 객체 x에 대해 다음 식은 참이다. x.clone() != x

또한 다음 식도 참이다.
x.clone().getClass() = x.getClass()

다음 식도 일반적으로 참이지만, 역시 필수는 아니다.
x.clone() .equals(x)

관례상, 이 메서드가 반환하는 객체는 super.clone을 호출해 얻어야 한다.
이 클래스와 (Object를 제외한) 모든 상위 클래스가 이 관례를 따른다면 다음 식은 참이다.
x.clone().getClassO = x.getClass()

관례상, 반환된 객체와 원본 객체는 독립적이어야 한다.
이를 만족하려면 super.clone으로 얻은 객체의 필드 중 하나 이상을 반환 전에 수정해야 할 수도 있다.

강제성이 없다는 점만 빼면 생성자 연쇄(constructor chaining)와 살짝 비슷한 메커니즘이다.

단, 주의할 점은 어떤 클래스의 하위 클래스에서 super.clone을 호출한다면 잘못된 클래스의 객체가 만들어져, 결국 하위 클래스의 clone 메서드가 제대로 동작하지 않게 된다는 점이다.

 

무슨 말이냐면

클래스 B가 클래스 A를 상속할 때. 하위 클래스인 B의 clone은 B 타입 객체를 반환해야 한다.

그런데 A의 clone이 자신의 생성자, 즉 new A()로 생성한 객체를 반환한다면 B의 clone도 A 타입 객체를 반환할 수밖에 없다.

즉, super.clone을 연쇄적으로 호출하도록 구현해두면 clone이 처음 호출된 상위 클래스의 객체가 만들어진다.

 

무슨말일까? 아래와 같이 테스트 코드를 짜 본 후 Child를 호출해보자.

super.clone에서 상위 객체인 Parent를 생성 하는 것이 아니라 처음 호출 된 Child를 생성하게 된다.

package com.example.sypark9646.item13;

import lombok.Getter;
import lombok.ToString;
import lombok.extern.slf4j.Slf4j;

@Slf4j
@ToString
@Getter
public class Parent implements Cloneable {

		private String parentField;

		public Parent(String parentField) {
				this.parentField = parentField;
		}

		@Override
		public Parent clone() {
				try {
						Object clone = super.clone();
						log.info("class Parent: " + clone.getClass());
						return (Parent) clone;
				} catch (CloneNotSupportedException e) {
						throw new AssertionError();
				}
		}
}
package com.example.sypark9646.item13;

import lombok.Getter;
import lombok.extern.slf4j.Slf4j;

@Slf4j
@Getter
public class Child extends Parent implements Cloneable { // cloneable 는 생략해도 됨

		public int childField;

		public Child(String parentField, int childField) {
				super(parentField);
				this.childField = childField;
		}

		@Override
		public Child clone() {
				// 상위 Parent class 에서 CloneNotSupportedException 을 잡아줌
				Object clone = super.clone();
				log.info("class Child: " + clone.getClass());
				return (Child) clone;
		}

		@Override
		public String toString() {
				return "Child(parentField=" + this.getParentField() + ", childField=" + this.getChildField() + ")";
		}
}
package com.example.sypark9646.item13;

import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;

public class CloneChainingTest {

		@Test
		@DisplayName("clone test")
		void superCloneAndInteritenceTest() {
				Parent parent = new Parent("parent");
				Child child = new Child("parent", 1);
				System.out.println("parent: " + parent);
				System.out.println("child: " + child);

				System.out.println("[parent clone]");
				Parent parentClone = parent.clone();
				System.out.println("parent clone: " + parentClone); // parent: Parent(parentField=parent)

				System.out.println("[child clone]");
				Child childClone = child.clone();
				System.out.println("child clone: " + childClone); // child: Child(parentField=parent, childField=1)

				Assertions.assertSame(parent.getClass(), parentClone.getClass());
				Assertions.assertSame(child.getClass(), childClone.getClass());
				Assertions.assertTrue(parentClone.getParentField().hashCode() == childClone.getParentField().hashCode()); // 동일한 참조값
		}
}

 

아래 스택오버 플로우에서 더 자세한 내용을 확인할 수 있다.

stackoverflow.com/questions/11905630/java-super-clone-method-and-inheritance

 

Java: super.clone() method and inheritance

I have a quick question regarding the clone() method in Java, used as super.clone() in regard to inheritance - where I call the clone() method in the parent class all the way up from the button. The

stackoverflow.com

사실 테스트를 짜 봐도 super.clone을 호출했을 때 Parent의 clone을 사용하고 있고,

Child를 만드는건데 당연히 Child만 만들어져야 하는 것 아닌가? 싶기도 하고... 잘 와닿지 않아 스터디 팀원분들께 질문 드렸다.

github.com/dolly0920/Effective_Java_Study/issues/33

 

[ITEM 13 Question] - 상속 관계에서 super.clone 호출에 대한 문제점 · Issue #33 · dolly0920/Effective_Java_Study

item13 p.78 (옮긴이) 클래스 B가 클래스 A를 상속할 때. 하위 클래스인 B의 clone은 B 타입 객체를 반환해야 한다. 그런데 A의 clone이 자신의 생성자, 즉 new A(..)로 생성한 객체를 반환한다면 B의 clone도 A

github.com

 

정리하자면 위 예시처럼 parent class에 object.clone을 사용했을 땐 문제가 되지 않지만,

예시로 주신 코드와 같이 parent class를 clone 할 때 아래와 같이 생성자를 사용하게 되면 문제가 된다.

package com.example.sypark9646.item13;

import lombok.Getter;
import lombok.ToString;
import lombok.extern.slf4j.Slf4j;

@Slf4j
@ToString
@Getter
public class Parent implements Cloneable {

		private String parentField;

		public Parent(String parentField) {
				this.parentField = parentField;
		}

		@Override
		public Parent clone() {
				Parent clone = new Parent(this.getParentField());
				log.info("class Parent: " + clone.getClass());
				return clone;
		}
}

요 부분만 바꿨을 뿐인데, Child clone에서는 parent 클래스의 다운캐스팅이 일어나게 되고, 이 부분에서 런타임 에러가 발생하게 되는 것..


 

불변 객체에서 제대로 동작하는 clone 메서드를 가진 상위 클래스를 상속해 Cloneable을 구현하고 싶다고 해보자.

class phoneNumber implements Cloneable {

	...
	
	@Override 
	public PhoneNumber clone() {
		try { 
			// Object의 clone 메서드는 Object를 반환하지만 Phone Number의 clone 메서드는 PhoneNumber를 반환하게 했다
			return (PhoneNumber) super.clone(); 
		} catch (CloneNotSupportedException e) {
			throw new AssertionError(); 
		}
	}
}

 

여기서 super.clone 호출을 try-catch 블록으로 감싼 이유는 Object의 clone 메서드가 검사 예외(checked exception)인 CloneNotSupportedException을 던지도록 선언되었기 때문이다. (CloneNotSupported Exception이 사실은 비 검사 예외 (unchecked exception) 였어야 했다. 아이템71)

 

 

만약 가변 객체에 대한 clone을 만들고 싶다면 어떻게 될까?

참조변수의 경우 동일한 값을 가지기 때문에 한 쪽이 바뀌면 다른쪽도 바뀌게 된다.

따라서 clone 메소드가 원본 객체에 영향을 끼치지 않기 위해서는 참조 변수 내부 정보를 재귀적으로 복사해야 한다.

 

아이템7에 나왔던 Stack 예제를 살펴보자.

elements를 복제할 때 elements.clone을 호출하게 되는데, 이때 elements 필드가 final이라면 복제할 수 없다. (final에는 새로운 값 할당 불가)

package com.example.sypark9646.item13;

import java.util.Arrays;
import java.util.EmptyStackException;

public class StackExample implements Cloneable {

		private Object[] elements;
		private int size = 0;
		private static final int DEFAULT_INITIAL_CAPACITY = 16;

		public StackExample() {
				this.elements = new Object[DEFAULT_INITIAL_CAPACITY];
		}

		public void push(Object e) {
				ensureCapacity();
				elements[size++] = e;

		}

		public Object pop() {
				if (size == 0) {
						throw new EmptyStackException();
				}
				Object result = elements[--size];
				elements[size] = null; // 다 쓴 참조 해제 return result;
				return result;
		}

		// 원소를 위한 공간을 적어도 하나 이상 확보한다.
		private void ensureCapacity() {
				if (elements.length == size) {
						elements = Arrays.copyOf(elements, 2 * size + 1);
				}
		}

		@Override
		public StackExample clone() {
				try {
						StackExample result = (StackExample) super.clone();
						result.elements = elements.clone(); // elements 배열의 clone을 재귀적으로 호출
						return result;
				} catch (CloneNotSupportedException e) {
						throw new AssertionError();
				}
		}
}

 

 

이 경우에는 element가 Object[]이기 때문에 제대로 복사가 됐다면, clone을 재귀적으로 호출하는 것만으로 충분하지 않은 경우도 있다.

package com.example.sypark9646.item13;

public class HashTableExample {

		private Entry[] buckets = new Entry[100];

		private static class Entry {

				final Object key;
				Object value;
				Entry next;

				Entry(Object key, Object value, Entry next) {
						this.key = key;
						this.value = value;
						this.next = next;
				}

//				Entry deepCopy() { // 재귀 방식은 스택 오버플로를 일으킬 위험이 있다
//						return new Entry(key, value, next == null ? null : next.deepCopy());
//				}

				Entry deepCopy() { // 반복자를 써서 순회하자
						Entry result = new Entry(key, value, next);
						for (Entry p = result; p.next != null; p = p.next) {
								p.next = new Entry(p.next.key, p.next.value, p.next.next);
						}
						return result;
				}
		}

		@Override
		public HashTableExample clone() {
				try {
						HashTableExample result = (HashTableExample) super.clone();

						result.buckets = new Entry[buckets.length];

						for (int i = 0; i < buckets.length; i++) {
								if (buckets[i] != null) {
										result.buckets[i] = buckets[i].deepCopy();
								}
						}
						return result;
				} catch (CloneNotSupportedException e) {
						throw new AssertionError();
				}
		}
}

 

이 때에는 Entry의 deepCopy를 만들어 연결 리스트를 복사하게 되는데,

주의 할 점은 재귀적으로 들어가게 되면 연결 리스트의 크기가 클 경우 재귀 스택이 너무 많아져서 스택 오버플로우를 일으킬 수 있기 때문에

반복자로 deepCopy를 만들도록 하자

 

Object의 clone 메서드는 CloneNotSupportedExceptioin을 던지지만 재정의한 메서드는 throws 절을 없애는 편이 좋다.

검사 예외를 던지지 않아야 그 메서드를 사용하기 편하기 때문이다(아이템 71).

 

Parent-Child 클래스들에서 본 것과 같이, 상속해서 쓰기 위한 클래스 설계 방식 두 가지(아이템 19) 중 어느 쪽에서든, 상속용 클래스는 Cloneable을 구현해서는 안 된다.

 

대신 Object의 방식을 모방하여 제대로 작동하는 clone 메서드를 구현해 protected로 두고 CloneNotSupportedException도 던질 수 있다. 이 방식은 Object를 바로 상속할 때처럼 Cloneable 구현 여부를 하위 클래스에서 선택하도록 해준다.

 

다른 방법으로는, clone을 동작하지 않게 구현해놓고 하위 클 래스에서 재정의하지 못하게 할 수도 있다.

아래와 같이 clone을 쓰지 못하도록 Exception을 걸어두면 된다.

@Override 
protected final Object clone() throws CloneNotSupportedException { 
	throw new CloneNotSupportedException(); 
}

 

마지막으로 주의할 점은 Cloneable을 구현한 스레드 안전 클래스를 작성할 때는 clone 메서드 역시 적절히 동기화해줘야 한다.(아이템 78)

Object의 clone 메서드는 동기화를 신경 쓰지 않았다!! 

따라서 호출외에 다른 할 일이 없더라도 clone을 재정의하고 동기화해줘야 한다.

이를 위해서는 Cloneable을 구현하는 모든 클래스는 clone을 재정의해야 하며, 접근 제한자는 public으로, 반환 타입은 클래스 자신으로 변경한다.

이 메소드는 가장 먼저 super.clone을 호출한 후 필요한 필드를 전부 적절히 수정하게 된다. (객체의 deepCopy 실행)

 

 


 

휴... 넘 복잡하다. 그러니까 Cloneable을 이미 구현한 클래스를 확장하는 경우 외에는 복사 생성자와 복사 팩터리라는 더 나은 객체 복사 방식을 제공하도록 하는 것이 좋겠다.

  • 복사 생성자: 단순히 자신과 같은 클래스의 인스턴스를 인수로 받는 생성자
  • 복사 팩터리: 복사 생성자를 모방한 정적 팩터리 메서드
		public Parent(Parent parent) { // 복사 생성자
				this.parentField = parent.getParentField();
		}

		public static Parent newInstance(Parent parent) { // 복사 팩터리
				return new Parent(parent.getParentField());
		}

위와 같은 방식이 Cloneable/clone 방식보다 나은 이유는,

생성자를 쓰지 않는 방식이 아니기 때문에 엉성한 clone 규약에 기대지 않고, 정상적인 final 필드 용법과도 충돌하지 않으며, 불필요한 검사 예외를 던지지 않고, 형변환도 필요치 않다.

또 다른 장점은 해당 클래스가 구현한 `인터페이스` 타입의 인스턴스를 인수로 받을 수 있다. 이를 변환 생성자 (conversion constructor)와 변환 팩터리 (conversion factory) 라고 한다. 이들을 이용 하게 되면 클라이언트는 원본의 구현 타입에 얽매이지 않고 복제본의 타입을 직접 선택할 수 있다.

ex. HashSet 객체를 TreeSet 타입으로 복제할 수 있다.

 

 

 

용어

  • 공변 반환 타이핑 (covariant return typing): 자바 5에 추가된 개념으로, 메소드가 오버라이딩 될 때 더 좁은 타입으로 대체될 수 있다는 것이다.
  • 검사예외와 비검사예외
    • 복구 가능하다고 믿는다면 검사 예외 => 프로그래머가 명시적으로 예외 처리
    • 그렇지 않다면 런타임 예외를 사용한다

 

Object의 기본 toString 메서드는 단순히 클래스이름@16진수해시코드를 반환한다.

Object.toString

toString의 일반 규약에 따르면 `간결하면서 사람이 읽기 쉬운 형태의 유익한 정보`를 반환해야 한다.

또한 toString의 규약에서는 `모든 하위 클래스에서 이 메서드를 재정의하라`고 한다.

 

toString을 잘 구현한 클래스는 디버깅하기 쉽다.

toString 메서드는 객체를 println, printf, 문자열 연결 연산자(+), assert 구문에 넘길 때, 혹은 디버거가 객체를 출력할 때 자동으로 불린다.

오류 메시지 등을 로깅할 때도 자동으로 호출될 수 있다.

 

 

따라서 실전에서 toString은 그 객체가 가진 주요 정보 모두를 반환하는 게 좋다. 

하지만 객체가 거대하거나 객체의 상태가 문자열 로 표현하기에 적합하지 않다면 요약 정보를 담아야 한다. (사이즈나 id 등)

 

toString을 구현할 때면 반환값의 포맷을 문서화할지 정해야 한다. (값 클래스라면 문서화하는 것이 좋다)

포맷을 명시하기로 했다면, 명시한 포맷에 맞는 문자열과 객체를 상호 전환할 수 있는 정적 팩터리나 생성자를 함께 제공해주면 좋다.

자바 플랫폼의 많은 값 클래스가 따르는 방식이기도 하다. BigInteger, BigDecimal과 대부분의 기본 타입 클래스가 여기 해당한다.

BigInteger.toString
BigInteger String 생성자

 

 

toString을 제공할 때에는 포맷 명시를 해 두는 것이 좋고, toString이 반환한 값에 포함된 정보를 얻어올 수 있는 API를 제공하도록 하자.

그렇지 않으면 이 정보가 필요한 프로그래머는 toString의 반환값을 파싱할 수밖에 없다. 이 경우 성능이 나빠지고, 작업량이 늘어나며, 향후 포맷을 바꾸면 시스템이 망가질 수 있다.

정적 유틸리티 클래스(아이템 4)는 toString을 제공할 이유가 없다. 또한, 대 부분의 열거 타입(아이템 34)도 자바가 이미 완벽한 toString을 제공하니 따로 재정의하지 않아도 된다. 하지만 하위 클래스들이 공유해야 할 문자열 표현이 있는 추상 클래스라면 toString을 재정의해줘야 한다. (대다수의 컬렉션 구현체는 추상 컬렉션 클래스들의 toString 메서드를 상속)

 

equals를 재정의한 클래스 모두에서 hashCode도 재정의해야 한다.

그렇지 않으면 hashCode 일반 규약을 어기게 되어 해당 클래스의 인스턴스를 HashMap 이나 HashSet 같은 컬렉션의 원소로 사용할 때 문제를 일으키게 된다고 한다.

 

아래는 Object 메소드의 hashcode이다.

Object.hashcode

정리해 보자면, 

  1. equals 비교에 사용되는 정보가 변경되지 않았다면, 애플리케이션이 실행되는 동안 그 객체의 hashCode 메서드는 몇 번을 호출해도 일관되게 항상 같은 값을 반환해야 한다. 단, 애플리케이션을 다시 실행한다면 이 값이 달라져도 상관없다.
  2. equals(Object)가 두 객체를 같다고 판단했다면, 두 객체의 hashCode는 똑같은 값을 반환해야 한다.
  3. equals(Object)가 두 객체를 다르다고 판단했더라도, 두 객체의 hashCode가 서로 다 른 값을 반환할 필요는 없다. 단, 다른 객체에 대해서는 다른 값을 반환해야 해시테이블 의 성능이 좋아진다.

hashCode 재정의를 잘못했을 때 크게 문제가 되는 조항은 두 번째 문항이다.

논리적으로 같은 객체는 같은 해시코드를 반환해야 한다.

아이템 10에서 보았듯이 equals는 물리적으로 다른 두 객체를 논리적으로는 같다고 할 수 있다.

하지만 Object의 기본 hashCode 메서드는 이 둘이 전혀 다르다고 판단하여, 규약과 달리 (무작위처럼 보이는) 서로 다른 값을 반환한다.

 

 

이 내용을 보기 전에, 먼저 hashmap의 동작 원리에 대해 정리하고 가야할 것 같다.

2020/12/19 - [작성중...] - Java HashMap vs LinkedHashMap vs TreeMap - 작성중...

 

Java HashMap vs LinkedHashMap vs TreeMap - 작성중...

HashMap HashMap은 Map 인터페이스를 implements 하고 있다. null key, null value 허용 동기화되지 않고 null을 허용한다는 점을 제외하면 Hashtable과 거의 동일하다. 순서가 보장되지 않는다. 해시맵의 성능을..

sysgongbu.tistory.com

위 글에서 볼 수 있듯이 HashMap은 해시코드가 다른 엔트리끼리는 동치성 비교를 시도조차 하지 않도록 최적화되어 있다.

 

그렇다면 올바른 해시코드를 리턴하기 위한 방법은 무엇일까?

만약 해시코드가 모두 동일한 값을 리턴한다면, HashMap에서는 모든 객체가 해시테이블의 버킷 하나에 담겨 마치 연결 리스트(linked list)처럼 동작한다. 그 결과 평균 수행 시간이 0(1)인 해시테이블이 O(n)으로 느려져서, 객체가 많아지면 도저히 쓸 수 없게 된다.
좋은 해시 함수라면 서로 다른 인스턴스에 다른 해시코드를 반환한다. 아까 보았던 hashCode 규약 3번이다. 이상적인 해시 함수는 주어진 (서로 다른) 인스턴스들을 32비트 정수 범위에 균일하게 분배해야 한다.

 

  1. int 변수 result를 선언한 후 값 c로 초기화한다. (c는 해당 객체의 첫 번째 핵심 필드를 단계 2번 방식으로 계산한 해시코드)
    • 핵심 필드: equals 비교에 사용되는 필드를 말한다. (아이템 10)
  2. 해당 객체의 나머지 핵심 필드 주 각각에 대해 다음 작업을 수행한다.
    • 해당 필드의 해시코드 c를 계산한다.
      • 기본 타입 필드라면, Type.hashCode(f)를 수행한다. 여기서 Type은 해당 기본 타입의 박싱 클래스다.
      • 참조 타입 필드면서 이 클래스의 equals 메서드가 이 필드의 equals 를 재귀적으로 호출해 비교한다면, 이 필드의 hashCode를 재귀적으로 호출한다. 계산이 더 복잡해질 것 같으면, 이 필드의 표준형(canonical representation)을 만들어 그 표준형의 hashCode를 호출한다. 필드의 값이 null이면 0을 사용한다(다른 상수도 괜찮지만 전통적으로 0을 사용)
      • 필드가 배열이라면, 핵심 원소 각각을 별도 필드처럼 다룬다. 규칙을 재귀적으로 적용해 각 핵심 원소의 해시코드를 계산한 다. 배열에 핵심 원소가 하나도 없다면 단순히 상수(일반적으로 0)를 사용한다. 모든 원소가 핵 심 원소라면 Arrays. hashCode 를 사용한다.
    • 단계 2.a에서 계산한 해시코드 c로 result를 갱신한다. 코드로는 다음 과 같다.
      • result = 31 * result + c;
  3. result를반환한다.

이때, equals 비교에 사용되지 않은 필드는 반드시 제외해야 한다. 그렇지 않으면 hashCode 규약 2번을 어기게 될 수 있다.

 

아래는 위 규칙에 따라 샘플로 만든 해시 코드이다.

@Override 
public int hashCode() {
	int result = Short.hashCode(areaCode); 
	result = 31 * result + Short.hashCode(prefix); 
	result = 31 * result + Short.hashCode(lineNum); 
	return result;
}

 

여기서 왜 31을 곱해야 하는지에 대한 생각은 스터디원이 잘 정리해 주어서 많은 도움이 됐다.

github.com/dolly0920/Effective_Java_Study/issues/25

 

[ITEM 11 Extension] - 왜 hashCode 계산에는 31이 들어가는가? · Issue #25 · dolly0920/Effective_Java_Study

저 같은 무근본 코더는 별 이상한게 궁금합니다. 실제로 자바 라이브러리 내부에도 hashCode 계산에 31을 사용하는 경우가 잦습니다. // StringUTF16.java public static int hashCode(byte[] value) { int h = 0; int lengt

github.com

 

해싱 함수의 구현 대해 더 알고 싶다면 아래를 참고하면 좋다.

guava.dev/releases/21.0/api/docs/com/google/common/hash/Hashing.html

 

Hashing (Guava: Google Core Libraries for Java 21.0 API)

Returns a hash function implementing FarmHash's Fingerprint64, an open-source algorithm. This is designed for generating persistent fingerprints of strings. It isn't cryptographically secure, but it produces a high-quality hash with fewer collisions than s

guava.dev

 

위 방식 외에도 Objects 클래스의 임의의 개수만큼 객체를 받아 해시코드를 계산해주는 정적 메서드인 hash를 사용할 수도 있다.

@Override 
public int hashCode() { return Objects.hash(lineNum, prefix, areaCode); }

하지만 성능상 좋진 않다. 여러 입력 인수를 담기 위한 배열이 만들어지고, 입력 중 기본 타입이 있다면 박싱과 언박싱도 거쳐야 하기 때문이다.

 

 

클래스가 불변이고, 해시코드를 계산하는 비용이 크다면, 매번 새로 계산하기 보다는 캐싱하는 방식을 고려해야 한다.

이 타입의 객체가 주로 해시의 키로 사용될 것 같다면 인스턴스가 만들어질 때 해시코드를 계산해둬야 한다.

만약 해시의 키로 사용되지 않는 경우라면 hashCode가 처음 불릴 때 계산하는 지연 초기화(lazy initialization) 전략을 사용할 수도 있다. 이 경우에는 클래스를 스레드 안전하게 만들도록 신경 써야 한다(아이템 83).

예시는 아래와 같다. 주의할 점은 hashCode 필드의 초깃값은 흔히 생성되는 객체의 해시코드와는 달라야 한다는 점이다.

private int hashCode; // 자동으로 0으로 초기화된다.

@Override 
public int hashCode() { 
	int result = hashCode;

	if (result == 0) {
		result = Short.hashCode(areaCode); 
		result = 31 * result + Short.hashCode(prefix); 
		result = 31 * result + Short.hashCode(lineNum); hashCode = result;
	} 
	return result;
}

 

결론부터 말하자면 equals는 아래와 특별한 케이스 외에는 재정의 하지 않도록 한다.

 

특히 아래와 같은 경우는 재정의 하지 않도록 하자.

  1. 각 인스턴스가 본질적으로 고유한 경우
    • 값을 표현하는 게 아니라 동작하는 개체를 표현하는 클래스의 경우 ex) Thread
  2. 인스턴스의 논리적 동치성을 검사할 일이 없는 경우
    • 논리적 동치: 두 명제 p, q에 대해 쌍방 조건이 항진 명제인 경우, 즉 p<=>q
    • 항진 명제: 논리식 혹은 합성명제에 있어 각 명제의 참·거짓의 모든 조합에 대하여 항상 참인 것
    • 즉, 쉽게 말하면 인스턴스들 끼리 equals() 메서드를 사용해서, 논리적으로 같은지 검사할 필요가 없는 경우에는 Object의 기본 equals 로만으로도 해결한다.
  3. 상위 클래스에서 재 정의한 equals가 하위 클래스에도 적용되는 경우
    • HashSet, TreeSet, EnumSet 등 대부분의 Set 구현체 - AbstractSet 에서 정의된 equals 사용
    • ArrayList, Vector 등 대부분의 List 구현체 - AbstractList 에서 정의된 equals 사용
    • HashMap, TreeMap, EnumMap 등 대부분의 Map 구현체 - AbstractMap 에서 정의된 equals 사용
  4. 클래스가 private이거나 package-private이고, equals 메소드를 호출할 일이 없는 경우
    • equals 메서드를 오버라이딩해서 호출되지 않도록 막자
@Override
public boolean equals(Object o) {
    throw new AssertionError(); // 메서드 호출 방지
}

 


 

equals를 재정의해야 하는 경우는 두 객체가 물리적으로 같은지 비교할 때가 아니라, 논리적 동치성을 확인해야 하며, 상위 클래스의 equals가 현재 클래스의 논리적 동치성을 비교하기에 적절하지 않을 경우이다.

 

주로 값 클래스들이 여기 해당하는데, 값 클래스란 Integer와 String처럼 값을 표현하는 클래스를 말한다.

값 객체의 equals를 재정의 하여 논리적 동치성을 확인하도록 하면, 인스턴스의 값을 비교할 수 있고, Map의 키와 Set의 원소로도 사용할 수 있게 된다.

 

만약 값 클래스라 하더라도 싱글톤이면 equals를 재정의하지 않아도 된다. Enum(아이템 34)도 여기에 해당한다.

이런 클래스에서는 어차피 논리적으로 같은 인스턴스가 2개 이상 만들어지지 않기 때문에 논리적 동치성과 객체 식별성이 사실상 똑같은 의미가 된다. 따라서 Object의 equals가 논리적 동치성까지 확인 해준다고 볼 수 있다.

 

 

equals 메소드를 재 정의할 때에는 동치관계(equivalence relation)를 만족해야한다.

 

1. 반사성(reflexivity): null이 아닌 모든 참조 값 x에 대해, x.equals(x) = true

객체는 자기 자신과 같아야 한다는 의미를 가진다.


2. 대칭성(symmetry): null이 아닌 모든 참조 값 x, y에 대해, x.equals(y) = true 이면 y.equals(x) = true

두 객체는 서로에 대한 동치 여부에 똑같이 답해야 한다는 의미이다. 이는 서로 다른 클래스의 객체를 비교할 때 위반될 수 있다.

예를 들어 아래와 같은 CaseInsensitiveString 을 정의 했을 때, 

public final class CaseInsensitiveString {
    private final String s;

    public CaseInsensitiveString(String s) {
        this.s = Objects.requireNonNull(s);
    }
    @Override
    public boolean equals(Object o) {
        if( o instanceof CaseInsensitiveString) {
            return s.equalsIgnoreCase((CaseInsensitiveString) o).s);
        }
        if ( o instanceof String) {
            return s.equalsIgnoreCase((String) o);
        }
    }
} 

실행 결과는 아래와 같이 다른 값을 반환하게 된다. 그 이유는 CaseinsensitiveString의 equals는 일반 String을 알고 있지만, String의 equals는 Case InsensitiveString의 존재를 모르기 때문이다.

CaseInsensitiveString cis = new CaseInsensitiveString("Media");
String s = "media";

cis.equals(s); // true
s.equals(cis); // false


3. 추이성(transitivity): null이 아닌 모든 참조 값 x, y, z에 대해, x.equal이(y)=true 이고 y.equals(z)=true 이면 x.equals(z) = true

추이성의 경우 상위 클래스에는 없는 새로운 필드를 하위 클래스에 추가하는 상황에서 위반될 수 있다.

예를 들어 아래와 같이 2차원의 점을 표현하는 Point 클래스와 이를 확장한 ColorPoint 클래스를 정의해 보자.

class Point {

	private final int x;
	private final int y;

	public Point(int x, int y) {
		this.x = x;
		this.y = y;
	}

	@Override
	public boolean equals(Object o) {
		if (!(o instanceof Point)) {
			return false;
		}
		Point p = (Point) o;
		return p.x == x && p.y == y;
	}
}
public class ColorPoint extends Point {
	private final Color color;

	public ColorPoint(int x, int y, Color color) {
		super(x, y);
		this.color = color;
	}

	@Override
	public boolean equals(Object o) {
		if (!(o instanceof Point)) {
			return false;
		}

		// o가 일반 Point 이면 색상을 무시하고 비교한다.
		if (!(o instanceof ColorPoint)) {
			return o.equals(this);
		}

		// o가 ColorPoint 이면 색상까지 비교한다.
		return super.equals(o) && ((ColorPoint) o).color == color;

	}
}

이 경우 ColorPoint에서 equals를 재정의 하지 않으면 색상 정보는 무시한 채 비교를 수행하게 된다. 

또한, 위와 같이 equals를 재정의 하게 되면 추이성을 위배하게 된다.

p1p2 와 p2p3 비교에서는 색상을 무시했지만, p1p3 비교에서는 색상까지 고려했기 때문이다.

ColorPoint p1 = new ColorPoint(1, 2, Color.RED); 
Point p2 = new Point(1, 2); 
ColorPoint p3 = new ColorPoint(1, 2, Color.BLUE);

pl.equals(p2); // true
p2.equals(p3); // true
pl.equals(p3); // false

사실 객체 지향적 추상화의 이점을 포기하지 않는 한, 구체 클래스를 확장해 새로운 값을 추가하면서 equals 규약을 만족시킬 방법은 존재하지 않는다.

 

equals 안의 instanceof 검사를 getClass 검사로 바꾸면 가능하다고 생각할 수도 있다. 하지만, 이 경우는 같은 구현 클래스의 객체와 비교할 때만 true를 반환하게 된다.

=> Point의 하위 클래스는 정의상 여전히 Point이므로 어디서든 Point로써 활용될 수 있어야 한다. (리스코프 치환 원칙)

 

자바 라이브러리에도 구체 클래스를 확장해 값을 추가한 클래스가 종종 있다. java.util.Date와 java.util.Timestamp 관계가 이와 같다. 그래서 Timestamp의 equals는 대칭성을 위배하며 , Date 객체와 한 컬렉션에 넣거나 서로 섞어 사용하면 엉뚱하게 동작할 수 있다. 아래는 javadocs에 기술되어 있는 주의점이다.

 

이와 관련된 내용은 아래 스택오버플로우에도 잘 나와있다.

stackoverflow.com/a/596507/11285469

 

Any reason to prefer getClass() over instanceof when generating .equals()?

I'm using Eclipse to generate .equals() and .hashCode(), and there is an option labeled "Use 'instanceof' to compare types". The default is for this option to be unchecked and use .getClass() to c...

stackoverflow.com

https://www.artima.com/intv/bloch.html#part17

The reason that I favor the instanceof approach is that when you use the getClass approach, you have the restriction that objects are only equal to other objects of the same class, the same run time type. If you extend a class and add a couple of innocuous methods to it, then check to see whether some object of the subclass is equal to an object of the super class, even if the objects are equal in all important aspects, you will get the surprising answer that they aren't equal. In fact, this violates a strict interpretation of the Liskov substitution principle, and can lead to very surprising behavior. In Java, it's particularly important because most of the collections (HashTable, etc.) are based on the equals method. If you put a member of the super class in a hash table as the key and then look it up using a subclass instance, you won't find it, because they are not equal.
Because of these problems, I didn't even bother discussing the getClass approach. But it turns out that because it does let you add aspects while preserving the equals contract, some people favor it. So I just want to get the information out there that it has disadvantages too. The biggest disadvantage is the fact that you get two objects that appear equal (because they are equal on all the fields) but they are not equal because they are of different classes. This can cause surprising behavior.
I'm going to write an essay discussing this in more detail. When it's done, I'll put it up on the book's web site. It will compare the two approaches and discuss the pros and cons.

Bill Venners: The reason I have used getClass in the past is because I don't know what is going to happen in subclasses. I can't predict that when I am writing my class. It seemed risky to me to use instanceof. If I used instanceof and someone passed a subclass instance to my superclass equals method, I would determine semantic equality by comparing only fields that exist in the superclass. I'd be ignoring any fields declared in subclasses, and it seems like they could be important to the notion of semantic equality for the subclass.
The other way to look at it I guess is that using instanceof in a superclass equals method makes it harder to write subclasses, because equals is supposed to be symmetric. If you call the subclass's equals method implementation, passing in an instance of the superclass, it must return the same result as if you passed the subclass instance to the superclass's equals method.

Josh Bloch: Yes. You are correct in saying that using getClass in equals makes it much easier to preserve the equals contract, but at what cost? Basically, at the cost of violating the Liskov substitution principle and the principle of least astonishment. You write something that obeys the contract, but whose behavior can be very surprising.

정리하자면, instanceof 접근 방식을 선호하는 이유는 getClass 접근 방식을 사용할 때 객체가 동일한 런타임 유형인 동일한 클래스의 다른 객체와 만 동일하다는 제한이 있기 때문이다. 클래스를 확장하고 몇 가지 메서드를 추가하면 하위 클래스의 일부 객체가 수퍼 클래스의 객체와 동일한 지 확인하게 된다.

Java에서는 대부분의 컬렉션 (HashTable 등)이 equals 메소드를 기반으로하기 때문에 특히 중요한데, getClass 를 사용하게 되면 슈퍼 클래스의 멤버를 키로 해시 테이블에 넣은 다음 하위 클래스 인스턴스를 사용하여 조회하면 같지 않기 때문에 찾을 수 없게 될 수도 있다.

+) 추가적으로 추상클래스에서라면 equals 메소드 재정의로 해결 가능하다


4. 일관성(consistency): nuII이 아닌 모든 참조 값 x, y에 대해, x.equals(y)를 반복해서 호출하면 항상 같은 값을 반환

두 객체가 같다면 (어느 하나 혹은 두 객체 모두가 수정되지 않는 한) 앞으로도 영원히 같아야 한다는 의미이다.

또한, 클래스가 불변이든 가변이든 equals의 판단에 신뢰할 수 없는 자원이 끼어 들게 해서는 안 된다.

 

ex) java.net.URL의 equals는 URLStreamHandler를 이용하여 주어진 URL과 매핑된 호스트의 IP 주소 를 이용해 비교한다.

호스트 이름을 IP 주소로 바꾸려면 네트워크를 통해야 하 는데, 그 결과가 항상 같다고 보장할 수 없다.

URL.equals
URLStreamHandler.equals

=> 이런 문제를 피하려면 equals는 항시 메모리 에 존재하는 객체만을 사용한 결정적 (deterministic) 계산만 수행해야 한다.

 

5. null-아님: null이 아닌 모든 참조 값 x에 대해, x.equals(null)은 false다.

이름처럼 모든 객체가 null과 같지 않아야 한다는 의미이다.

특히 NullPointerException을 던지는 방식이 자주 발생할 수 있는데, equals에서는 이런 경우도 허용하지 않는다.

이 때, 명시적 null 검사를 하기 보다는 아래와 같이 건네받은 객체를 적절히 형변환한 후 필수 필드들의 값을 알아내도록 한다.

(이를 위해서는 형변환에 앞서 instanceof 연산자로 입력 매개변수가 올바른 타입 인지 검사해야 한다.)

@Override 
public boolean equals(Object o) { 
	if (!(o instanceof MyType)) {
		return false; 
	}
	MyType mt = (MyType) o; 
	...
}

+ equals가 타입을 확인하지 않으면 잘못된 타입이 인수로 주어졌을 때 Class CastException을 던져서 일반 규약을 위배하게 된다. 

=> instanceof는 (두 번째 피 연산자와 무관하게) 첫 번째 피 연산자가 null이면 false를 반환한 다. 따라서 입력이 null이면 타입 확인 단계에서 false를 반환하 기 때문에 null 검사를 명시적으로 하지 않아도 된다.

 

 

Object 클래스의 equals를 살펴보면 재 정의 시 위의 동치관계들을 모두 만족해야 함을 알 수 있다.

만약 아래 equals 규약을 어기면 그 객체를 사용하는 다른 객체들이 어떻게 반응할지 알 수 없다.

Object.equals


위의 내용들을 정리하여 equals 메소드에 대한 재정의를 단계별로 알아보자

 

public final class phoneNumber {
    private final short areaCode, prefix, lineNum;

    @Override
    public boolean equals(Object o) {
        if( o == this) { // 1. == 연산자를 사용해 입력이 자기 자신의 참조인지 확인
            return true;
        }

        if( o == null) { // 널 체크
            return false;
        }

        if(!(o instanceof PhoneNumber)) { // 2. instanceof 연산자로 입력이 올바른 타입인지 확인
            return false;
        }

        PhoneNumber pn = (PhoneNumber)o; // 3. 입력을 올바른 타입으로 형변환
        return pn.lineNum == lineNum && pn.prefix == prefix
                        && pn.areaCode == areaCode; // 4. 입력 객체와 자기 자신의 대응되는 핵심 필드들이 모두 일치하는지 하나씩 검사
    }
}

 

1. == 연산자를 사용해 입력이 자기 자신의 참조인지 확인한다. 

자기 자신이 면 true를 반환한다. 이는 단순한 성능 최적화용으로, 비교 작업이 복잡한 상황일 때 값어치를 할 것이다.

 

2. instanceof 연산자로 입력이 올바른 타입인지 확인한다. 그렇지 않다면 false를 반환한다. 

이때의 올바른 타입은 equals가 정의된 클래스인 것이 보통이지만, 가끔은 그 클래스가 구현한 특정 인터페이스가 될 수도 있다. 어떤 인터페이스는 자신을 구현한 (서로 다른) 클래스끼리도 비교할 수 있 도록 equals 규약을 수정하기도 한다. 이런 인터페이스를 구현한 클래스라면 equals에서 (클래스가 아닌) 해당 인터페이스를 사용해야 한다.

ex) Set, List, Map, Map.Entry 등

 

3. 입력을 올바른 타입으로 형변환한다.

 

4. 입력 객체와 자기 자신의 대응되는 ‘핵심’ 필드들이 모두 일치하는지 하나씩 검사한다. 

모든 필드가 일치하면 true를, 하나라도 다르면 false를 반환

=> 2단계에서 인터페이스를 사용했다면 입력의 필드 값을 가져올 때도 그 인터페이스의 메서드를 사용해야 한다.

타입이 클래스라면 (접근 권한 에 따라) 해당 필드에 직접 접근할 수도 있다.

 

주의할 점은 float와 double을 제외한 기본 타입 필드는 == 연산자로 비교하고, 참조 타입 필드는 각각의 equals 메서드로, 

float와 double 필드는 각각 정적 메서드인 XXX.compare(x1, x2)로 비교한다. (Nan, -0.0f, 특수한 부동소수 값 등을 다뤄야 하기 때문)

=> XXX.equals를 대신 사용할 수 있으나, 이 경우에는 오토박싱을 사용하게 되어서 성능 상 좋지 않다.

+) null도 정상 값으로 취급하는 참조 타입 필드의 경우는 Object.equals를 사용하도록 한다. (NullPointerException 발 생을 예방)

 

만약 CaselnsensitiveString 처럼 복잡한 필드를 가진 클래스를 비교할 때에는 필드의 표준형(canonical form)을 저장해둔 후, 표준형끼리 비교하면 훨씬 경제적이다. 이 기법은 특히 불변 클래스(아이템 17)에 좋다.

 

어떤 필드를 먼저 비교하느냐가 equals의 성능을 좌우하므로 다를 가능성이 더 크거나 비교하는 비용이 싼 필드를 먼저 비교하자.

동기화용 락(lock) 필드 같이 객체의 논리적 상태와 관련 없는 필드는 비교하면 안 된다. 핵심 필드로부터 계산해낼 수 있는 파생 필드 역시 굳이 비교할 필요는 없지만, 파생 필드를 비교하는 쪽이 더 빠 를 때도 있다. 파생 필드가 객체 전체의 상태를 대표하는 상황이 그렇다.

ex) 자신의 영역을 캐시해두는 Polygon 클래스의 경우

=> 모든 변과 정점을 일일이 비교할 필요 없이, 캐시해둔 영역만 비교하면 결과를 바로 알 수 있다.

 

 

추가적으로 알아둘 점은,

  • equals를 재정의할 땐 hashCode도 반드시 재정의하자(아이템 11)
  • 너무 복잡하게 해결하려 하지 말자. 필드들의 동치성만 검사해도 된다. alias 등은 무시하자.
  • Object 외의 타입을 매개변수로 받는 equals 메서드는 선언하지 말자. (입력 타입이 Object가 아니므로 재정의가 아니라 다중정의임)
class MyClass {
	public boolean equals(MyClass o) { // 재정의가 아니라 다중정의이다 
		// -> 따라서 여기에 @Override 애노테이션을 붙이면 컴파일 에러 발생함
	}
}

 

 

 

 

 

 

 

용어

  • 리스코프 치환 원칙 (Liskov substitution principle): 어떤 타입에 있어 중요한 속성이라면 그 하위 타입에서도 마찬가지로 중요하다. 따라서 그 타 입의 모든 메서드가 하위 타입에서도 똑같이 잘 작동해야 한다. => 서브타입은 언제나 자신이 기반타입 (base type)으로 교체할 수 있어야 한다.

+ Recent posts