태그 달린 클래스는 아래와 같이 어떠한 타입인지에 대한 정보를 담고 있는 멤버 변수(필드)를 가지고 있는 클래스를 말한다.
=> 즉, 상태가 있는 클래스
class Figure {
enum Shape {
RECTANGLE, CIRCLE
};
// 태그 필드 - 현재 양을 나타낸다.
final Shape shape;
double length;
double width;
double radius;
// 원용 생성자 - 원(CIRCLE)일 때만 쓰인다.
Figure(double radius) {
shape = Shape.CIRCLE;
this.radius = radius;
}
// 사각형용 생성자 - 사각형(RECTANGLE)일 때만 쓰인다.
Figure(double length, double width) {
shape = Shape.RECTANGLE;
this.length = length;
this.width = width;
}
double area() {
switch (shape) {
case RECTANGLE:
return length * width;
case CIRCLE:
return Math.PI * (radius * radius);
default:
throw new AssertionError(shape);
}
}
}
태그 달린 클래스의 단점은 아래와 같다.
열거 타입 선언, 태그 필드, switch 문 등 쓸데없는 코드가 많다.
새로운 의미를 추가할 때마다 모든 switch 문을 찾아 새 의미를 처 리하는 코드를 추가해야
여러 구현이 한 클래스에 혼합돼 있어서 가독성도 나쁘다.
필드들을 final로 선언하려면 해당 의미에 쓰이지 않는 필드들까지 생성자에서 초기화해야 함
다른 의미를 위한 코드도 언제나 함께 하니 메모리도 많이 사용한다.
인스턴스의 타입만으로는 현 재 나타내는 의미를 알 길이 전혀 없다.
이렇게 태그달린 클래스 보다는 클래스 계층 구조를 활용하는 서브타이핑 (subtyping)을 사용하는 것이 낫다. 태그 달린 클래스를 클래스 계층구조로 바꾸는 방법은 아래와 같다.
abstract class Figure { // 가장 먼저 계층구조의 루트(root)가 될 추상 클래스를 정의
// 공통 데이터 필드의 경우 추상 클래스에 모아 둔다
abstract double area(); // 태그 값에 따라 동작이 달라지는 메서드들을 루트 클래스의 추상 메서드로 선언
}
class Circle extends Figure { // 루트 클래스를 확장한 구체 클래스
final double radius;
Circle(double radius) {
this.radius = radius;
}
@Override
double area() {
return Math.PI * (radius * radius);
}
}
class Rectangle extends Figure {
final double length;
final double width;
Rectangle(double length, double width) {
this.length = length;
this.width = width;
}
@Override
double area() {
return length * width;
}
}
// 만약 Square 클래스를 추가하고 싶다면 루트 클래스의 코드를 건드리지 않고도 독립적으로 계층구조를 확장할 수 있다.
class Square extends Rectangle { Square(double side) { super(side, side); } }
이렇게 클래스 계층구조로 바뀌게 되면 태그 값에 상관없이, 동작이 일정한 메서드들을 루트 클래스에 일반 메서드로 추가 하면 된다.
클래스 계층구조의 경우 필드들은 모두 final이며, 각 클래스의 생성자가 모든 필드를 남김없이 초기화하고 추상 메서드를 모두 구현했는지 컴파일러가 확인해줄 수 있다. 또한, 타입 사이의 자연스러운 계층 관계를 반영할 수 있어서 유연성은 물론 컴파일타임 타입 검사 능력을 높여준다는 장점도 있다.
디폴트 메서드를 선언하면, 그 인터페이스를 구현한 후 디폴트 메서드를 재정의하지 않은 모든 클래스에서 디폴트 구현이 쓰이게 된다.
디폴트 메서드 덕분에 자바에도 기존 인터페이스에 메서드를 추가할 수 있게 되었다. 하지만 모든 기존 구현체들과 매끄럽게 연동된다는 보장은 없다. 왜냐면 자바 7까지는 인터페이스에 새로운 메서드가 추가될 것을 고려하지 않았기 때문이다.
자바 8에서는 핵심 컬렉션 인터페이스들에 다수의 디폴트 메서드가 추가되었다. 주로 람다를 활용하기 위해서이다.(7장 참조)
(디폴트 메서드는 불변식을 해치지 않아야 함)
java.util.Collection
자바 8의 Collection 인터페이스에 추가된 removelf 디폴트 메서드를 보자.
이 메서드는 주어진 predicate가 true를 반환 하면 원소를 제거하는 구조이다. 디폴트 구현은 반복자를 이용해 순회하면서 각 원소를 인수로 넣어 predicate를 호출하고, predicate가 true를 반환하면 반복자의 remove 메서드를 호출해 그 원소를 제거한다.
Predicate - 인수로 값을 받아 boolean 값을 반환하는 함수로, 람다나 스트림은 제네릭 형태를 사용하는데, Predicate 를 사용하게 되면 boolean을 Boolean으로 변환하는 과정이 없어 더 효율적이다.
위 코드는 범용적으로 구현한 형태이지만 모든 Collection 구현체와 잘 어우러지는 것은 아니다.
org.apache.commons.collections.collection.SynchronizedCollection 를 살펴보자.
// org.apache.commons.collections.collection.SynchronizedCollection: 모든 메서드에서 주어진 락 객체로 동기화한 후 내부 컬렉션 객체에 기능을 위임하는 래퍼 클래스(아이템 18)
public class SynchronizedCollection implements Collection, Serializable {
private static final long serialVersionUID = 2412805092710877986L;
protected final Collection collection;
protected final Object lock; // 아파치 버전은 컬렉션 대신 클라이언트가 제공한 객체로 락을 거는 능력을 추가로 제공
...
}
아파치의 SynchronizedCollection 클래스에는 removelf 메서드를 재정의하지 않고 있다.
이 클래스를 자바 8과 함께 사용해서 removelf 의 디폴트 구현을 물려받게 된다면 모든 메서드 호출을 알아서 동기화해주지 못한다.
인터페이스에서 디폴트 메서드로 정의된 removelf은 동기화에 관해 아무것도 모르기 때문에 락 객체를 사용할 수 없다.
=> SynchronizedCollection 인스턴스를 여러 스레드가 공유하는 환경에서 한 스레드가 removelf를 호출하면 ConcurrentModificationException이 발생하거나 다른 예기치 못한 결과로 이어질 수 있다.
자바 플랫폼 라이브러리에서는 이런 문제를 예방하기 위해 구현한 인터페이스의 디폴트 메서드를 재정의하고, 다른 메서드에서는 디폴트 메서드를 호출하기 전에 필요한 작업을 수행하도록 했다. 예컨대 Collections.SynchronizedCollection이 반환하는 package-private 클래스들은 removelf 를 재정의하고, 이를 호출하는 다른 메서드들은 디폴트 구현을 호출하기 전에 동기화를 하도록 했다.
(하지만 자바 플랫폼에 속하지 않은 컬렉션 구현체들은 이를 따라가지 못함)
따라서 디폴트 메서드는 컴파일에 성공하더라도 기존 구현체에 런타임 오류를 일으킬 수 있다는 점을 알아야 한다.
자바 8은 컬렉션 인터페이스에 꽤 많은 디폴트 메서드를 추가했고, 그 결과 기존에 짜여진 많은 자바 코드가 영향을 받을 수 있다. 마찬가지로, 기존 인터페이스에 디폴트 메서드로 새 메서드를 추가하는 일은 꼭 필요한 경우가 아니면 피해야 한다.
하지만 새로운 인터페이스를 만드는 경우라면 디폴트 메서드 구현을 하면 편리하다.(아이템 20)
(단, 디폴트 메서드는 인터페이스로부터 메서드를 제거하거나 기존 메서드의 시그니처를 수정하는 용도가 아니다. 일반적으로 라이브러리 개발자들이 라이브러리를 바꿔도 호환성을 유지하기 위해 사용한다. 용도를 잘 생각하자)
새로운 인터페이스라면 릴리스 전에 서로 다른 방식으로 최소한 세 가지는 구현하여 테스트 하자.
또한 각 인터페이스의 인스턴스를 다양한 작업에 활용하는 클라이언트도 여러 개 만들어 테스트 하자.
아래는 `모던 자바 인 액션` 13장 디폴트 메서드의 활용 패턴 2가지를 정리해 보았다.
첫번째는 선택형 메서드 패턴이다. 자바 8 이전, 디폴트 메서드가 없었을 때에는 인터페이스를 구현하는 클래스에서 오버라이드 한 추상 메서드의 내용이 비어있는 상황을 볼 수 있었다. 그런데, 디폴트 메서드는 기본 구현을 제공할 수 있기 때문에 인터페이스를 구현하는 클래스에서 빈 구현을 제공할 필요가 없어진다. => 불필요한 코드를 줄일 수 있다.
public interface Iterator<E> {
...
default void remove() {
throw new UnsupportedOperationException("remove");
}
}
두번째는 동작 다중 상속 패턴이다. 디폴트 메서드를 이용하면 기존에는 불가능했던 동작 다중 상속 기능도 구현할 수 있다.
다중 상속을 받을 때, 다른 클래스나 인터페이스로부터 같은 시그니처를 갖는 메서드를 상속 받을 때 알아야 할 세가지 규칙은 아래와 같다.
클래스가 항상 우선권 => 클래스나 부모 클래스에서 정의한 메서드 > 디폴트 메서드
그 다음으로는 서브 인터페이스가 우선권 => B가 A를 상속받는다면 B가 A보다 우선권
그 다음으로는 여러 인터페이스를 상속받는 클래스가 명시적으로 디폴트 메서드를 오버라이드 하고 호출해야 함. => 아이템 20에서 봤던 것 처럼 명시적으로!
Functional Interface: 함수형 인터페이스는 하나의 추상 메소드(Single abstract method, 단일 추상 메소드)로 이루어진 인터페이스인데, 여기서 함수의 시그니쳐가 정의되어 있기 때문에 컴파일러가 이 정보를 참고해서 람다에서 생략된 정보들을 추론할 수 있게 된다
함수형 인터페이스는 컴파일러가 미리 체크할 수 있도록 `@FunctionalInterface` 어노테이션으로 표시해줄 수 있다. 이 어노테이션은 Runnable 이나 Callable, Comparator 등의 함수형 인터페이스에 붙어있다. => 이때, 인터페이스 내에 딱 하나의 추상메소드가 있는게 아니라면 컴파일 에러를 뱉는다.
java.lang.Runnable
아래 내용은 `모던 자바 인 액션`에서 관련된 내용을 간단히 정리한 것이다.
Stream: 한 번에 한 개씩 만들어지는 연속적인 데이터 항목들의 모임 => 병렬처리를 위해 등장
Default Method: 구현클래스에서 구현하지 않아도 되는 메서드를 인터페이스에 추가할 수 있는 기능 => 인터페이스를 쉽게 바꿀 수 있도록 도와줌
Lambda: 메서드로 전달할 수 있는 익명 함수를 단순화 한 것 => 간결한 방식으로 코드 전달
함수형 인터페이스: 위 java.util.Collection의 removeIf에서 Predicate<T> 인터페이스로 필터 메서드를 파라미터화 할 수 있었다. 이 Predicate<T>가 함수형 인터페이스이다.
java.util.function.Predicate<T>
위에서 알아봤듯이 함수형 인터페이스는 정확히 하나의 추상 메서드를 지정하는 인터페이스이다. Predicate 인터페이스를 보면 알 수 있듯이, 함수형 인터페이스에서도 디폴트 메서드를 포함할 수 있다. 즉, 디폴트 메서드가 있더라도 추상 메서드가 오직 하나이면 함수형 인터페이스이다.
함수형 인터페이스로는 어떤 일을 할 수 있을까?
람다 표현식으로 함수형 인터페이스의 추상 메서드 구현을 직접 전달할 수 있으므로 전체 표현식을 함수형 인터페이스의 인스턴스로 취급할 수 있다. (함수형 인터페이스보다는 덜 깔끔하지만 익명 내부 클래스로도 같은 기능 구현 가능)
함수형 인터페이스의 추상 메서드 시그니처는 람다 표현식의 시그니처를 가리키는데, 람다 표현식의 시그니처를 서술하는 메서드를 함수 디스크립터라고 한다. 예를 들어 위 Runnable 함수형 인터페이스에서 유일한 추상 메서드 run은 인수와 반환값이 없기 때문에 Runnable 인터페이스는 인수와 반환값이 없는 시그니처로 생각할 수 있다.
아래는 사용 사례와 람다 예제, 그리고 대응하는 함수형 인터페이스를 정리한 것이다.
사용 사례
람다 예제
대응하는 함수형 인터페이스
boolean 표현
(List<String> list) -> list.isEmpty()
Predicate<List<String>>
객체 생성
() -> new Apple(10)
Supplier<Apple>
객체에서 소비
(Apple a) -> System.out.println(a.getWeight)
Consumer<Apple>
객체에서 선택/추출
(String s) -> s.length()
Function<String, Integer> 또는 ToIntFunction<String>
두 값 조합
(int a, int b) -> a*b
IntBinaryOperator
두 객체 비교
(Apple a1, Apple a2) -> a1.getWeight().compareTo(a2.getWeight())
Comparator<Apple> 또는 BiFunction<Apple, Apple, Integer> 또는 ToIntBiFunction<Apple, Apple>
하나 주의할 점은, 함수형 인터페이스는 checked Exception을 던지는 동작을 허용하지 않는다.
즉, 예외를 던지는 람다 표현식을 만들려면 checked Exception을 선언하는 함수형 인터페이스를 직접 정의하거나 람다를 try-catch 블록으로 감싸야 한다.
import java.io.BufferedReader;
import java.io.IOException;
@FunctionalInterface
public interface BufferedReaderProcessor {
String process(BufferedReader b) throws IOException;
}
위 함수형 인터페이스로 정의하거나, Function을 쓰고 싶다면 아래처럼 try-catch로 감싼다
자바 컴파일러는 람다 표현식이 사용된 context(대상 형식)을 이용해서 람다 표현식과 관련된 함수형 인터페이스를 추론할 수 있다.
= 대상 형식을 이용해서 함수 디스크립터를 알 수 있다
= 컴파일러는 람다의 시그니처를 추론할 수 있다. (람다 문법에서 생략 가능)
클래스가 인터페이스를 구현하게 되면, 인터페이스는 클래스가 자신의 인스턴스로 무엇을 할 수 있는지를 클라이언트에 알리는 역할을 한다.
아래와 같은 java.io.ObjectStreamConstants 와 같이 메서드 없이 static final(상수) 필드로만 이루어져있는 인터페이스는 올바르지 않다.
클래스 내부에서 사용하는 상수는 외부 인터페이스가 아니라 내부 구현에 해당하는데, 인터페이스의 경우 API로 노출하기 때문
인터페이스로 구현할 경우 클라이언트 코드가 내부 구현에 해당하는 상수들에 종속될 수 있다. => 즉, 다음 릴리스에서 상수들을 더는 쓰지 않게 되더라도 바이너리 호환성을 위해 여전히 상수 인터페이스를 구현하고 있어야 한다.
final이 아닌 클래스가 상수 인터페이스를 구현한다면 모든 하위 클래스의 이름 공간이 그 인터페이스가 정의한 상수 들로 오염되어 버린다.
자바에서의 namespace는 익숙하지 않은 단어이지만, 모든 것을 고유하게 식별하는 이름이라고 생각하면 된다. Java 클래스의 패키지 이름은 클래스의 네임 스페이스 역할을하며 JVM에서 클래스를 고유하게 식별하는 데 도움이 된다.
상수 인터페이스를 Implement 한 클래스에 같은 상수를 가질 경우, 클래스에서 새롭게 정의한 상수가 사용된다.
public interface ConstantInterface {
public static final int CONSTANT_VALUE = 10;
public static final String CONSTANT_STRING = "";
}
public class ContaminateConstant implements ConstantInterface {
public static final int CONSTANT_VALUE = 100;
public static final String CONSTANT_STRING = "contaminated";
}
import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
public class ConstantInterfaceContaminationTest {
@Test
@DisplayName("final이 아닌 클래스가 상수 인터페이스를 구현한다면 모든 하위 클래스의 `이름 공간`이 그 인터페이스가 정의한 상수 들로 오염되어 버린다.")
void testContamination() {
ContaminateConstant contaminateConstant = new ContaminateConstant();
/*
* 상수 인터페이스를 Implement 한 클래스에 같은 상수를 가질 경우,
* 클래스에 정의한 상수가 사용되므로 사용자가 의도한 흐름으로 프로그램이 돌아가지 않을 수 있다.
*/
Assertions.assertAll(
() -> Assertions.assertNotEquals(ConstantInterface.CONSTANT_STRING, ContaminateConstant.CONSTANT_STRING),
() -> Assertions.assertNotEquals(ConstantInterface.CONSTANT_VALUE, ContaminateConstant.CONSTANT_VALUE)
);
System.out.println(ConstantInterface.CONSTANT_STRING + " " + ContaminateConstant.CONSTANT_STRING);
System.out.println(ConstantInterface.CONSTANT_VALUE + " " + ContaminateConstant.CONSTANT_VALUE);
}
}
상수를 공개할 목적이라면 특정 클래스나 인터 페이스와 강하게 연관된 상수일 때, 그 클래스나 인터 페이스 자체에 추가해야 한다.
열거 타입으로 나타내기 적합한 상수라면 열거 타입으로 만들어 공개하면 된다(아이템 34).
그것도 아니라면, 인스턴스화할 수 없는 유틸리티 클래스(아이템 4)에 담아 공개하도록 한다. <- 이 때 인스턴스화 할 수 없도록 Private 생성자를 만들어 두는 것을 잊지 말자!!!
요번 아이템을 보면서 static final 에 대해 조금 헷갈렸는데, `static final` 자체는 상수라는 의미가 아니다.
static: 메모리 할당을 컴파일 타임에 하는 것 & `해당 클래스`에서 이 이름을 가진 변수가 오직 하나
final: 단 한번만 값이 할당되는 것 (+ 메소드 레벨에서 오버라이딩을 불가능하게 함)
자바 8부터 인터페이스도 디폴트 메서드(default method)를 제공하기 때문에 두 메커니즘 모두 인스턴스 메서드를 구현 형태 로 제공할 수 있게 되었다. 그래서 엄청 헷갈림...ㅠㅠ
둘의 가장 큰 차이는 추상 클래스가 정의한 타입을 구현하는 클래스는 반드시 추상 클래스의 하위 클래스가 되어야 한다는 점이다.
반면 인터페이스가 선언한 메서드를 모두 정의하고 그 일반 규약을 잘 지킨 클래스라면 다른 어떤 클래스를 상속했든 같은 타입으로 취급됨.
인터페이스는 믹스인(mixin) 정의에 안성맞춤이다. 믹스인이란 클래스가 구현할 수 있는 타입으로,
믹스인을 구현한 클래스에 원래의 `주된 타입` 외에 도 특정 선택적 행위를 제공한다고 선언하는 효과를 준다.
예를 들어 Comparable 은 자신을 구현한 클래스의 인스턴스들끼리는 순서를 정할 수 있다고 선언하는 믹스인 인터페이스로,
대상타입의 주된 기능에 선택적 기능을 ‘혼합 (mixed-in)’한다고 해서 믹스인이라 부른다.
추상 클래스로는 믹스인을 정의할 수 없다. 이유는 앞서와 같이, 기존 클래스에 덧씌울 수 없기 때문이다.
클래스 는 두 부모를 섬길 수 없고, 클래스 계층구조에는 믹스인을 삽입하기에 합리적인 위치가 없다.
래퍼 클래스 관용구(아이템 18)와 함께 사용하면 인터페이스는 기능을 향상 시키는 안전하고 강력한 수단이 된다. 인터페이스의 메서드 중 구현 방법이 명백한 것이 있다면, 그 구현을 아래와 같이 디폴트 메서드로 제공하도록 하자.
단, 디폴트 메서드를 제공할 때는 상속하려는 사람을 위한 설명을 @implSpec 자바독 태그를 붙여 문서화 해야 한다(아이템 19)
java.util.Collection
디폴트 메서드에도 제약은 있다. 인터페이스는 Object 클래스의 equals나 hashCode 등을 디폴트 메서드로 제공하면 안된다.
=> 따라서 굳이 제공하고 싶다면 abstract 클래스에서 override 해주면서 구현해야 한다.
또한, 아래처럼 여러 인터페이스가 같은 이름을 가진 디폴트 메서드라면 바로 사용할 수 없다. (구현체에서 오버라이드 할 경우는 가능)
한편, 인터페이스와 추상 골격 구현(skeletal implementation) 클래스를 함께 제공하는 식으로 인터페이스와 추상 클래스의 장점을 모두 취하는 방법도 있다. 인터페이스로는 타입을 정의하고, 필요하면 디폴트 메서드 몇 개도 함께 제공하도록 하고, 골격 구현 클래스는 나머지 메서드들까지 구현한다. 이렇게 해두면 단순히 골격 구현을 확장하는 것만으로 이 인터페이스를 구현하는 데 필요한 일이 대부분 완료된다.
=> 템플릿 메서드 패턴
(이전에 왜 HashSet의 경우 AbstractSet 추상클래스를 상속하고 있는데, Set 인터페이스또한 implement하고 있는지에 대한 의문이 들었던 적이 있었고, 이에 대해 살짝 알아본 적이 있었다.)
예시를 통해 보자. 아래 코드는 완벽히 동작하는 List 구현체를 반환하는 정적 팩터리 메서드로, AbstractList 골격 구현으로 활용했다.
static List<Integer> intArrayAsList(int[] a) {
Objects.requireNonNull(a);
return new AbstractList<>() {
@Override
public Integer get(int i) {
return a[i]; // 오토박싱(아이템 6)
}
@Override
public Integer set(int i, Integer val) {
int oldVal = a[i];
a[i] = val;// 오토언박싱
return oldVal; // 오토박싱
}
@Override
public int size() {
return a.length;
}
};
}
이 예시는 int 배열을 받아 Integer 인스턴스의 리스트 형태로 보여주는 어댑터 패턴이기도 하다. int 값과 Integer 인스턴스 사이의 박싱과 언박싱 때문에 성능은 그리 좋지 않으며, 익명 클래스(아이템 24) 형태를 사용했음
골격 구현 클래스를 우회적으로 이용할 수도 있는 방법도 있다.
인터페이스를 구현한 클래스에서 해당 골격 구현을 확장한 private 내부 클래스를 정의하고, 각 메서드 호출을 내부 클래스의 인스턴스에 전달하는 방법을 사용하면 된다. 아이템 18에서 다룬 래퍼 클래스와 비슷한 이 방식을 시뮬레이트한 다중 상속(simulated multiple inheritance)이라 하며, 다중 상속의 많은 장점을 제공하는 동시에 단점은 피하게 해준다. 예시는 아래와 같다.
public interface Food {
}
public class Pizza implements Food{
}
public class Truck {
public void driveTo(String destination) {
System.out.println("drive to " + destination);
}
}
아래와 같이 Kitchen 인터페이스로 함수를 정의해 두고 AbstractKitchen으로 공통적으로 turnLightOn/Off 골격 함수를 정의한다.
public interface Kitchen {
void cook(Food food);
void turnLightOn();
void turnLightOff();
}
public abstract class AbstractKitchen implements Kitchen {
@Override
public void turnLightOn() {
System.out.println("light on");
}
@Override
public void turnLightOff() {
System.out.println("light off");
}
}
public class PizzaTruck extends Truck implements Kitchen {
private final InnerAbstractKitchen innerAbstractKitchen = new InnerAbstractKitchen();
@Override
public void cook(Food food) {
innerAbstractKitchen.cook(food);
}
@Override
public void turnLightOn() {
innerAbstractKitchen.turnLightOn();
}
@Override
public void turnLightOff() {
innerAbstractKitchen.turnLightOff();
}
private static class InnerAbstractKitchen extends AbstractKitchen {
@Override
public void cook(Food food) {
System.out.println("cook " + food.getClass().getSimpleName());
}
}
}
public interface Animal {
default String jump() {
return "jump";
}
}
public class Cat implements Animal {
@Override
public String jump() {
return "cat is jumping";
}
}
public class Dog implements Animal {
}
상속을 고려한 설계와 문서화 = public/protected 메소드 중 final 이 아닌 것
=> 메서드를 재정의하면 어떤 일이 일어나는지(내부적으로 어떻게 사용하고 있는지)를 정리하여 문서화 하자
java.util.AbstractCollection
위 API 문서의 Implementation Requirement 는 메서드의 내부 동작 방식을 설명하는 곳이다. 메서드 주석에 @implSpec 태그를 붙여주면 자바독 도구가 생성해준다.
주어진 원소가 이 컬렉션 안에 있다면 그 인스턴스를 하나 제거한다 => 선택적 동작. 더 정확 하게 말하면, 이 컬렉션 안에 ‘Object.equals(o, e)가 참인 원소’ e가 하나 이상 있다면 그 중 하나를 제거한다. 주어진 원소가 컬렉션 안에 있었다면(즉, 호출 결과 이 컬렉션이 변경 됐다면) true를 반환한다.
Implementation Requirements: 이 메서드는 컬렉션을 순회하며 주어진 원소를 찾도록 구현되었다. 주어진 원소를 찾으면 반복자의 remove 메서드를 사용해 컬렉션에서 제거 한다. 이 컬렉션이 주어진 객체를 갖고 있으나, 이 컬렉션의 iterator 메서드가 반환한 반복자가 remove 메서드를 구현하지 않았다면 UnsupportedOperationException 을 던지니 주의하자.
이 설명에 따르면 iterator 메서드를 재정의하면 remove 메서드의 동작에 영향을 주며, iterator 메서드로 얻은 반복자의 동작이 remove 메서드의 동작에 주는 영향도 설명하고 있다.
자바 11의 자바독에서 이 태그를 활성화하려면 명령줄 매개변수로 -tag "implSpec:a:Implementation Requirements:"를 지정 해줘야 한다.
내부 메커니즘을 문서로 남기는 것뿐만 아니라,
효율적인 하위 클래스를 큰 어려움 없이 만들 수 있게 하려면 클래스의 내부 동작 과정 중간에 끼어들 수 있는 훅(hook)을 잘 선별하여 protected 메서드 형태나 드물게는 protected 필드로 공개해야 할수도 있다.
java.util.AbstractList
fromlndex(이상)부터 tolndex(미만)까지의 모든 원소를 이 리스트에서 제거한다. tolndex 이후의 원소들은 앞으로 index만큼씩 당겨진다. 이 호출로 리스트는 `tolndex - fromlndex`만큼 짧아진다.
이 리스트/부분리스트에 정의된 clear 연산이 이 메서드를 호출하는데, 리스트 구현의 내부 구조를 활용하도록 이 메서드를 재정의하면 이 리스트와 부분리스트의 clear 연산 성능을 크게 개선할 수 있다.
Implementation Requirements: 이 메서드는 fromlndex에서 시작하는 리스트 반복 자를 얻어 모든 원소를 제거할 때까지 ListIterator.next와 ListIterator.remove를 반복 호출하도록 구현되었다.
주의: ListIterator.remove가 선형 시간이 걸리면 이 구현의 성능은 제곱에 비례한다.
removeRange 메서드가 사용되지 않지만 제공된 이유는 하위 클래스에서 부분 리스트의 clear 메서드를 고성능으로 만들기 위해서이다. removeRange 메서드가 없을 때 하위 클래스에서 clear 메서드를 호출하면 제거할 원소 수의 제곱에 비례해 성능이 느려지거나, 부분리스트의 메커니즘을 밑바닥부터 새로 구현해야 했을 것이다.
언제 메서드를 protected로 둘지 일정하진 않다. 상속용 클래스를 시험하는 방법은 직접 하위 클래스를 만들어보는 것이 유일하다.(약 3개)
상속을 허용하는 클래스의 경우 생성자는 직접적으로든 간접적으로든 재정의 가능 메서드를 호출해서는 안 된다. 왜냐하면 상위 클래스의 생성자가 하위 클래스의 생성자보다 먼저 실행되므로 하위 클래스에서 재정의 한 메서드가 하위 클래스의 생성자보다 먼저 호출된다. 이때 그 재정의한 메서드가 하위 클래스의 생성자에서 초기화하는 값에 의존한다면 의도대로 동작하지 않을 것이다.
아래 예를 살펴보자.
package com.example.sypark9646.item19;
public class Parent {
public Parent() {
System.out.println("parent 생성자");
overrideMe();
}
public void overrideMe() {
System.out.println("parent");
}
}
package com.example.sypark9646.item19;
import java.time.Instant;
public class Child extends Parent {
private final Instant instant;
public Child() {
System.out.println("child 생성자");
this.instant = Instant.now();
}
@Override
public void overrideMe() {
System.out.println("child");
System.out.println(instant);
}
}
package com.example.sypark9646.item19;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
public class OverrideTimeTest {
@DisplayName("상속용 클래스의 생성자의 재정의 가능 메소드 호출 테스트")
@Test
void overrideTest() {
Child child = new Child();
child.overrideMe();
}
}
위 테스트에서 볼 수 있듯이, parent 생성자를 호출하면서 overrideMe 호출 -> 이때, Child 생성자를 만드는 것이 목표였기 때문에(?) child의 overrideMe를 호출하는데, 아직 Child가 초기화 되기 전이므로 instant = null이 찍힌다는 것을 확인할 수 있다.
Parent 생성자 안에서 부르는 overrideMe가 parent override를 프린트 할 줄 알았지만,,, 아니었다
즉, 여기서는 final 필드의 상태가 두 가지이다!! (정상이라면 단 하나)
overrideMe에서 instant 객체의 메서드를 호출하려 한다면 상위 클래스의 생성자가 overrideMe 를 호출할 때 NullPointerException을 던지게 된다.
Cloneable과 Serializable 인터페이스 중 하나라도 구현한 클래스를 상속할 수 있게 설계하는 것은 일반적으로 좋지 않은 생각이다.
굳이 하고싶다면, clone과 readObject 메서드는 생성자와 비슷한 효과를 내므로(새로운 객체 생성) 재정의 가능 메서드를 호출하면 안된다.
readObject의 경우 하위 클래스의 상태가 미처 다 역직렬화되기 전에 재정의 한 메서드부터 호출하게 되며,
clone의 경우 하위 클래스의 clone 메서드가 복제본의 상태를 올바른 상태로 수정하기 전에 재정의한 메서드를 호출한다.
(특히 clone이 잘못되면 복제본뿐 아니라 원본 객체에도 피해를 줄 수 있다)
마지막으로, Serializable을 구현한 상속용 클래스가 readResolve나 writeReplace 메서드를 갖는다면 이 메서드들은 protected로 선언해 야 한다. private으로 선언한다면 하위 클래스에서 무시되기 때문이다. 이 역시 상속을 허용하기 위해 내부 구현을 클래스 API로 공개하는 예 중 하나다.
상속을 쓰는 경우는 추상 클래스나 인터페이스의 골격 구현(아이템 20)할 때가 있고, 불변 클래스(아이템 17) 등에는 절대 사용하지 않도록 하자. 일반적인 구체 클래스일 때에는 상속용으로 설계하지 않았을 경우 상속을 금지하도록 하는 것이 좋다.
상속을 금지하는 방법은 두 가지가 있는데, 가장 쉬운 방법은 클래스를 final로 선언하는 방법이다.
두 번째는 모든 생성자를 private이나 package-private으로 선언하고 public 정적 팩터리를 만들어주는 방법이다.
결론적으로 상속은 매우 복잡하다.. 상속 대신 사용할 수 있는 방법은 인터페이스가 될 수 있고, 래퍼 클래스 패턴(아이템18) 도 가능하다. 그렇지만 만약 구체 클래스가 표준 인터페이스를 구현하지 않았는데 상속을 금지하면 사용 하기에 상당히 불편해진다. 이런 클래스라도 상속을 꼭 허용해야겠다면 클래스 내부에서 재정의 가능 메서드를 사용하지 않게 만들고, 이 사실을 문서로 남기도록 하자.
클래스의 동작을 유지하면서 재정의 가능 메서드를 사용하는 코드를 제거할 수 있는 기계적인 방법은 아래와 같다.
먼저 각각의 재정의 가능 메서드는 자신의 본문 코드를 private `도우미 메서드`로 옮기고, 이 도우미 메서드를 호출하도록 수정한다.
그런 다음 재정의 가능 메서드를 호출하는 다른 코드들도 모두 이 도우미 메서드를 직접 호출하도록 수정하면 된다.
package com.example.sypark9646.item19;
public class Parent {
public Parent() {
System.out.println("parent 생성자");
helpOverride();
}
public void overrideMe() {
helpOverride();
}
private void helpOverride(){
System.out.println("parent override");
}
}
package com.example.sypark9646.item19;
import java.time.Instant;
public class Child extends Parent {
private final Instant instant;
public Child() {
System.out.println("child 생성자");
this.instant = Instant.now();
}
@Override
public void overrideMe() {
helpOverride();
}
private void helpOverride(){
System.out.println("child override");
System.out.println(instant);
}
}
실행 결과를 보면, parent의 overrideMe(helpOverride)를 호출함으로써 instant = null 값이 출력되는 일이 발생하지 않았고,
이러한 결과가 나온 이유는, 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();
}
}
컴포지션과 전달의 조합은 넓은 의미로 위임(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();
}
}
불변 클래스는 가변 클래스보다 설계 및 구현이 쉬우며, 오류가 생길 여지도 적고 훨씬 안전하다.
클래스를 불변으로 만들기 위해서는 아래 규칙을 따라야 한다.
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)
요 내용과 비슷한 것이 일급 컬렉션이라는 것이다. 이번 과제는 일급 컬렉션을 아래 조건에 맞게 구현하는 것이었다.
규칙 8: 일급 콜렉션 사용 이 규칙의 적용은 간단하다. 콜렉션을 포함한 클래스는 반드시 다른 멤버 변수가 없어야 한다. 각 콜렉션은 그 자체로 포장돼 있으므로 이제 콜렉션과 관련된 동작은 근거지가 마련된셈이다. 필터가 이 새 클래스의 일부가 됨을 알 수 있다.
필터는 또한 스스로 함수 객체가 될 수 있다. 또한 새 클래스는 두 그룹을 같이 묶는다든가 그룹의 각 원소에 규칙을 적용하는 등의 동작을 처리할 수 있다. 이는 인스턴스 변수에 대한 규칙의 확실한 확장이지만 그 자체를 위해서도 중요하다. 콜렉션은 실로 매우 유용한 원시 타입이다. 많은 동작이 있지만 후임 프로그래머나 유지보수 담당자에 의미적 의도나 단초는 거의 없다. - 소트웍스 앤솔로지 객체지향 생활체조편
출처: https://jojoldu.tistory.com/412
쉽게 말하면, 컬렉션을 가지고 있는 클래스를 하나 만들어서 클래스가 멤버 변수를 verify 하도록 하고, 컬렉션은 외부에서 바꿀 수 없도록 하자는 것이다. => 위에서 봤듯이, 컬렉션은 외부에서 참조가능 할 경우 final을 붙여도 안에 들어있는 값들이 변경될 수 있으니까
먼저 학교의 경우 enum으로 관리할 수 있도록 했다. (학과도 만들면 좋긴 했지만... 너무 귀찮았음)
좀 더 재밌는 요소를 부여해 보고 싶어서 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();
}
}
잘 설계된 컴포넌트는 모든 내부 구현을 완벽히 숨겨, 구현과 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이다)
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) 으로 설정하는 것이
결국 로직상으로는 동일한데, 왜 다들 안된다고 하는 것인지.. 궁금해져서 조금 알아 보았다.
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;
}
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.equalsBigDecimal.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(); // 오버플로우 발생 가능
}
}；
