item 42 익명 클래스보다는 람다를 사용하라

ITEM 42 익명 클래스보다는 람다를 사용하라

---

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

• 이런 인터페이스를 함수객체(function object)라고 하여 특정 함수나 동작을 나타내는 경우 사용

jdk 1.1 등장 이후 함수 객체를 만드는 주요 수단은 익명클래스가 되었다

문자열을 길이 순으로 정렬하는 코드(정렬을 위한 비교 함수로 익명 클래스를 사용한다)

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

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

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

여기서는 Comparator 인터페이스가 정렬을 담당하는 추상 전략, 문자열을 정렬하는 구체적인 전략을 익명 클래스로 구현 

위와 같이 익명 클래스로 코드를 구현하면 코드가 너무 길어져 자바는 함수형 프로그래밍에 적합하지 않았다

자바 8이 되면서 추상 메서드가 하나뿐인 인터페이스는 특별한 의미를 인정받아 특별한 대우를 받게 되었다

• 함수형 인터페이스라고 부르게 되며 이 인터페이스들의 인스턴스를 람다식(람다)을 사용해 만들 수 있게 됨
  • 람다는 함수나 익명 클래스와 개념은 비슷하지만 코드는 훨씬 간결하다

위 예제를 람다로 바꾼 코드

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

람다식을 함수 객체로 사용 - 익명 클래스 대체

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

람다, 매개변수(s1, s2), 반환값의 타입은 각각 (Comparator<String>), String, int 인데 코드에서는 나타나지 않는다

우리 대신 컴파일러가 문맥을 살펴보고 타입을 추론한 것

상황에 따라 타입을 추론하지 못하는 경우에는 개발자가 직접 명시해줘야됨

타입 추론 규칙은 너무 복잡한 내용이라 다 알기가 힘들다 

(다 몰라도 되며 타입을 명시해야 코드가 더 명확한 경우를 제외하고 람다의 모든 매개변수 타입은 생략하자
그 후 컴파일러가 타입을 알수 없다고 알려주면 그때 타입을 명시하면 됨
반환값이나 람다식 전체를 형변환 해야하는 경우도 있을 수 있지만 매우 드문 경우이다)

타입 추론 관련해서는 지난 아이템인 item 26, item 29, item 30에서 이야기 한 규칙을 잘 지켜야 한다
(제네릭의 로 타입을 쓰지 않기, 제네릭을 사용하자, 제네릭 메서드를 사용하자)
이러한 규칙들은 람다와 같이 쓰는 경우 매우 중요해지는데 그 이유는 컴파일러가 타입을 추론할때 필요한 타입 정보 대부분을 제네릭에서 얻기 때문이다

위와 같이 람다를 사용해도 간결하지만 람다 자리에 비교자 생성 메서드를 사용하면 코드가 더 간결해진다

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

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

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

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

item 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; }

  //toString을 재정의하여 계산식 출력을 편하게 확인 가능하다
  @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 String DoubleBinaryOperator op;

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

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

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

람다 기반 Operation 열거 타입을 보면 상수별 클래스 몸체는 더이상 사용할 필요가 없다고 생각되지만 꼭 그런것은 아니다

• 메서드나 클래스와 다르게 람다는 이름이 없고 문서화도 못 한다
• 따라서 코드 자체로 동작이 명확히 설명되지 않거나 코드 줄 수가 많아지면 람다를 쓰지 말아야 한다

람다는 1줄인 경우에 가장 좋으며 길어야 3줄로 끝내자

• 세줄이 넘어가면 가독성이 너무 안좋아지니 너무 길거나 읽기가 어렵다면 람다를 쓰지 않는 방식으로 리팩토링을 하자

열거타입 생성자에 넘겨지는 인수들의 타입도 컴파일 타임에 추론된다 따라서 열거 타입 생성자 안의 람다는 열거타입의 인스턴스 멤버에 접근할 수 없다

• 인스턴스는 런타임에 만들어진다
• 따라서 상수별 동작을 짧게 구현하기 어렵거나 인스턴스 필드나 메서드를 사용해야 하는 경우라면 상수별 클래스 몸체를 사용해야 한다

람다의 시대가 도래하며 익명 클래스는 설 자리가 크게 좁아지만 람다로 대체하지 못하는 곳도 있다

• 람다는 함수형 인터페이스에서만 사용된다
  • 추상 클래스의 인스턴스를 만드는 경우 람다를 쓸 수 없으니 익명 클래스를 써야한다
• 추상 메서드가 여러 개인 인터페이스의 인스턴스를 만드는 경우도 익명 클래스를 쓸 수 있다
• 또 람다는 자기 자신을 참조할 수 없다
  • 람다에서의 this는 바깥의 인스턴스를 말한다
  • 따라서 함수 객체가 자신을 참조해야 하는 경우는 익명 클래스를 사용해야 한다(익명 클래스의 this는 익명 클래스 자신의 인스턴스를 말한다)

람다도 익명 클래스처럼 직렬화 형태가 구현별로 다를 수 있으니 람다를 직렬화 하는 일은 극히 삼가해야 한다

• 이건 익명 클래스의 인스턴스도 마찬가지이다
• 직렬화해야하는 함수 객체가 있으면 private 정적 중첩 클래스(아이템 24)의 인스턴스를 사용하자

자바 8이 되며 작은 함수 객체를 구현하는데 적합한 람다가 도입되었다

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

람다는 작은 함수 객체를 아주 쉽게 표현 가능해 함수형 프로그래밍의 지평을 열었다(그 전까지 함수형 프로그래밍이 자바에서 실용적이지 않았다)