[이펙티브 자바] 7장 : 람다와 스트림

자바 8에서 함수형 인터페이스, 람다, 메서드 참조라는 개념이 추가되었다. (함수 객체 쉽게 사용)

이와 함께 스트림 API 추가로 데이터 원소의 시퀀스 처리를 라이브러리 차원에서 지원하기 시작했다.

아이템 42 : 익명 클래스보다는 람다를 사용하라

1. 예전에 자바에서 함수 타입 표현 ⇒ 추상 메서드를 하나만 담은 인터페이스(or 추상클래스) 사용
2. JDK 1.1 등장 후 ‘익명 클래스'가 함수 객체를 만드는 주요수단

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

3. ‘익명클래스는 코드가 너무 길어 함수형 프로그래밍에 적합하지 않음’

자바 8에서 ‘추상메서드 하나의 인터페이스'는 특별하게 사용하게 되었다. ⇒ 함수형 인터페이스

함수형 인터페이스는 인스턴스를 ‘람다식'을 사용해 만들 수 있다. ⇒ 간결한 코드

List<String> words = Arrays.asList(args);
Collections.sort(words,
                (s1, s2) -> Integer.compare(s1.length(), s2.length()));

람다의 매개변수를 살펴보면 타입이 명시되어있지 않다. 이는 컴파일러가 타입추론을 해준것이다. (상황에 따라 타입 명시 필요)

• 타입 추론
  • 보통 컴파일러는 타입을 추론할 때 제네릭에서 정보를 얻는다. 만약 List가 로타입이였다면 타입 추론에 실패해 컴파일 에러가 발생했을 것이다.
• 비교자 생성 메서드
• Collections.sort(words, comparingInt(String::length));
• 자바 8에 추가된 sort 메서드모두 비교자 생성메서드가 람다식 자리에 들어간다.
• words.sort(comparingInt(String::length));

실용적 사용

람다가 추가되면서 함수객체를 실용적으로 사용할 수 있게 되었다.

람다를 사용하면 값마다 다르게 동작하는 코드를 쉽게 구현할 수 있다.(장점)

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

    // 아이템 34의 메인 메서드 (215쪽)
    public static void main(String[] args) {
        double x = Double.parseDouble(args[0]);
        double y = Double.parseDouble(args[1]);
        for (Operation op : Operation.values())
            System.out.printf("%f %s %f = %f%n",
                    x, op, y, op.apply(x, y));
    }
}

위 코드는 symbol값을 정의하고 DoubleBinaryOperator라는 함수형 인터페이스를 통해 쉽게 동작을 구현해서 주입해두었다. 이는 상수별 클래스 몸체 구현보다 구현은 편하지만 이름이 없고 문서화를 하지 못한다.(단점)

람다 한계

• 람다는 함수형 인터페이스에서만 쓰인다. 추상 클래스에서는 익명 클래스를 써야한다.
• 람다는 자신을 참조할 수 없다. (람다의 this는 바깥 인스턴스를 가리킴)
• 람다를 직렬화하는 일은 극히 삼가자 (구현별 직렬화가 다를 수 있다)

람다는 자바에서 함수 객체를 쉽게 표현할 수 있어 자바 함수형 프로그래밍의 지평을 열었다.

아이템 43 : 람다보다는 메서드 참조를 사용하라

람다의 장점은 간결함!!

그 장점을 더욱 극대화 시킨 것이 바로 ‘메서드 참조’

• 하지만 생략을 많이 하므로 적절하게 사용할 것

제목 없음

-핵심정리-

메서드 참조 쪽이 짧고 명확하다면 메서드 참조를 쓰고, 그렇지 않을 때만 람다를 사용하라

아이템 44 : 표준 함수형 인터페이스를 사용하라

자바의 람다 지원으로 인해 API 작성 모범사례도 변화하였다.

상위 클래스 기본 메서드를 재정의해 동작을 구현하는 ‘템플릿 메서드 패턴'은 현대적인 해법으로 함수 객체를 받는 정적 팩터리나 생성자 제공으로 사용할 수 있게 되었다.

**‘함수 객체'**를 매개변수로 받는 생성자나 메서드를 더 사용하게 되었다.

자바는 다양한 인수와 반환값을 지원하는 ‘표준 함수형 인터페이스'를 제공한다. (용도에 맞다면 직접 구현하지말 고 사용하라)

 

표준 함수형 인터페이스 예시

UnaryOperator<T>	T apply(T t)	String::toLowerCase
BinaryOperator<T>	T apply(T t1, T t2)	BigInteger::add
Predicate<T>	boolean test(T t)	Collection::isEmpty
Function<T, R>	R apply(T t)	Arrays::asList
Supplier<T>	T get()	Instant::now
Consumer<T>	void accept(T t)	System.out::println

위 예시 외에도 int, long, double용으로 변형한 IntPredicate(int를 받아 참/거짓 판단) 등의 변형이 생긴다.

인수 2개씩을 받는 BiConsumer<T, U>와 같이 변형이 생길 수도 있다.

이러한 함수형 인터페이스는 무려 43개나 된다. 모두 외울 필요는 없지만 자주 쓰는 패턴은 기억해두자.

• 표준 함수형 인터페이스는 기본 타입만 지원하므로 박싱 타입을 넣어 성능을 저하시키지 말자

 

-직접 작성이 필요한 경우-

• 표준 함수형 인터페이스에 용도가 맞는 게 없을 때 예를 들어 매개변수 3개 또는 검사 예외를 던지는 경우
• Comparator<T> 같은 경우
  • 자주 쓰이며, 이름 자체가 용도를 명확히 설명하는 경우
  • 반드시 따라야 하는 규약이 있는 경우
  • 유용한 디폴트 메서드를 제공할 수 있는 경우

직접 작성한 함수형 인터페이스에는 ‘@FunctionalInterface’ 애너테이션이 달려 있고 사용해야만 한다.

이를 사용하는 이유는 ‘@Override’ 사용이유와 비슷하다.

1. 이를 사용하는 이에게 인터페이스가 람다용으로 설계된 것임을 알림
2. 해당 인터페이스가 추상메서드를 오직 하나만 가지고 있을 때 컴파일 되게함
3. 2번을 통해 누군가 실수로 메서드를 추가하지 못하게 막을 수 있음

-핵심 정리-

자바도 람다를 지원하니 이제 API 설계시 입력값과 반환값에 함수형 인터페이스 타입을 활용하라. (표준 함수형 인터페이스 or 직접 구현한 인터페이스)

아이템 45 : 스트림은 주의해서 사용하라

스트림은 다량의 데이터 처리작업을 돕고자 자바 8에 추가되었다.

스트림 파이프라인은 중간연산 후에 종단 연산으로 끝난다. 또한 지연 평가가 되어 평가는 종단 연산이 호출될 때 이뤄진다.

스트림을 과하게 사용하면 프로그램 전체가 단 한줄에도 표현될 수 있지만 나와 거의 대부분 사람들이 코드를 이해하기 어려워진다. ⇒ 스트림이 과하면 읽거나 유지보스가 힘든 프로그램이 된다.

따라서, 기존 코드는 스트림을 사용하도록 리팩토링 하되, 새 코드가 나아 보일 때만 반영하자.

중간 연산으로 사용한 flatMap은 스트림의 원소 각각을 하나의 스트림으로 매핑한 다음 다시 그 스트림을 하나의 스트림으로 합친다. (중첩 람다 사용)

    // 코드 45-5 데카르트 곱 계산을 스트림 방식으로 구현 (276쪽)
    private static List<Card> newDeck() {
        return Stream.of(Suit.values())
                .flatMap(suit ->
                        Stream.of(Rank.values())
                                .map(rank -> new Card(suit, rank)))
                .collect(toList());
    }

아이템 46 : 스트림에서는 부작용 없는 함수를 사용하라

스트림의 핵심은 계산을 일련의 변환으로 재구성하는 것이다.

• 각 변환 단계는 이전 단계의 결과를 받아 처리하는 순수 함수
  • 순수함수 : 오직 입력만이 결과에 영향을 주는 함수

forEach는 스트림 계산 결과를 보고할 때만 사용하고 계산하는 데에는 쓰지말자.

스트림을 올바르게 사용하려면 Collector를 알아둬야한다.

• toList, toSet, toMap, groupingBy, joining ..etc

p.277 예시들을 자주 보며 익히자.

아이템 47 : 반환 타입으로는 스트림보다 컬렉션이 낫다

반환 타입으로 스트림보다 컬렉션 인터페이스를 쓴다.

원소 시퀀스를 반환하는 공개 API의 반환 타입에는 Collection이나 그 하위 타입을 쓰는 게 일반적으로 최선이다.

• Collection 인터페앗는 Iterable의 하위 타입이고, stream 메서드도 제공한다.
• 하지만, 단지 컬렉션을 반환한다는 이유로 덩치 큰 시퀀스를 메모리에 올려서는 안된다.

컬렉션을 반환하는 게 불가능하면 스트림과 Iterable 중 더 자연스러운 것을 반환하라

아이템 48 : 스트림 병렬화는 주의해서 적용하라

동시성 프로그램을 올바르게 작성하는 것은 매우 어렵다. 병렬 스트림 파이프라인 프로그래밍에서도 이는 다를바가 없다.

스트림을 잘못 병렬화하면 성능이 나빠지거나 예상치 못한 결과나 동작이 발생할 수 있다.

정말 조건만 잘 지켜지면 parallel메서드 호출 하나로 엄청난 성능 향상을 얻을 수 있긴 하다.