예전에는 자바에서 함수 타입을 표현할 때 추상 메소드를 하나만 담은 인터페이스(드물게는 추상 클래스)를 사용했다. 이런 인터페이스의 인스턴스를 함수 객체(function object)라고 하여, 특정 함수나 동작을 나타내는 데 썼다. 함수 객체를 만드는 주요 수단은 익명 클래스였는데, 문자열을 길이순으로 정렬할 때 정렬을 위한 비교 함수를 예로 보자.
1 2 3 4 5 6 | // 익명 클래스의 인스턴스를 함수 객체로 사용 - 낡은 기법이다! Collections.sort(words, new Comparator<String>() { public int compare(String s1, String s2) { return Integer.compare(s1.length(), s2.length()); } }); | cs |
전략 패턴처럼 함수 객체를 사용하는 과거 객체 지향 디자인 패턴에는 익명 클래스면 충분했다. 하지만 익명 클래스 방식은 코드가 너무 길기 때문에 자바는 함수형 프로그래밍에 적합하지 않았다.
자바 8에 와서 추상 메소드 하나짜리 인터페이스는 특별한 의미를 인정받아 특별한 대우를 받게 되는데, 지금은 함수형 인터페이스라 부르는 이 인터페이스들의 인스턴스를 람다식(lambda expression, 혹은 짧게 람다)을 사용해 만들 수 있게 된 것이다.
람다는 함수나 익명 클래스와 개념은 비슷하지만 코드는 훨씬 간결하다. 다음은 익명 클래스를 사용한 앞의 코드를 람다 방식으로 바꾼 모습이다.
1 2 3 | // 람다식을 함수 객체로 사용 - 익명 클래스 대체 Collections.sort(words, (s1, s2) -> Integer.compare(s1.length(), s2.length())); | cs |
여기서 람다, 매개변수(s1, s2), 반환값의 타입은 각각 (Comparator<String>), String, int지만 코드에서는 언급이 없다. 우리 대신 컴파일러가 문맥을 살펴 타입을 추론해준 것이다. 상황에 따라 컴파일러가 타입을 결정하지 못할 수도 있는데, 그럴 때는 프로그래머가 직접 명시해야 한다. 타입을 명시해야 코드가 더 정확할 때만 제외하고는, 람다의 모든 매개변수 타입은 생략하자. 컴파일러가 "타입을 알 수 없다"는 오류를 낼 때만 해당 타입을 명시하면 된다.
람다 자리에 비교자 생성 메소드를 사용하면 이 코드를 더 간결하게 만들 수 있다.
1 | Collections.sort(words, comparingInt(String::length)); | cs |
더 나아가 자바 8 때 List 인터페이스에 추가된 sort 메소드를 이용하면 더욱 짧아진다.
1 | words.sort(comparingInt(String::length)); | cs |
람다를 언어 차원에서 지원하면서 기존에는 적합하지 않았던 곳에서도 함수 객체를 실용적으로 사용할 수 있게 되었다. 다음은 Operation 열거 타입을 람다를 이용해 구현한 예다.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 | // 함수 객체(람다)를 인스턴스 필드에 저장해 상수별 동작을 구현한 열거 타입 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 double apply(double x, double y) { return op.applyAsDouble(x, y); } } | cs |
람다를 이용하면 열거 타입의 인스턴스 필드를 이용하는 방식으로 상수별로 다르게 동작하는 코드를 쉽게 구현할 수 있다. 단순히 각 열거 타입의 상수의 동작을 람다로 구현해 생성자에 넘기고, 생성자는 이 람다를 인스턴스 필드로 저정해둔 다음, apply 메소드에서 필드에 저장된 람다를 호출하기만 하면 된다.
람다 기반 Operation 열거 타입을 보면 상수별 클래스 몸체는 더 이상 사용할 이유가 없다고 느낄지 모르지만, 꼭 그렇지는 않다. 메소드나 클래스와 달리, 람다는 이름이 없고 문서화도 못한다. 따라서 코드 자체로 동작이 명확히 설명되지 않거나 코드 줄 수가 많아지면 람다를 쓰지 말아야 한다. 람다는 한 줄일 때 가장 좋고 길어야 세 줄 안에 끝내는 게 좋다.
람다가 도입되면서 익명 클래스의 입지가 좁아지긴 했으나, 람다로 대체할 수 없는 곳이 있다. 람다는 함수형 인터페이스에서만 쓰인다. 예컨대 추상 클래스의 인스턴스를 만들 때 람다를 쓸 수 없으니, 익명 클래스를 써야 한다. 비슷하게 추상 메소드가 여러 개인 인터페이스의 인스턴스를 만들 때도 익명 클래스를 쓸 수 있다. 마지막으로, 람다는 자신을 참조할 수 없다. 람다에서의 this 키워드는 바깥 인스턴스를 가리키는 반면, 익명 클래스에서의 this는 익명 클래스의 인스턴스 자신을 가리키기 때문에 함수 객체가 자신을 참조해야 한다면 반드시 익명 클래스를 써야 한다.
람다로 익명 클래스처럼 직렬화 형태가 구현별로 다를 수 있다. 따라서 람다를 직렬화하는 일은 극히 삼가야 한다(익명 클래스의 인스턴스도 마찬가지다). 직렬화해야만 하는 함수 객체가 있다면 private 정적 중첩 클래스의 인스턴스를 사용하자.
자바가 8로 판올림되면서 작은 함수 객체를 구현하는 데 적합한 람다가 도입되었다. 익명 클래스는 함수형 인터페이스가 아닌 타입의 인스턴스를 만들 때만 사용하라. 람다는 작은 함수 객체를 아주 쉽게 표현할 수 있어 이전 자바에서는 실용적이지 않던 함수형 프로그래밍의 지평을 열었다.