아이템[42]. 익명 클래스보다는 람다를 사용하라

예전에는 자바에서 함수 타입을 표현할 때 추상 메서드를 하나만 담은 인터페이스(드물게는 추상 클래스)를 사용했습니다.

이런 인터페이스의 인스턴스를 함수 객체라고 하여, 특정 함수나 동작을 나타내는데 썼습니다.

1997년 JDK 1.1이 등장하면서 함수 객체를 만드는 주요 수단은 익명 클래스(아이템 24)가 되었습니다.

다음 코드를 예로 살펴봅시다.

문자열을 길이순으로 정렬하는데, 정렬을 위한 비교 함수로 익명 클래스를 사용합니다.

Collections.sort(words, new Comparator<String>() {
    public int compare(String s1, String s2) {
        return Integer.compare(s1.length(), s2.length());
    }
});

전략(Strategy) 패턴처럼, 함수 객체를 사용하는 과거 객체 지향 디자인 패턴에는 익명 클래스면 충분했습니다.

이 코드에서 Comparator 인터페이스가 정렬을 담당하는 추상 전략을 뜻하며, 문자열을 정렬하는 구체적인 전략을 익명 클래스로 구현하였습니다.

하지만 익명 클래스 방식은 코드가 너무 길기 때문에 자바는 함수형 프로그래밍에 적합하지 않았습니다.

 

자바 8에 와서 추상 메서드 하나짜리 인터페이스는 특별한 의미를 인정받아 특별한 대우를 받게 되었습니다.

자바 8에 추가된 기술 [1] 함수형 인터페이스

지금은 함수형 인터페이스를 부르는 이 인터페이스들의 인스턴스를 람다식을 사용해 만들 수 있게 된 것입니다.

람다는 함수 익명 클래스와 개념은 비슷하지만 코드는 훨씬 간결합니다.

 

다음은 익명 클래스를 사용한 앞의 코드를 람다 방식으로 바꾼 모습입니다.

자질구레한 코드들이 사라지고 어떤 동작을 하는지가 명확하게 드러납니다.

Collections.sort(words, 
        (s1, s2) -> Integer.compare(s1.length(), s2.length()));

여기서 람다, 매개변수(s1, s2), 반환값의 타입은 각각 (Comparator<String>), String, int지만 코드에서는 언급이 없습니다.

우리 대신 컴파일러가 문맥을 살펴 타입을 추론해준 것입니다.

상황에 따라 컴파일러가 타입을 결정하지 못할 수도 있는데, 그럴 때에는 프로그래머가 직접 명시해야 합니다.

타입 추론 규칙은 자바 언어 명세의 챕터를 통째로 차지할 만큼 복잡합니다.

너무 복잡해서 이 규칙을 다 이해하는 프로그래머는 거의 없다고 하고, 잘 알지 못한다 해도 상관없답니다.

타입을 명시해야 코드가 더 명확할 때만 제외하고는, 람다의 모든 매개변수 타입은 생략합시다.

그런 다음 컴파일러가 "타입을 알 수 없다"는 오류를 낼 때만 해당 타입을 명시하면 됩니다.

반환값이나 람다식 전체를 형변환해야 할 때도 있겠지만, 아주 드물 것입니다.

🐻
타입 추론에 관한 한마디

 

아이템 26에서는 제네릭의 로 타입을 쓰지말라 했고, 아이템 29에서는 제네릭을 쓰라 했고, 아이템 30에서는 제네릭 메서드를 쓰라고 했습니다.

이 조언들은 람다와 함께 쓸 때에는 두 배로 중요해집니다.

컴파일러가 타입을 추론하는 데 필요한 타입 정보 대부분을 제네릭에서 얻기 때문입니다.

우리가 이 정보를 제공하지 않으면 컴파일러는 람다의 타입을 추론할 수 없게 되어, 결국 우리가 일일이 명시해야 합니다.

좋은 예로, 위 코드에서 인수 words가 매개변수화 타입인 List<String>이 아니라 로 타입인 List였다면 오류가 났을 것입니다.

 

람다 자리에 비교자 생성 메서드를 사용하면 이 코드를 더 간결하게 만들 수 있습니다.(아이템 14, 아이템 43)

Collections.sort(words, comparingInt(String::length));

더 나아가 자바 8 때 List 인터페이스에 추가된 sort 메서드를 이용하면 더욱 짧아집니다.

words.sort(comparingInt(String::length));

람다를 언어 차원에서 지원하면서 기존에는 적합하지 않았던 곳에서도 함수 객체를 실용적으로 사용할 수 있게 되었습니다.

아이템 34의 Operation 열거 타입을 예로 들어봅시다.

apply 메서드의 동작이 상수마다 달라야 해서 상수별 클래스 몸체를 사용해 각 상수에서 apply 메서드를 재정의한 것을 떠올려봅시다.

public enum Operation {
    PLUS("+")   {
        public double apply(double x, double y) { return x + y; }
    },
    MINUS("-")  {
        public double apply(double x, double y) { return x - y; }
    },
    TIMES("*")  {
        public double apply(double x, double y) { return x * y; }
    },
    DIVIDE("/") {
        public double apply(double x, double y) { return x / y; }
    };

    private final String symbol;

    Operation(String symbol) { this.symbol = symbol; }

    @Override public String toString() { return symbol; }
    public abstract double apply(double x, double y);
}

아이템 34에서는 상수별 클래스 몸체를 구현하는 방식보다는 열거 타입에 인스턴스 필드를 두는 편이 낫다고 했습니다.

람다를 이용하면 후자의 방식, 즉 열거 타입의 인스턴스 필드를 이용하는 방식으로 상수별로 다르게 동작하는 코드를 쉽게 구현할 수 있습니다.

단순히 각 열거 타입 상수의 동작을 람다로 구현해 생성자에 넘기고, 생성자는 이 람다를 인스턴스 필드로 저장해둡니다.

그런 다음 apply 메서드에서 필드에 저장된 람다를 호출하기만 하면 됩니다.

이렇게 구현하면 원래 버전보다 간결하고 깔끔해집니다.

public enum Operation {
    PLUS("+", (x, y) -> x + y),
    MINUS("-", (x, y) -> x - y),
    TIMES("*", (x, y) -> x * y),
    DIVIDE("/", (x, y) -> x / y);

    private final String symbol;
    private final DoubleBinaryOperator op;

    Operation(String symbol, DoubleBinaryOperator op) { 
        this.symbol = symbol; 
        this.op = op;
    }

    @Override public String toString() { return symbol; }

    public abstract double apply(double x, double y) {
        return op.applyAsDouble(x, y);
    }
}

이 코드에서 열거 타입 상수의 동작을 표현한 람다를 DoubleBinaryOperator 인터페이스 변수에 할당했습니다.

DoubleBinaryOperator는 java.util.function 패키지가 제공하는 다양한 함수 인터페이스(아이템 44) 중 하나로, double 타입 인수 2개를 받아 double 타입 결과를 돌려줍니다.

 

람다 기반 Operation 열거 타입을 보면 상수별 클래스 몸체는 더 이상 사용할 이유가 없다고 느낄지 모르지만, 꼭 그렇지는 않습니다.

메서드나 클래스와 달리, 람다는 이름이 없고 문서화도 못합니다.

따라서 코드 자체로 동작이 명확히 설명되지 않거나 코드 줄 수가 많아지면 람다를 쓰지 말아야 합니다.

람다는 한 줄 일때 가장 좋고 길어야 세 줄 안에 끝내는 게 좋습니다.

세 줄을 넘어가면 가독성이 심하게 나빠집니다.

람다가 길거나 읽기 어렵다면 더 간단히 줄여보거나 람다를 쓰지 않는 쪽으로 리팩터링해야 합니다.

열거 타입 생성자에 넘겨지는 인수들의 타입도 컴파일타임에 추론됩니다.

따라서 열거 타입 생성자 안의 람다는 열거 타입의 인스턴스 멤버에 접근할 수 없습니다.

⇒ 인스턴스는 런타임에 만들어지기 때문입니다.

따라서 상수별 동작을 단 몇 줄로 구현하기 어렵거나, 인스턴스 필드나 메서드를 사용해야만 하는 상황이라면 상수별 클래스 몸체를 사용해야 합니다.

이처럼 람다의 시대가 열리면서 익명 클래스는 설 자리가 크게 좁아진 게 사실입니다.

하지만 람다로 대체할 수 없는 곳이 있습니다.

람다는 함수형 인터페이스에서만 쓰입니다.

예컨대 추상 클래스의 인스턴스를 만들 때 람다를 쓸 수 없으니, 익명 클래스를 써야 합니다.

비슷하게 추상 메서드가 여러 개인 인터페이스의 인스턴스를 만들 때도 익명 클래스를 쓸 수 있습니다.

마지막으로, 람다는 자신을 참조할 수 없습니다.

자바 8에 추가된 기술 [2] 람다 표현식

람다에서의 this 키워드는 바깥 인스턴스를 가리킵니다.

반면 익명 클래스에서의 this는 익명 클래스의 인스턴스 자신을 가리킵니다.

그래서 함수 객체가 자신을 참조해야 한다면 반드시 익명 클래스를 써야 합니다.

람다도 익명 클래스처럼 직렬화 형태가 구현별로 다를 수 있습니다.

따라서 람다를 직렬화하는 일은 극히 삼가야 합니다. (익명 클래스의 인스턴스도 마찬가지입니다.)

직렬화해야만 하는 함수 객체가 있다면(Comparator) private 정적 중첩 클래스(아이템 24)의 인스턴스를 사용합시다.

정리

• 자바가 8로 판올림되면서 작은 함수 객체를 구현하는 데 적합한 람다가 도입되었다.
• 익명 클래스는 (함수형 인터페이스가 아닌) 타입의 인스턴스를 만들 때만 사용하라.
• 람다는 작은 함수 객체를 아주 쉽게 표현할 수 있어 (이전 자바에서는 실용적이지 않던) 함수형 프로그래밍의 지평을 열었다.