[Effective-Java] Item 42. 익명 클래스보다는 람다를 사용하라

이전 자바에서 함수 타입 표현은 추상 메소드 하나인 interface, 혹은 추상클래스에서 jdk1.1(1997)이후 익명클래스를 주로 사용하게 됐다.

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

 

익명 클래스의 인스턴스를 함수 객체로 사용하는 방법

---

List<String> words = Arrays.asList("d","c","b","a");
Collections.sort(words, new Comparator<String>() {
    @Override
    public int compare(String s1, String s2) {
        return Integer.compare(s1.length(), s2.length());
    }
});

 

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

하지만 코드가 너무 길기 때문에 함수형 프로그래밍에 적합하지 않아 낡은 기법이다.

 

 

람다식을 이용하는 방법

---

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

위에서 익명클래스로 선언했던 Comparator는 람다로도 표현할 수 있다. 함수형 인터페이스기 때문이다.

 

 

익명클래스 방식인 Comparator를 람다식으로 바꿔보면 아래와 같다.

 

List<String> words = Arrays.asList("d","c","b","a");
Collections.sort(words, (s1, s2) -> Integer.compare(s1.length(), s2.length()));

 

 

 

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

컴파일러가 문맥을 살펴 타입을 추론해주는 것이다. 

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

 

컴파일러가 타입을 결정하지 못할 수도 있는데, 그 때 직접 명시하면 된다. 컴파일러가 타입을 추론하는 데 필요한 타입 정보 대부분은 제네릭에서 얻는다. 이 정보를 제공하지 않으면 컴파일러는 람다의 타입을 추론할 수 없게 되어, 하나하나 명시해야한다. words를 로타입인 List로 바꾼다면 컴파일 에러가 발생한다.

 

 

Collections의 sort 메소드를 보면 제네릭 타입이기 때문이다.

 

 

그리고 위 람다식 코드는 비교자 생성 메소드를 사용해 더 간결하게 만들 수도 있다.

 

List<String> words = Arrays.asList("d","c","b","a");
// String::length는 a->a.length()와 같다.(비한정적)
Collections.sort(words, Comparator.comparingInt(String::length));

 

Comparator의 정적 메소드인 comparingInt를 이용해, ToIntFunction 타입인 String의 length 메소드를 보낼 수 있어서다.

 

 

여기서 자바 8 List 인터페이스에 추가된 sort를 이용하면 더 짧아진다.

 

List<String> words = Arrays.asList("d","c","b","a");
words.sort(comparingInt(String::length));

 

 

람다식을 열거 타입에서 이용하는 방법

---

 

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;
    }
    public abstract double apply(double x, double y);
    }

 

아이템 34의 Operation을 예로들면,

apply 메소드의 동작이 상수마다 달라 상수별 클래스 몸체를 사용해 각 상수에서 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;
    }
    public double apply(double x, double y) {
        return op.applyAsDouble(x, y);
    }
 }

 

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

그리고 apply 메소드에서 필드에 저장된 람다를 호출하기만 하면 된다.

DoubleBinaryOperator는 java.util.function가 제공하는 함수 인터페이스로, double 타입 인수 2개를 받아 double 타입을 반환한다.

 

 

람다 사용 유의점

---

 

1. 람다는 이름이 없고 문서화도 못하기 때문에 코드 자체로 동작이 명확히 설명되지 않거나 코드 줄 수가 많아지면 람다를 쓰지 말아야 한다.

세 줄이 넘어가면 가독성이 나빠지고 람다가 길거나 읽기 어려우면 더 간단히 줄이거나 람다를 안쓰는 쪽으로 리팩토링 해야한다.

 

2. 인스턴스 필드나 메소드를 사용해야만 한다면, 상수별 클래스 몸체를 사용해야한다.

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

따라서 열거 타입 생성자 안의 람다는 인스턴스가 런타임에 만들어지기 때문에 열거 타입의 인스턴스 멤버에 접근할 수 없다.

 

람다로는 정적 필드나 메소드만 가능

 

상수별 클래스 몸체는 필드에 접근 가능

 

 

3. 람다는 함수형 인터페이스 에서만 쓰이기 때문에, 추상 클래스의 인스턴스를 만들 때 람다를 쓸 수 없으니 익명 클래스를 써야한다.

 

4. 추상 메소드가 여러 개인 인터페이스의 인스턴스를 만들때도 익명 클래스를 써야한다.

 

5. 람다는 자신을 참조할 수 없다.

람다에서 this는 바깥 인스턴스를 가리키는 반면 익명 클래스에서 this는 인스턴스 자신을 가리키기에, 함수 객체가 자신을 참조해야 한다면 익명 클래스를 사용해야 한다.

 

6. 람다를 직렬화하는 일은 극히 삼가야한다.(익명 클래스의 인스턴트도 마찬가지)

람다도 익명 클래스처럼 직렬화 형태가 구현별로 다를 수 있다. 직렬화해야 하는 함수 객체는 private 정적 중첩 클래스의 인스턴스를 쓰자.

 

 

정리

---

익명 클래스는(함수형 인터페이스가 아닌) 타입의 인스턴스를 만들때만 사용하자.

 

 

* 위 글은 EffectiveJava 3/E 책 내용을 정리한 글로, 저작권 관련 문제가 있다면 댓글로 남겨주시면 즉각 삭제조치 하겠습니다.