자바에서 함수 객체를 만드는 주요 수단은 익명 클래스였다. 아래는 문자열을 길이순으로 정렬하는데, 정렬을 위한 비교 함수로 익명 클래스를 쓴 것이다.
Collections.sort(words, new Comparator<String>() {
public int compare(String s1, String s2){
return Integer.compare(s1.length(), s2.length());
}
});하지만 익명 클래스 방식은 코드가 너무 길기 때문에 자바는 함수형 프로그래밍에 적합하지 않았다.
자바 8에서 함수형 인트페이스들의 인스턴스를 람다식을 사용해 만들 수 있게 되었다. 람다는 함수나 익명 클래스와 개념은 비슷한지만 코드는 훨씬 간결하다. 다음은 위의 코드를 람다 방식으로 바꾼 것이다.
Collections.sort(words, (s1, s2) -> Integer.compare(s1.length(), s2.length()));람다, 매개변수(s1, s2), 반환값의 타입이 명시되지 않은 모습이다. 우리가 명시하는 대신 컴파일러가 문맥을 살펴 타입을 추론해준 것이다. 상황에 따라 컴파일러가 타입을 결정하지 못할 수도 있는데, 그럴 때는 프로그래머가 직접 명시해야 한ㄷ. 타입을 명시해야 코드가 더 명확할 때만을 제외하고는, 람다의 모든 매개변수 타입은 생략하자.
추가로 타입 추론에 관해 알아야 할 것이 있다. 아이템 26에서는 제네릭의 로 타입을 쓰지 말라고 했고, 아이템 29에서는 제네릭을 쓰라 했고, 아이템 30에서는 제네릭 메서드를 쓰라고 했다. 이 조언들은 람다와 함께 쓸 때 두 배로 중요해진다. 컴파일러가 타입을 추론하는 데 필요한 타입 정보 대부분을 제네릭에서 얻기 때문이다.
람다를 이용하면 열거 타입의 인스턴스 필드를 이용하는 방식으로 상수별로 다르게 동작하는 코드를 쉽게 구현할 수 있다. 람다 기반의 열거 타입을 보면 상수별 클래스 몸체는 더 이상 사용할 이유가 없다고 느낄지 모르지만, 그렇지 않다. 메서드나 클래스와 달리 람다는 이름이 없고 문서화도 못 한다. 따라서 코드 자체로 동작이 명확히 설명되지 않거나 코드 줄 수가 많아지면 람다를 쓰지 말아야 한다. 또한 열거 타입 생성자에 넘겨지는 인수들의 타입도 컴파일타임에 추론된다. 따라서 열거 타입 생성자 안의 람다는 열거 타입의 인스턴스 멤버에 접근할 수 없다. 따라서 상수별 동작을 단 몇 줄로 구현하기 어렵거나, 인스턴스 필드나 메서드를 사용해야만 하는 상황이라면 상수별 클래스 몸체를 사용해야 한다.
람다가 들어오면서 익명 클래스의 사용이 줄긴 했지만, 람다로 완벽히 대체할 수 있는 것은 아니다. 람다는 함수형 인터페이스에서만 쓰인다. 예를 들어 추상 클래스의 인스턴스를 만들 때 람다를 쓸 수 없으니, 익명 클래스를 써야 한다. 비슷하게 추상 메서드가 여러 개인 인터페이스의 인스턴스를 만들 때도 익명 클래스를 써야 한다. 마지막으로 람다는 자신을 참조할 수 없다. 람다에서 this 키워드는 바깥 인스턴스를 가리킨다. 반면 익명 클래스의 this는 익명 클래스의 인스턴스 자신을 가리킨다. 그래서 함수 객체가 자신을 참조해야 한다면 반드시 익명 클래스를 써야 한다.
람다도 익명 클래스처럼 직렬화 형태가 구현별(가령 가상머신별로) 다를 수 있다. 따라서 람다(또는 익명 클래스의 인스턴스)를 직렬화하는 일은 극히 삼가야 한다. 직렬화해야만 하는 함수 객체가 있다면(가령 Comparator처럼) private 정적 중첩 클래스의 인스턴스(아이템 24)를 사용하자.
