[모던자바인액션] 람다 표현식 : 익명 함수를 간결하게 만들기

💬 모던 자바 인 액션 챕터 3을 읽고 정리한 글입니다. 

 

---

✔️ 람다가 뭔데요?

지난 챕터에서는 동작 파라미터화를 통해서 파라미터로 메서드의 동작 자체를 전달해주는 것을 배웠다. 이때, 메서드의 동작을 전달하기 위해서 별도의 @Override 어노테이션이나 상속된 메서드 이름 등, 동작 외에 다른 코드들이 반복되어 상당히 불편했다. 람다 표현식은 이를 해결하기 위해서, 단순히 '동작에 대한 코드만' 메서드로 전달할 수 있도록 익명 함수를 단순화한 것이다.

 

람다 표현식은 다음과 같은 특징을 가진다.

💬 메서드에 이름이 없으니까 “익명”이다. (메서드에 대한 네이밍을 고민할 필요가 없다!)
- 이름은 없지만, 파라미터 리스트와 바디, 반환 형식, 발생 가능한 예외 리스트는 가질 수 있다.
💬 함수 : 특정 클래스에 종속되지 않고, 독립적으로 구성된다. 하지만 메서드처럼 파라미터, 바디, 리턴값, 가능한 예외까지 모두 포함한다!
- 챕터 1에서 설명했던 (메서드 vs 함수의 내용을 생각하자!)
💬 전달 : 람다 표현식은 마치 ‘일급 객체’처럼 인수로 전달하거나, 변수로 저장이 가능하다.
💬 간결성 : 코드가 간결해진다! 단순히 동작 자체만 넘겨줄 수 있다.

 람다 표현식은 어떻게 구성되어 있을까?

(Crew a1, Crew a2) -> Integer.compare(a1.getAge(), a2.getAge());

 

(Crew a1, Crew a2) : 람다 파라미터, 현재 코드에서는 compareTo에 사용되는 파라미터 2개를 의미한다.

→ : 화살표, 파라미터 리스트와 바디를 구분해주는 역할을 한다.

Integer.compare(a1.getAge(), a2.getAge()) : 람다 바디, 람다의 반환값을 표현해준다.

 

또한, 람다는 크게 표현식 스타일과 블록 스타일로 표현할 수 있다.

표현식 스타일: () -> "Hello Crew!”

블록 스타일: () → { return “Hello Crew!”; }

 

블록에서는 return과 세미콜론을 붙여줘야 한다. 주로 여러 행을 입력해야 할 때 사용하며, 간결한 경우 표현식 스타일로도 만들 수 있다.

 

---

✔️ 그래서 람다… 어디서 사용하는데?

람다로 간결해진다는 것까지는 알게 되었다. 하지만, 이를 어떻게 응용하면 좋을지 아직 감이 잡히지 않는다. 교재에서는 다음과 같이 람다의 사용법을 설명한다. 

 

💡 주로 함수형 인터페이스에서 람다를 사용합니다.

 

갑자기 함수형 인터페이스? 무슨 말인지 이해하기 어려울 수 있지만, 우리는 이미 함수형 인터페이스를 본 적이 있다. 함수형 인터페이스는 '디폴트 메서드의 유무에 관계없이, 오직 추상 메서드를 1개만 가지는 인터페이스'이다. 아래는 자바에서 제공하는 대표적인 함수형 인터페이스 중 하나인 Predicate이다.

@FunctionalInterface
public interface Predicate<T> {
        boolean test(T t);
        }

우리는 챕터 2에서 사용하였던 다중 조건에 대해 검증을 위해 Predicate 인터페이스를 사용하였다. 여기서 Predicate<T>를 함수형 인터페이스라고 할 수 있으며, 오직 하나의 추상 메서드인 'test()'만 가지고 있다.

 

우리가 흔히 정렬할 때 사용하는 Comparator<T> 역시, 함수형 인터페이스의 일종이다.

@FunctionalInterface
public interface Comparator<T> {
        int compare(T o1, T o2);
        }

compare()라는 추상 메서드를 가지고 있으며, 자바에서는 명시적으로 해당 인터페이스가 함수형 인터페이스임을 알리기 위해서 @FunctionalInterface라는 어노테이션을 붙여서 표현한다. (해당 어노테이션을 붙이면 해당 인터페이스가 함수형 인터페이스임을 보장하며, 추상 메서드가 없어지거나 늘어났다든지, 함수형 인터페이스의 정의에 맞지 않게 되면 컴파일 에러가 발생하게 된다.)

 

💬 추상 메서드는?

추상 메서드의 정의에 대해서 헷갈릴 수도 있다. 추상 메서드란, 자식 클래스에서 반드시 오버라이딩 해야지 사용할 수 있는 메서드를 의미한다. 즉, Comparator를 구현한 클래스는 반드시 compare()를 구현해야 한다.

NaturalOrderComparator implements Comparator<Comparable<Object>> {
@Override
public int compare(Comparable<Object> c1, Comparable<Object> c2) {
        return c1.compareTo(c2);
        }

Intellij의 도움을 받아, Comparator를 기본으로 구현한 Comparators의 구현체인 NaturalOrderComparator를 가져왔다. (보통 오름차순으로 정렬할 때 해당 클래스를 많이 사용한다.) 해당 클래스를 보면 위와 같이 compare를 구현한 것을 볼 수 있다.

 

추상 메서드를 사용하는 이유는, ‘중복되는 부분, 공통되는 부분’은 미리 만들어져있는 것을 사용하고, 생산하는 쪽에서 이를 받아서 처리할 수 있도록 하기 위함이다. 즉, 생산하는 쪽에서 판단하여 본인에게 필요한 부분을 재정의할 수 있도록 하기 위해서이다.

 private static class ReverseComparator implements Comparator<Comparable<Object>>, Serializable {
public int compare(Comparable<Object> c1, Comparable<Object> c2) {
        return c2.compareTo(c1);
        }

예를 들어, NaturalOrderComparator의 경우 위와 같이 인자로 들어온 c1, c2 순으로 두 값을 비교하지만, ReverseComparator의 경우 c2, c1 순으로 값을 비교하는 것을 볼 수 있다. 

 

자, 다시 돌아와서 추상 메서드는 abstract 키워드를 붙이며, 끝에 세미콜론(;)을 붙이는 것이 관습이다. 그러나 인터페이스에서는 abstract를 생략할 수 있으며, 인터페이스의 모든 메서드는 ‘추상 메서드’라고 생각하면 된다.

 

그러면, 여기서 퀴즈! Child 인터페이스는 함수형 인터페이스라고 할 수 있을까?

public interface Parent {
    int hello(int a, int b);
}
public interface Child extends Parent{
    int hello(double a, double b);
}

 

→ 땡! Child 인터페이스를 상속받으며 받은 hello(int a, int b);에 의해서 추상 메서드가 2개가 되기 때문에 함수형 인터페이스라고 할 수 없다.

---

✔️ 함수형 인터페이스… 왜 쓰는 건데?

앞서 계속 말한 '함수형 인터페이스'라는 단어로 인해서 슬슬 어지러워지기 시작했다. 함수형 인터페이스는, “추상 메서드가 1개인 인터페이스는 함수형 인터페이스”이다. 우리는 이 문장에서 “추상 메서드가 1개”라는 것에 주목해야 한다. 람다 표현식을 통해, 이러한 함수형 인터페이스의 인스턴스를 쉽게 구현할 수 있기 때문이다!

 

간단하게 Runnable 인터페이스를 사용해보자. 

// 익명 클래스를 사용했을 경우
Runnable r1 = new Runnable() {
@Override
public void run() {
        System.out.println("Anonymous class");
        }
        };

// 람다를 사용했을 경우
        Runnable r2 = () -> System.out.println("Lambda");

Runnable<T>은 run()이라는 추상 메서드를 1개만 가지고 있는 함수형 인터페이스이다. 익명 클래스를 사용하게 되면, 위와 같이 Runnable 인터페이스에 대한 구현체를 생성하지 않고도 파라미터 내에서 바로 전달해줄 수 있다. 이때, 내부의 메서드가 딱 1개임을 보장하기 때문에 람다를 사용해서 '동작 자체'만 전달할 수 있도록 변경할 수 있게 된다! 👍

 

이때, 우리는 이러한 람다 표현식의 시그니처를 표현하기 위해서 '함수 디스크립터'라는 별도의 용어를 사용할 수 있다. 앞서 말한 것처럼, 함수형 인터페이스의 추상 메서드는 람다 표현식으로 만들 수 있기 때문에, 우리는 다음과 같이 정의할 수 있다.

 

💡 함수형 인터페이스의 시그니처는 람다 표현식의 시그니처와 동일하다.
우리는 이러한 시그니처에 대해서 '함수 디스크립터'라고 말할 수 있다.

 

여기서 시그니처란, 메서드명과 파라미터의 순서, 타입, 개수를 의미한다. (리턴 타입, 예외는 제외한다!)

// 람다 표현식 : () -> {}
// 이때, 시그니처는 () -> void
execute(() -> {});

public void execute(Runnable r) {
        // 추상 메서드
        // 이때, 시그니처는 () -> void
        r.run();
        }

코드를 살펴보자. 위 코드에서 람다 표현식의 시그니처는 () -> void, 추상 메서드의 시그니처 역시 () -> void이다.  

---

✔️ 실행 어라운드 패턴

자바7에서부터 추가된 Try-with-resources를 활용하면 try에 자원 객체를 전달하고, try 코드 블록이 끝나면 자동으로 자원을 종료해줄 수 있다. 즉, 모든 catch 블록에 별도의 종료 처리를 하거나, finally 블록을 선언하지 않아도 된다. 이전까지는 항상 자원을 생성하고, 사용하고, 해제할 때에는 아래와 같이 중복되는 코드가 필요했었다.

Resource resource = null;
        try {
        resource = getResource();
        // 리소스 사용 로직
        } catch (...) {
        ... // 예외 처리 로직
        } finally {
        if (resource != null) {
        try {
        resource.close(); // 자원 할당 해제
        } catch (Exception ignored) {
        }
        }
        }

자원 해제를 위해서, 다음과 같이 중복되는 try-catch 문이 필요했던 것이다. 그러나, 자바 7에서는 try-with-resources라는 특징이 추가되어, try에 자원을 전달하게 되면 finally에서 종료 처리를 하지 않아도 자동으로 자원을 종료해주게 된 것이다. 

try (Resource resource = getResource()) {
        // 리소스 사용
        } catch(...) {
        ...
        }

위와 같이 코드가 훨씬 간결해지는 것을 볼 수 있다.

 

우리는 위와 같은 과정을 이제 '실행 어라운드 패턴'이라고 말할 것이다. 그리고, 이러한 실행 어라운드 패턴을 구현하기 위해서 람다와 동작 파라미터를 사용할 것이다. 벌써부터 말이 너무 어렵다. 쉽게 설명하면, 실제 자원을 처리하는 로직을, 설정 + 정리 과정으로 감싸는 것을 의미한다.

 

💡 즉, 실행 어라운드 패턴이란 (초기화/준비) → 작업 처리! → (정리/마무리) 이다.

 

실제로 어떤 식으로 실행 어라운드 패턴을 적용할 수 있는지 코드를 통해서 살펴보자.

public String processFile() throws IOException {
        try (BufferedReader br =
        new BufferedReader(new FileReader("data.txt"))) {
        return br.readLine();
        }
        }

BufferedReader를 통해 파일의 한 줄을 읽는 코드이다. 위 코드를 차례대로 변화시켜가며 알아보자.

 

💬 지금은 고작 한 줄 읽고 끝내는데, 나는 한 번에 10줄을 읽는 코드를 구현해 주세요.

: 우리가 이러한 요구사항을 받았을 때 기존의 코드에서 어떤 걸 생각할 수 있을까?

 

1. 이미 파일에 접근하는 부분은 있다.

2. 값을 읽어오기 위한 Reader도 준비되어 있다.

3) 1줄이 아닌, 10줄을 읽도록 하는 로직이 필요하다.

 

우리는, BufferedReader를 통해 10줄을 읽도록 만들기 위해, processFile() 메서드에게 동작을 전달해주도록 수정할 것이다. 동작을 전달해주는 것, 즉 ‘동작 파라미터화’를 이용하자는 것이다. 

// 우리는 이렇게 동작할 수 있도록 만들고 싶다.
String result =
        processFile((BufferedReader br) -> {
        StringBuilder fileMessage = new StringBuilder();
        for (int i = 0; i < 10; i++) {
        fileMessage.append(br.readLine());
        }
        return fileMessage.toString();
        };

우리는 람다를 활용하여 다음과 같이 10줄을 받아서 처리하도록 만들었다. (처음부터 람다 표현식을 만들었다기보단, 10줄을 처리하는 동작 자체를 파라미터로 넘겼다고 보는 것이 더 쉽다.) processFile()의 인자로 10줄을 읽는 동작 자체를 전달해준 것이다. 이렇게 만든 동작 자체를 파라미터화 시켰다면, 이제 이를 바탕으로 함수형 인터페이스를 하나 선언해보자.

 

@FunctionalInterface
public interface BufferedReaderProcessor {
    String process(BufferedReader b) throws IOException;
}

람다 표현식의 시그니처와 추상 메서드의 시그니처는 동일하기 때문에, 파라미터로 BufferedReader를 선언해준다. (메서드명은 익명 함수이기 때문에 별도로 고려하지 않아도 된다.) 이제, 이러한 process() 메서드의 시그니처와 동일한 람다를 전달해보자.

 

public String processFile(BufferedReaderProcessor p) throws IOException {
        try (BufferedReader br =
        new BufferedReader(new FileReader("data.txt"))) {
        return p.process(br); // 이렇게 처리할 수 있게 되었다!
        }
        }

코드를 보면, 인자로 BufferedReaderProcessor라는 함수형 인터페이스를 받는 것을 볼 수 있다. 이렇게 받은 함수형 인터페이스의 process() 메서드를 호출하여 실제 동작을 실행할 수 있도록 만들었다. 이제, 우리는 함수형 인터페이스를 사용하지 않고 다시 한 번  동일한 시그니처를 가진 람다 표현식으로 변경할 수 있다.

 

// 10줄 읽기
String tenLine =
        processFile((BufferedReader br) -> {
        StringBuilder fileMessage = new StringBuilder();
        for (int i = 0; i < 10; i++) {
        fileMessage.append(br.readLine());
        }
        return fileMessage.toString();
        };

// 1줄 읽기
        String oneLine =
        processFile((BufferedReader br) -> br.readLine());

최종적으로 정리한 코드를 보면, 동작 자체를 람다 표현식으로 전달하여 10줄로 읽든, 1줄로 읽든 자유롭게 만들 수 있게 되었다. 실행 어라운드 패턴을 활용하여, 실제로 동작을 처리하는 부분에 대해서 파라미터로 넘겨, 람다 표현식을 활용해 더 간결하게 코드를 작성할 수 있게 되었다. 아래 코드는, 어떤 과정으로 코드를 변경하는지 정리하는 부분이다. 

// Step 1 - return에서 바로 로직을 선언했기 때문에 확장성이 없다.
public String processFile() throws IOException {
        try (BufferedReader br =
        new BufferedReader(new FileReader("data.txt"))) {
        return br.readLine();
        }
        }

// Step 2 - 함수형 인터페이스 선언하기
@FunctionalInterface
public interface BufferedReaderProcessor {
    String process(BufferedReader b) throws IOException;
}

    // 기존의 코드에서 시그니처를 맞춰준다.
    public String processFile(BufferedReaderProcessor p) throws IOException { 
	...
    }

    // step 3 - 내부 구현 로직을 갈아끼울 수 있도록 만들기.
    public String processFile(BufferedReaderProcessor p) throws IOException {
        try (BufferedReader br = new BufferedReader(new FileReader("data.txt"))) {
            return p.process(br);
        }
    }

    // step 4 - 람다로 변경하기!
    String tenLine =
            processFile((BufferedReader br) -> {
        StringBuilder fileMessage = new StringBuilder();
        for (int i = 0; i < 10; i++) {
        fileMessage.append(br.readLine());
        }
        return fileMessage.toString();
        };

// 1줄 읽기
        String oneLine =
        processFile((BufferedReader br) -> br.readLine());

 

 

---

✔️ 함수형 인터페이스 응용하기

내용이 많아서 헷갈리는 부분이 많을 수밖에 없다. 가볍게 한 번 정리해보자.

✏️ 함수형 인터페이스는 하나의 추상 메서드만 가진다.
✏️  추상 메서드는 람다 표현식의 시그니처와 동일하다.
✏️  함수형 인터페이스의 추상 메서드 시그니처를 함수 디스크립터라고 한다.

 

자바에서는 이러한 함수형 인터페이스를 기본적으로 몇 가지 제공한다. java.util.function 패키지에 존재하며, 몇 가지 함수형 인터페이스를 간단하게 살펴보자.

 

💬 Predicate

@FunctionalInterface
public interface Predicate<T> {
        boolean test(T t);
        }

public <T> List<T> filter(List<T> list, Predicate<T> p) {
        List<T> results = new ArrayList<>();
        for (T t : list) {
        if (p.test(t)) {
        results.add(t);
        }
        }
        return results;
        }

// Example
        Predicate<String> nonEmptyStringPredicate = (String s) -> !s.isEmpty();
        List<String> nonEmpty = filter(listOfStrings, nonEmptyStringPredicate);

Predicate<T>는 test()라는 추상 메서드를 정의하고, 인자로 받은 제네릭 타입 T를 처리하여 boolean 값으로 반환하는 것이 특징이다. 주로 참/거짓에 대한 판단을 이용할 때 많이 사용한다.

 

💬 Consumer

@FunctionalInterface
public interface Consumer<T> {
        void accept(T t);
        }

public <T> void forEach(List<T> list, Consumer<T> c) {
        for (T t : list) {
        c.accept(t);
        }
        }

// example
        forEach(
        Arrays.asList(1,2,3,4,5),
        (Integer i)->System.out.println(i));

Consumer<T>는 accept()라는 추상 메서드를 정의하며, 인자로 받은 T 타입을 통해 어떠한 동작을 수행하도록 만든다. 이때, 리턴값이 없기 때문에 동작에 대한 실행 로직을 정의할 때 활용하기 좋다.

 

💬 Function

@FunctionalInterface
public interface Function<T, R> {
        R apply(T t);
        }

public <T, R> List<R> map(List<T> list, Function<T, R> f) {
        List<R> result = new ArrayList<>();
        for (T t : list) {
        result.add(f.apply(t));
        }
        return result;
        }

// example
        List<Integer> l = map(
        Arrays.asList("lambdas","in","action"),
        (String s)->s.length() // [7, 2, 6] 
        );

Function<T, R> 은 apply()라는 추상 메서드를 정의하며, 인자로 받은 T 타입을 통해 R 객체를 반환한다. 입력 → 출력으로 어떠한 객체를 생성할 시 유용하다.

 

참고로, 이러한 함수형 인터페이스 내부의 제네릭 파라미터는 무조건 레퍼런스 타입만 사용할 수 있는데, 이때 자바에서는 primitive 타입을 레퍼런스 타입으로 변환하는 기능을 제공한다. 이를 ‘박싱(Boxing)’이라고 하고, 반대의 과정을 ‘언박싱(Unboxing)’이라고 한다. 보통 자바에서는, 박싱과 언박싱을 자동으로 처리해주는 오토박싱(autoboxing)이 많이 사용되는데, 흔히 리스트에 값을 넣을 때 내부 요소는 wrapping 되어 들어간다.

List<Integer> list = new ArrayList<>();
        for (int i = 0; i < 10; i++) {
        // int -> Integer로 autoboxing 과정이 일어난다. 
        list.add(i);
        }

// ArrayList.java
public boolean add(E e) {
        modCount++;
        add(e, elementData, size);
        return true;
        }

private void add(E e, Object[] elementData, int s) {
        if (s == elementData.length)
        elementData = grow();

        elementData[s] = e;
        size = s + 1;
        }

궁금해서 찾아봤는데, 제네릭으로 받는 시점부터 레퍼런스 타입만 받을 수 있으니 컴파일러에서 알아서 wrapping 해준다고 판단하였다. 이러한 wrapping 과정은 결국 힙에 저장되면서 메모리 소비가 발생하기 때문에 성능적으로 이슈가 있을 수 있는데, 함수형 인터페이스를 활용하여 오토박싱을 피할 수 있게 된다.

 

IntPredicate evenNumbers = (int i) -> i % 2 == 0;
// 여기서 1000은 박싱하지 않는다. 오토박싱을 피할 수 있다.
        evenNumbers.test(1000);

        Predicate<Integer> oddNumbers = (Integer i) -> i % 2 != 0;
// Predicate<Integer>에서는 1000이라는 값을 Integer로 박싱하게 된다.
        oddNumbers.test(1000);

위 코드에서 사용하는 IntPredicate를 이용하게 되면, primitive 타입인 int 값을 boxing 하지 않은 상태로 Predicate<T> 인터페이스를 사용하는 효과를 얻을 수 있다. IntPredicate 외에도 다양한 타입에 맞는 Predicate가 존재하기 때문에 상황에 따라서 맞춰서 사용하면 좋을 것 같다. 

 

아래는 자바에서 제공하는 함수형 인터페이스와 디스크립터 정보이다. (물론 더 많이 있다!)

 

함수형 인터페이스 이름	함수 디스크립터
Predicate<T>	T -> boolean
Consumer<T>	T -> void
Function<T, R>	T -> R
Supplier<T>	() -> T
UnaryOperator<T>	T->T
BinaryOperator<T>	(T, T) -> T
BiPredicate<L, R>	(T, U) -> boolean
BiConsumer<T, U>	(T, U) -> void
BiFunction<T, U, R>	(T, U) -> R

 

💬 추가적으로, 함수형 인터페이스에서는 Checked Exception을 던지지 않는다. 교재에서는 단순히 예외를 던질 수 없다고 나와서, 무슨 말인지 이해가 안 됐었는데, 정확하게 말하면 자바에서 제공하는 기본 함수형 인터페이스의 추상 메서드에 대해서 별도로 Exception을 throw 하지 않는다는 말이었다. 그래서, 개발자가 직접 예외를 던지기 위해서는 커스텀 인터페이스를 정의해서 명시적으로 throws을 통해 전파시키거나, 람다 자체를 try - catch로 잡아서 runtime Exception으로 감싸서 처리해줘야 한다. (사실, 이는 checked exception의 개념 자체에서 나오는 문제가 아닌가 싶기는 하다.)

 

1) throws로 예외 전파하기

@FunctionalInterface
public interface BufferedReaderProcessor {
    String process(BufferedReader b) throws IOException;
}

    BufferedReaderProcessor p = (BufferedReader br) -> br.readLine();

2) try-catch로 잡아서 처리하기

 

Function<BufferedReader, String> f = (BufferedReader b) -> {
        try {
        return b.readLine();
        } catch (IOException e) {
        throw new RuntimeException(e);
        }
        };

 

 

---

✔️ 람다 표현식은 어떻게 구현체의 정보를 알까요?

람다 표현식은 람다가 사용되는 컨텍스트를 이용하여 람다의 형식을 추론할 수 있다. 이때, 람다에게 전달되는 파라미터나 변수 등 람다에서 사용되기를 기대하는 표현식의 형식을 ‘대상 형식’이라고 한다.

List<Crew> crews = filter(wootecho, (Crew crew) ->
        crew.getCourse().equals(BACKEND));

위 예제는 우테코 크루들 중에서 백엔드인 크루들만 뽑는 예제이다. 위 코드에서 람다 표현식은 어떻게 형식 검사를 진행하는지 알아보자.

 

1) filter 메서드의 선언 확인하기

// filterCrews의 정의
public List<Crew> filterCrews(List<Crew> crews, Predicate p) {
        List<Crew> resultCrews = new ArrayList<>();
        for (Crew crew : crews) {
        if (p.test(crew) {
        resultCrews.add(crew);
        }
        }
        }

// before
        filterCrews(wootecho, (Crew crew) → crew.getCourse().equals(BACKEND))

// after
        filterCrews(wootecho, Predicate<Crew> p)

현재, 위 코드에서 filterCrews()는 두 번째 파라미터로 Predicate<Crew> 형식을 기대한다. 여기서 Predicate<Crew>가 대상 형식이 된다.  

 

2) Predicate<Crew>의 시그니처에 대해서 살펴보기

자바에서 기본으로 제공되는 Predicate<T> 함수형 인터페이스는, test()라는 추상 메서드를 가진다. 이때, 해당 추상 메서드이ㅡ 시그니처는 T -> boolean이며, 위 예제에서는 Crew -> boolean이 된다.

 

3) 함수 디스크립터 묘사하기

이때, Crew를 인자로 받아 boolean을 반환하는 함수 디스크립터를 묘사하게 되며, 이 과정에서 람다 표현식이 예외를 던질 수 있다면 추상 메서드에서도 예외를 던질 수 있도록 throws로 던지거나, try-catch로 잡아 처리해야 한다. 아무튼, filter로 전달되는 인수는 위와 같은 요구사항을 만족해야 하며, 현재 코드에서는 (Crew crew) -> crew.getCourse.equals(BACKEND); 라는 코드 자체가 Crew -> boolean을 반환하고 있어서 

 

 

💬 이때, '대상 형식'이라는 특징 때문에, 람다식마다 그에 호환하는 추상 메서드를 가진 다른 함수형 인터페이스로 사용될 수 있다.

Comparator<Crew> c1 =
        (Crew a1, Crew a2) -> a1.getAge().compareTo(a2.getAge());

        ToIntBiFunction<Crew, Crew> c2 =
        (Crew a1, Crew a2) -> a1.getAge().compareTo(a2.getAge());

        BiFunction<Crew, Crew, Integer> c3 =
        (Crew a1, Crew a2) -> a1.getAge().compareTo(a2.getAge());

위의 세 코드 모두 Crew를 파라미터로 받아, compareTo를 통해서 비교한 결과를 내지만 (동일한 람다식이지만) 각각 다른 함수형 인터페이스가 사용된 것을 볼 수 있다. 

 

 

💬 람다의 void 호환 규칙

람다의 바디에 일반 표현식이 있으면, void를 반환하는 함수 디스크립터와 호환된다.

// Predicate는 불리언 반환값을 갖는다. (추가한 뒤 여부 반환)
Predicate<String> p = s -> list.add(s);

// Consumer는 void 반환값을 갖는다. (추가하는 것에 대한 행위)
        Consumer<String> b = s -> list.add(s);

list.add()는 원래 반환값이 boolean인 메서드인데, Predicate로도 사용할 수 있지만 아래와 같이 Consumer에서도 사용할 수 있는 것을 볼 수 있다. (여기서 일반 표현식이라는 말이 굉장히 모호한데, 기본적으로 자바는 메서드의 리턴값을 사용하지 않아도 된다. 그래서 위 예제에서도 리턴값을 사용하지 않을 수 있으니 void를 반환하는 Consumer와 사용하게 되면, 단순히 동작 자체만 실행하는 형태로 사용하는 식으로 하는 게 아닐까... 라는 게 내 생각이다 🤔)

 

 

💬 함수형 인터페이스의 메서드 오버라이딩

// Java에서 제공하는 함수형 인터페이스
@FunctionalInterface
public interface Runnable {
    public abstract void run();
}

// 내가 만든 함수형 인터페이스
@FunctionalInterface
public interface Sample {
    void run();
}

위와 같은 두 개의 함수형 인터페이스가 존재한다고 가정해보자.

public class Main {
    public static void main(String[] args) {
        execute(() -> {});
    }
    public static void execute(Runnable runnable) {
        runnable.run();
    }
    public static void execute(Sample sample) {
        sample.run();
    }
}

이때, () → {}라는 디스크립터가 () → void인 람다 표현식이 있을 때, 어떤 걸 사용하게 될까?

 

Intellij에서는 모호하다고 알려준다. 즉, 이 과정에서 대상 형식을 통해 컨텍스트가 동일한 ‘함수형 인터페이스’를 찾아나가는 걸 볼 수 있다. 그렇기 때문에, 명시적으로 캐스팅하는 과정이 필요하다.

public static void main(String[] args) {
        execute((Sample) () -> {});
        }

나는 내가 만든 게 좋으니까 이렇게 캐스팅을 진행했다.

 

💬 정리

💡 자바 컴파일러는 람다 표현식이 사용된 컨텍스트 (=대상 형식)을 통해, 람다 표현식과 관련된 함수형 인터페이스를 추론한다.
= 그렇기 때문에, 컴파일러는 람다의 시그니처까지 추론을 할 수 있다.
= 즉, 시그니처를 아니까 람다의 문법식 자체에서도 이를 생략할 수 있다!

 

---

✔️ 람다에서는 타입을 생략해도 된다던데?

우리는 위에서 컴파일러가 람다의 시그니처를 안다는 사실을 도출하였다.

// Before
List<Crew> crews = filter(wootecho, (Crew crew) ->
        crew.getCourse().equals(BACKEND));

// After
        List<Crew> crews = filter(wootecho, crew ->
        crew.getCourse().equals(BACKEND));

이런 식으로, 굳이 명시적으로 Crew라는 파라미터 타입을 지정해주지 않아도 되는 것을 알 수 있다. 특히, 파라미터의 개수가 늘어나면 각 파라미터 모두에게 타입을 지정해줄 필요가 없기 때문에 코드상으로도 더 간결해지게 된다.

 

즉, 정리하자면!

1. 자바 컴파일러는 람다 표현식이 사용된 컨텍스트 (대상 형식)을 통해 람다 표현식과 관련된 함수형 인터페이스를 추론한다.
2. 이렇게 추론한 함수형 인터페이스 덕분에, 함수 디스크립터를 알 수 있다. 
3. 즉, 컴파일러는 람다의 시그니처를 추론할 수 있다. (추상 메서드 시그니처 == 람다의 시그니처)
4. 컴파일러는 람다 표현식의 파라미터 형식에 접근할 수 있기 때문에, 문법적으로 생략이 가능하다.

 

---

✔️ 람다의 지역 변수

람다에서는 익명 함수처럼 외부에서 정의된 변수를 활용할 수 있다. (이를 자유 변수라고 하는데, 파라미터로 넘겨진 변수가 아닌, 외부에서 정의된 변수 자체를 의미한다고 생각하면 된다.) 이를 람다 캡처링이라고 부른다. 그러나, 이때 해당 지역변수는 명시적으로 final로 선언되어 있거나, final처럼 사용되어야 한다는 점이 큰 특징이다. (인스턴스, 클래스, 정적 변수는 상관없다.)

public class Main {
    private String pobi = "I'm pobi";  // 인스턴스 변수 
    private static String WOOTECO = "I'm Wooteco"; // 클래스 변수
    private static final String COACH = "I'm Coach"; // 정적 변수

    public void main(String[] args) {
        String crew = "I'm Crew"; // 지역 변수, final 취급이다.
        Runnable r1 = () -> System.out.println(crew);
        Runnable r2 = () -> System.out.println(COACH);
        Runnable r3 = () -> System.out.println(pobi);
        Runnable r4 = () -> System.out.println(WOOTECO);

        r1.run(); // I'm Crew
        r2.run(); // I'm Coach
        r3.run(); // I'm pobi
        r4.run(); // I'm Wooteco
    }

}

 

만약, crew에 다른 이름을 할당하려고 한다면, Intellij에서는 다음과 같이 람다 표현식은 final이어야 한다고 경고한다.

 

💬 왜 이런 제약을 건 걸까?

관련해서는 프롤로그에 글을 작성해두었다! 😎

우아한테크코스 학습로그 저장소

요약하자면, 인스턴스 변수는 heap, 정적 / 클래스 변수는 static 영역에 위치해 있기 때문에 모든 스레드가 접근이 가능하다. 그러나, 지역변수는 스레드 별로 스택 영역을 가지고 있기 때문에 라이프 사이클 자체는 변수가 선언된 블록이 된다. 그렇기 때문에, 만약 람다식을 별도의 스레드에서 실행한다면, 코드 블록이 끝났을 때 해당 변수는 스택에서 제거되지만 람다식이 수행될 때 여전히 해당 변수를 참조할 수 있기 때문에, 이러한 가능성을 없애기 위해서 람다는 보통 지역 변수의 복사본을 가지고 있는다. 복사본을 가지고 있기 때문에 원본 변수와 값이 달라지면 안 되기 때문에, final 키워드를 통해서 변경 자체를 막아버리는 것이다. 

 

---

챕터 3의 경우 내용이 굉장히 길어서 2개로 나눠쓸 예정이다.

개인적으로 람다 캡쳐링에 대한 내용이 굉장히 색달랐다 😎 얼른 남은 챕터도 써야겠다...!