Java 8 이전의 함수 객체
Function Object (함수 객체)
: Java 8 이전에는 자바에서 함수 타입을 표현할 때 추상 메서드를 하나만 담은 인터페이스(드물게는 추상 클래스)를 사용했는데, 이런 인터페이스의 인스턴스를 함수 객체라고 함
- 특정 함수나 동작을 나타내는 데에 사용함
익명 클래스 (item 24)
-
JDK 1.1이 등장하면서 함수 객체를 만드는 주요 수단이 됨
-
낡은 기법
-
예시 코드) 문자열을 길이순으로 정렬하는데, 정렬을 위한 비교 함수로 익명 함수를 사용함
Collections.sort(words, new Comparator<String>() { public int compare(String s1, String s2) { return Integer.compare(s1.length(), s2.length()); } });- 함수 객체를 사용하는 과거 객체 지향 디자인 패턴에는 익명 클래스면 충분했다. 이 코드에서 Comparator 인터페이스가 정렬을 담당하는 추상 전략을 뜻하며, 문자열을 정렬하는 구체적인 전략을 익명 클래스로 구현했다.
-
단, 익명 클래스 방식은 코드가 너무 길음 -> Java는 함수형 프로그래밍에 적합하지 않음
Lambda Expression(람다식)
:함수형 인터페이스들의 인스턴스
-
함수나 익명 클래스와 개념은 비슷하지만, 코드는 훨씬 간결함
-
Java 8에서 공식적으로 추가됨. 함수 객체가 특별한 의미를 인정받아, 특별한 대우를 받게 된 것임
-
예시 코드) 익명 클래스를 사용한 앞의 코드를 람다로 바꾼 코드
Collections.sort(words, (s1, s2) -> Integer.compare(s1.length(), s2.length()));- 여기서 람다, 매개변수(s1, s2), 반환값의 타입은 각각
(Comparator<String>),String,int지만 코드에서는 언급이 없음 (우리 대신 컴파일러가 문맥을 살펴 타입을 추론해줌)
상황에 따라 컴파일러가 타입을 결정하지 못할 수도 있음. 그럴 때에는 프로그래머가 직접 명시해줘야 함
타입 추론 규칙은 매우 복잡하여 이 규칙을 다 이해하는 프로그래머는 거의 없고, 잘 알지 못한다 해도 상관 없음
- 여기서 람다, 매개변수(s1, s2), 반환값의 타입은 각각
-
타입을 명시해야 코드가 더 명확할 때만 제외하고는, 람다의 모든 매개변수 타입은 생략하자.
- 그 다음 컴파일러가 '타입을 알 수 없다' 오류를 낼 때만 해당 타입을 명시하면 됨
- 반환값이나 람다식 전체를 형변환 할 때도 있긴 있지만, 아주 드뭄
+) 💡 컴파일러가 타입을 추론할 때에는 필요한 타입 정보 대부분을 제네릭에서 얻음
우리가 이 정보를 제공하지 않으면 컴파일러는 람다의 타입을 추론할 수 없게 되어, 결국 우리가 일일이 명시해야 함.
예시) 바로 위에 코드에서 인수 words가List<String>이 아니라List였으면 컴파일 오류 발생
-
람다 자리에 비교자 생성 메서드를 사용하면 이 코드를 더 간결하게 만들 수 있음
Collections.sort(words, comparingInt(String::length));📌 비교자 생성 메서드(Comparator Construction Method) (아이템 14)
: 객체 참조를 int 타입 키에 매핑되는 키 추출함수(key extractor function)를 인수로 받아, 그 키를 기준으로 순서를 정하는 비교자를 반환하는 정적 메서드- 매우 간결하다는 장점이 있지만, 약간의 성능 저하가 뒤따름
-
더 나아가, Java 8 때 List 인터페이스에 추가된 sort 메서드를 이용하면 더욱 짧아짐
words.sort(comparingInt(String::length));
람다의 장점
-
람다를 언어 차원에서 지원하면서, 기존에는 적합하지 않았던 곳에서도 함수 객체를 실용적으로 사용할 수 있게 되었음
-
아이템 34의 Operation 열거타입 코드 개선하기
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); }-
상수별 클래스 몸체를 구현하는 방식보다는 열거 타입에 인스턴스 필드를 두는 방식임
-
람다를 이용하면 열거 타입의 인스턴스 필드를 이용하는 방식으로 상수별로 다르게 동작하는 코드를 쉽게 구현 가능
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
- java.util.function 패키지가 제공하는 다양한 함수 인터페이스 중 하나
- double 타입 인수 2개를 받아 double 타입 결과를 돌려줌
-
람다 유의사항
-
위 코드를 보면 상수별 클래스 몸체는 더 이상 필요가 없다고 느낄 수 있지만, 그렇지는 않다.
-
메서드와 클래스와 달리, 람다는 이름이 없고 문서화도 못 함
-
따라서 코드 자체로 동작이 명확히 설명되지 않거나, 코드 줄 수가 많아지면 람다를 쓰지 말아야 한다.
-
람다는 한 줄일 때 가장 좋고, 길어야 세 줄 안에 끝내는 것이 좋다. (가독성 때문에)
-
람다가 길거나 읽기 어려우면 더 줄여보거나, 람다를 빼고 리팩터링 해보자.
-
열거타입 생성자에 넘겨지는 인수들의 타입도 컴파일 타임에 추론됨 -> 열거 타입 생성자 안의 람다는 열거 타입의 인스턴스 멤버에 접근할 수 없다. (인스턴스는 런타임에 만들어짐).
- 따라서 상수별 동작을 단 몇 줄로 구현하기 어렵거나, 인스턴스 필드/메서드를 사용해야만 한다면 상수별 클래스 몸체를 사용해야 한다.
람다 vs 익명 클래스
-
람다의 시대가 열리며 익명 클래스는 입지가 매우 좁아졌다.
-
그러나 람다로는 대체할 수 없는 곳이 있다.
-
람다 : 함수형 인터페이스에서만 쓰인다.
- 추상 클래스의 인스턴스를 만들 때, 람다를 쓸 수 없음 -> 익명클래스 사용
- 추상 메서드가 여러 개인 인터페이스의 인스턴스를 만들 때 -> 익명클래스 사용
- 람다는 자기 자신을 참조할 수 없음(람다의 this : 바깥 인스턴스 지칭) -> 익명클래스 사용 (익명클래스의 this : 자기 자신의 인스턴스 가리킴)
-
람다도 익명클래스처럼 직렬화 형태가 구현 별로 다를 수 있다.
=> 람다를 직렬화 하는 일은 극히 삼가야 한다. (= 익명 클래스)- 직렬화해야만 하는 함수 객체(ex: Comparator) : private 정적 중첩 클래스의 인스턴스를 사용하라
