아이템[44]. 표준 함수형 인터페이스를 사용하라

자바가 람다를 지원하면서 API를 작성하는 모범 사례도 크게 바뀌었습니다.

예컨대 상위 클래스의 기본 메서드를 재정의해 원하는 동작을 구현하는 템플릿 메서드 패턴의 매력이 크게 줄었습니다.

이를 대체하는 현대적인 해법은 같은 효과의 함수 객체를 받는 정적 팩터리나 생성자를 제공하는 것입니다.

이 내용을 일반화해서 말하면 함수 객체를 매개변수로 받는 생성자와 메서드를 더 많이 만들어야 합니다.

이 때 함수형 매개변수 타입을 올바르게 선택해야 합니다.

LinkedHashMap을 생각해봅시다.

이 클래스의 protected 메서드인 removeEldestEntry를 재정의하면 캐시로 사용할 수 있습니다.

맵에 새로운 키를 추가하는 put 메서드는 이 메서드를 호출하여 true가 반환되면 맵에서 가장 오래된 원소를 제거합니다.

예컨대 removeEldestEntry를 다음처럼 재정의하면 맵에 원소가 100개가 될 때까지 커지다가, 그 이상이 되면 새로운 키가 더해질 때마다 가장 오래된 원소를 하나씩 제거합니다.

즉, 가장 최근 원소 100개를 유지합니다.

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

잘 동작하지만 람다를 사용하면 훨씬 잘 해낼 수 있습니다.

LinkedHashMap을 오늘날 다시 구현한다면 함수 객체를 받는 정적 팩터리나 생성자를 제공했을 것입니다.

removeEldestEntry 선언을 보면 이 함수 객체는 Map.Entry<K,V>를 받아 boolean을 반환해야 할 것 같지만, 꼭 그렇지만은 않습니다.

removeEldestEntry는 size()를 호출해 맵 안의 원소 수를 알아내는데, removeEldestEntry가 인스턴스 메서드라서 가능한 방식입니다.

하지만 생성자에 넘기는 함수 객체는 이 맵의 인스턴스 메서드가 아닙니다.

팩터리나 생성자를 호출할 때에는 맵의 인스턴스가 존재하지 않기 때문입니다.

따라서 맵은 자기 자신도 함수 객체에 건네줘야 합니다.

이를 반영한 함수형 인터페이스는 다음처럼 선언할 수 있습니다.

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

이 인터페이스도 잘 동작하기는 하지만, 굳이 사용할 이유는 없습니다.

자바 표준 라이브러리에 이미 같은 모양의 인터페이스가 준비되어 있기 때문입니다.

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

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

그러면 API가 다루는 개념의 수가 줄어들어 익히기 더 쉬워집니다.

또한 표준 함수형 인터페이스들은 유용한 디폴트 메서드를 많이 제공하므로 다른 코드와의 상호운용성도 크게 좋아질 것입니다.

예컨대 Predicate 인터페이스는 프레디키트들을 조합하는 메서드를 제공합니다.

앞의 LinkedHashMap 예에서는 직접 만든 EldestEntryRemovalFunction 대신 표준 인터페이스인 BiPredicate<Map<K,V>, Map.Entry<K,V>를 사용할 수 있습니다.

java.util.function 패키지에는 총 43개의 인터페이스가 담겨 있습니다.

전부 기억하긴 어렵겠지만, 기본 인터페이스 6개만 기억하면 나머지를 충분히 유추해낼 수 있습니다.

이 기본 인터페이스들은 모두 참조 타입용입니다.

기본 인터페이스

[1]. Operator 인터페이스

Operator 인터페이스는 인수가 1개인 UnaryOperator와 2개인 BinaryOperator로 나뉘며, 반환값과 인수의 타입이 같은 함수를 뜻합니다.

[2]. Predicate 인터페이스

Predicate 인터페이스는 인수 하나를 받아 boolean을 반환하는 함수를 뜻합니다.

[3]. Function 인터페이스

Function 인터페이스는 인수와 반환 타입이 다른 함수를 뜻합니다.

[4]. Supplier 인터페이스

Supplier 인터페이스는 인수를 받지 않고 값을 반환(혹은 제공)하는 함수를 뜻합니다.

[5]. Consumer 인터페이스

Consumer 인터페이스는 인수를 하나 받고 반환값은 없는(특히 인수를 소비하는) 함수를 뜻합니다.

기본 인터페이스는 기본 타입인 int, long, double용으로 각 3개씩 변형이 생겨납니다.

그 이름도 기본 인터페이스의 이름 앞에 해당 기본 타입 이름을 붙여 지었습니다.

예를 들어, int를 받는 Predicate는 IntPredicate가 되고 long을 반환하는 BinaryOperator는 LongBinaryOperator가 됩니다.

이 변형들 중 유일하게 Function의 변형만 매개변수화됐습니다.

정확히는 반환 타입만 매개변수화됐는데, 예를 들어 LongFunction<int[]>은 long 인수를 받아 int[]을 반환합니다.

Function 인터페이스

Function 인터페이스는 기본 타입을 반환하는 변형이 총 9개가 더 있습니다.

인수와 같은 타입을 반환하는 함수는 UnaryOperator이므로, Function 인터페이스의 변형은 입력과 결과의 타입이 항상 다릅니다.

입력과 결과 타입이 모두 기본 타입이면 접두어로 SrcToResult를 사용합니다.

예컨대 long을 받아 int를 반환하면 LongToIntFunction이 되는 식입니다.

나머지는 입력이 객체 참조이고 결과가 int, long, double인 변형들로, 앞서와 달리 입력을 매개변수화하고 접두어로 ToResult를 사용합니다.

즉, ToLongFunction<int[]>은 int[] 인수를 받아 long을 반환합니다.

 

기본 함수형 인터페이스 중 3개에는 인수를 2개씩 받는 변형이 있습니다.

BiPredicate<T, U>, BiFunction<T, U, R>, BiConsumer<T,U>입니다.

BiFunction에는 다시 기본 타입을 반환하는 세 변형 ToIntBiFunction<T,U>, ToLongBiFunction<T,U> 그리고 ToDoubleBiFunction<T,U>가 존재합니다.

Consumer에도 객체 참조와 기본 타입 하나, 즉 인수를 2개 받는 변형인 ObjDoubleConsumer<T> 그리고 ObjIntConsumer<T>, ObjLongConsumer<T>가 존재합니다.

이렇게 해서 기본 인터페이스의 인수 2개짜리 변형은 총 9개입니다.

마지막으로, BooleanSupplier 인터페이스는 boolean을 반환하도록 한 Supplier의 변형입니다.

이것이 표준 함수형 인터페이스 중 boolean을 이름에 명시한 유일한 인터페이스지만, Predicate와 그 변형 4개도 boolean 값을 반환할 수 있습니다.

앞서 소개한 42개의 인터페이스에 이 BooleanSuppier까지 더해서 표준 함수형 인터페이스는 43개입니다.

솔직히 다 외우기엔 수도 많고 규칙성도 부족합니다.

하지만 실무에서 자주 쓰이는 함수형 인터페이스 중 상당수를 제공하며, 필요할 때 찾아 쓸 수 있을 만큼은 범용적인 이름을 사용했습니다.

표준 함수형 인터페이스 대부분은 기본 타입만 지원합니다.

그렇다고 기본 함수형 인터페이스에 박싱된 기본 타입을 넣어 사용하지는 맙시다.

동작은 하지만 "박싱된 기본 타입 대신 기본 타입을 사용하라"라는 아이템 61의 조언을 위배합니다.

특히 계산량이 많을 때에는 성능이 처참히 느려질 수 있습니다.

이제 대부분 상황에서는 직접 작성하는 것보다 표준 함수형 인터페이스를 사용하는 편이 나음을 알았을 것입니다.

🤔
그렇다면 코드를 직접 작성해야 할 때는 언제일까요?

 

물론 표준 인터페이스 중 필요한 용도에 맞는 게 없다면 직접 작성해야 합니다.

예를 들어 매개변수 3개를 받는 Predicate라든가 검사 예외를 던지는 경우가 있을 수 있습니다.

그런데 구조적으로 똑같은 표준 함수형 인터페이스가 있더라도 직접 작성해야만 할 때가 있습니다.

자주 보아온 Comparator<T> 인터페이스를 떠올려봅시다.

구조적으로는 ToIntBiFunction<T,U>와 동일합니다.

심지어 자바 라이브러리에 Comparator<T>를 추가할 당시 ToIntBiFunction<T,U>가 이미 존재했더라도 ToIntBiFunction<T,U>를 사용하면 안 됐습니다.

Comparator가 독자적인 인터페이스로 살아남아야 하는 이유

Comparator가 독자적인 인터페이스로 살아남아야 하는 이유가 몇 개 있습니다.

[1]. API에서 굉장히 자주 사용되는데, 지금의 이름이 그 용도를 아주 훌륭히 설명해준다.

[2]. 구현하는 쪽에서 반드시 지켜야 할 규약을 담고 있다.

[3]. 비교자들을 변환하고 조합해주는 유용한 디폴트 메서드들을 듬뿍 담고 있다.

이 중 하나 이상을 만족한다면 전용 함수형 인터페이스를 구현해야 하는 건 아닌지 고민해야 합니다.

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

전용 함수형 인터페이스를 작성하기로 했다면, 자신이 작성하는 게 다른 것도 아닌 '인터페이스'임을 명심해야 합니다. 아주 주의해서 설계해야 한다는 뜻입니다. (아이템 21)

 

EldestEntryRemovalFunction 인터페이스에서 @FunctionalInterface 애너테이션이 달려있는걸 볼 수 있습니다.

이 애너테이션을 사용하는 이유는 @Override를 사용하는 이유와 비슷합니다.

프로그래머의 의도를 명시하는 것으로, 크게 세 가지 목적이 있습니다.

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

그러니 직접 만든 함수형 인터페이스에는 항상 @FunctionalInterface 애너테이션을 사용합시다.

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

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

클라이언트에게 불필요한 모호함만 안겨줄 뿐이며, 이 모호함으로 인해 실제로 문제가 일어나기도 합니다.

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

그래서 올바른 메서드를 알려주기 위해 형변환해야 할 때가 종종 생깁니다. (아이템 52)

이런 문제를 피하는 가장 쉬운 방법은 서로 다른 함수형 인터페이스를 같은 위치의 인수로 사용하는 다중정의를 피하는 것입니다.

이는 "다중정의는 주의해서 사용하라"는 아이템 52 조언의 특수한 예라 할 수 있습니다.

정리

• 이제 자바도 람다를 지원한다.
• 여러분도 지금부터는 API 설계할 때 람다도 염두에 두어야 한다는 뜻이다.
• 입력값과 반환값에 함수형 인터페이스 타입을 활용하라.
• 보통은 java.util.function 패키지의 표준 함수형 인터페이스를 사용하는 것이 가장 좋은 선택이다.
• 단, 흔치는 않지만 직접 새로운 함수형 인터페이스를 만들어 쓰는 편이 나을 수도 있음을 잊지 말자.