표준 함수형 인터페이스를 사용하라 - [7장. 람다와 스트림(아이템44)]

📙 1. 함수형 인터페이스

  자바가 람다를 지원하면서 상위 클래스의 기본 메서드를 재정의해 원하는 동작을 구현하는 템플릿 메서드 패턴의 매력이 크게 줄었다.

  이를 대체하는 방법으로 함수 객체를 받는 정적 팩터리나 생성자를 제공하는 방법이 있다.

  즉, 함수 객체를 매개변수로 받는 생성자와 메서드를 더 많이 사용하는 것이다.

 

  LinkedHashMap의 removeEldestEntry를 살펴보자. removeEldestEntry를 다음과 같이 재정의하면, 맵에 원소가 100개가 될 때마다 가장 오래된 원소를 하나씩 제거한다.

// 기존
public class LinkedHashMap<K,V> extends HashMap<K,V> implements Map<K,V> {
    ...
    protected boolean removeEldestEntry(Map.Entry<K,V> eldest) {
        return false;
    }
    ...
}

// 재정의
protected boolean removeEldestEntry(Map.Entry<K, V> eldest) {
    return size() > 100;
}

  이를 함수형 인터페이스로 나타내면 다음과 같다.

@FunctionalInterface
interface EldestEntryRemovalFunction<K, V> {
    boolean remove(Map<K, V> map, Map.Entry<K, V> eldest);
}

  하지만, 굳이 불필요하게 함수형 인터페이스를 만들 필요는 없다.

  표준 인터페이스인 BiPredicate<Map<K, V>, Map.Entry<K, V>>를 사용할 수 있기 때문이다.

 

 

📙 2. 표준 함수형 인터페이스

  java.util.function 패키지를 보면 다양한 용도의 표준 함수형 인터페이스가 담겨 있다.

  그러므로 표준 함수형 인터페이스에 필요한 용도에 맞는 게 있다면, 직접 구현하지 말고 표준 함수형 인터페이스를 활용하도록 하자.

 

  총 43개의 표준 함수형 인터페이스가 존재하는데, 기본 인터페이스 6개만 기억하면 나머지는 충분히 유추할 수 있다. 기본 인터페이스 6개는 다음과 같다.

1. Operator 인터페이스
   반환값과 인수의 타입이 같은 함수
   인수가 1개인 UnaryOperator와 2개인 BinaryOperator가 있다.
2. Predicate 인터페이스
   인수 하나를 받아 boolean을 반환하는 함수
3. Funtion 인터페이스
   인수와 반환 타입이 다른 함수
4. Supplier 인터페이스
   인수를 받지 않고 값을 반환(혹은 제공)하는 함수
5. Consumer 인터페이스
   인수를 하나 받고 반환값은 없는(특히 인수를 소비하는) 함수

인터페이스	함수 시그니처	예
UnaryOperator<T>	T apply(T t)	String::toLowerCase
BinaryOperator<T>	T apply(T t1, T t2)	BigInteger::add
Predicate<T>	boolean test(T t)	Collection::isEmpty
Function<T, R>	R apply(T t)	Arrays::asList
Supplier<T>	T get()	Instant::now
Consumer<T>	void accept(T t)	System.out::println

 

  표준 함수형 인터페이스는 대부분 기본 타입만 지원한다. 그렇다고 기본 함수형 인터페이스에 박싱 된 기본 타입을 넣어 사용하지는 말자. 계산량이 많을 때 성능이 매우 느려질 수 있기 때문이다.

 

📙 3. 함수형 인터페이스를 구현해야 하는 시기 및 작성법

📌 1. 함수형 인터페이스를 구현해야 하는 시기

  아래의 3가지 경우 중 하나 이상을 만족한다면 전용 함수형 인터페이스 구현을 고민해 보자.

1. 자주 쓰이며, 이름 자체가 용도를 명확히 설명해 준다.
2. 반드시 따라야 하는 규약이 있다.
3. 유용한 디폴트 메서드를 제공할 수 있다.

  이를 잘 나타내는 예시가 Comparator<T> 인터페이스다. 구조적으로 ToIntBiFunction<T, U>와 동일하다.

  하지만 아래의 내용들로 인해 독자적인 인터페이스로 살아남게 되었다.

1. API에서 굉장히 자주 사용되는데, 지금의 이름이 그 용도를 아주 훌륭히 설명한다.
2. 구현하는 쪽에서 반드시 지켜야 할 규약을 담고 있다.
3. 비교자들을 변환하고 조합해 주는 유용한 디폴트 메서드들을 담고 있다.

📌 2. 작성법

  직접 만든 함수형 인터페이스에는 항상 @FunctionalInterface 애너테이션을 달도록 하자. 이는 @Override처럼 프로그래머의 의도를 명시하는 역할을 한다.

  그 목적은 아래와 같다.

1. 해당 클래스의 코드나 설명 문서를 읽을 이에게 그 인터페이스가 람다용으로 설계된 것임을 알려준다.
2. 해당 인터페이스가 추상 메서드를 오직 하나만 가지고 있어야 컴파일되게 해준다.
3. 유지보수 과정에서 누군가 실수로 메서드를 추가하지 못하도록 해준다.

 

 

📙 4. 함수형 인터페이스를 API에서 사용할 때의 주의점

  함수형 인터페이스를 API에서 사용할 때의 주의점에 대해서 살펴보자.

  서로 다른 함수형 인터페이스를 같은 위치의 인수로 받는 메서드들을 다중 정의해서는 안 된다.

  ExecutorService의 submit 메서드는 Callable<T>를 받는 것과 Runnable을 받는 것을 다중정의했다.

public interface ExecutorService extends Executor {
    ...
    <T> Future<T> submit(Callable<T> task);
    Future<?> submit(Runnable task);
    ...
}

  그 결과, 올바른 메서드를 알려주기 위해 형변환을 해야 할 때가 매우 많이 생기게 된다.

  그러므로 서로 다른 함수형 인터페이스를 같은 위치의 인수로 사용하는 다중 정의를 하지 말도록 하자.

 

해당 글은 Joshua Bloch 님의 'Effective Java 3/E'를 참고하였습니다.