스트림으로 데이터 수집

우리는 이 장에서 reduce처럼 collect를 사용하여 다양한 요소 누적 방식을 인수로 받아 최종 결과를 반환하는 방법을 소개할 것이다. 다양한 요소 누적 방식은 Collector 인터페이스에 정의되어 있는데 컬렉션, 컬렉터 collect를 헷갈리지 않도록 따라와야한다.

먼저 하나 예시를 들겠다.

1. 통화별로 트랙잭션을 그룹화한 다음 해당 통화로 일어난 모든 트랙잭션 합계를 계산
2. 트랜잭션을 비싼 트랜잭션과 저렴한 트랜잭션 두 그룹으로 분류
3. 트랜잭션을 도시 등 다수준으로 그룹화하시오. 그리고 각 트랜잭션이 비싼지 저렴한지 구분하시오

다음은 자바 8 이전 코드로 작성한 코드이다.

Map<Currency, List<Transcation>> transactionsByCurrencies = new HashMap<>();

        for (Transaction transaction : transactions) {
            Currency currency = transaction.getCurrency();
            List<Transcation> transactionsForCurrency = transactionsByCurrencies.get(currency);
            if(transactionsForCurrency == null){
                transactionsForCurrency = new ArrayList<>();
                transactionsByCurrencies.put(currency, transactionsForCurrency);
            }
            transactionsForCurrency.add(transaction);
        }

트랜잭션의 리스트를 반복하여 부른 후 같은 통화를 가진 트랜잭션 리스트에 현재 탐색 중인 트랜잭션을 추가한다.
만약 현재 같은 통화가 없으면 새로운 항목을 만든다.

위의 코드는 한눈에 알아보기도 어렵고 구현하기도 어렵다. 이를 collect 메서드를 활용하여 원하는 연산을 더욱 간결하게 구현할 수 있다.

Map<Currency, List<Transaction>> transactionsByCurrencies =
 transactions.stream().collect(groupingBy(Transaction::getCurrency));

앞선 코드와 비교했을 때 한눈에 알아보기도 쉽고 코드 또한 짧아 졌다.

컬렉터란 무엇인가?

앞선 예제를 보면 명령형 프로그래밍에 비해 함수형 프로그래밍이 얼마나 편리한지 명확하게 보여주고 있다.
예제에서 collect 메서드로 Collector 인터페이스 구현을 전달했다. Collector 인터페이스 구현은 스트림의 요소를 어떤 식으로 도출할지 지정한다. 이번에 볼 메서드는 groupingBy 메서드로 이를 이용하여, 각 키와 각 키에 대응하는 요소 리스트를 값으로 포함하여 맵을 만들어 낼 것이다.

미리 정의된 컬렉터

컬렉터에서 미리 정의된 groupingBy와 같은 Collectors 클래스에서 제공하는 팩토리 메서드의 기능을 살펴볼 것이다.
Collectors에서 제공하는 메서드의 기능은 크게 세 가지로 구분할 수 있다.

• 스트림 요소를 하나의 값으로 리듀스하고 요약
• 요소 그룹화
• 요소 분할

리듀싱과 요약

5장에서 다룬 요리 예제를 이용하여 살펴보겠다.

첫 번째 예로 counting()이라는 팩토리 메서드가 반환하는 컬렉터로 메뉴에서 요리 수를 계산해준다.

long howManyDishs = menu.stream().collect(Collectors.counting());
->
long howManyDishs = menu.stream().count();

위의 코드처럼 불필요한 과정을 생략할 수 있다.
Collectors 클래스를 임포트를 하게되면 앞선 예제처럼 Collectors.counting()을 간단하게 counting()으로 표현할 수 있다.

스트림 값에서 최댓값 최소값 검색

만약 메뉴에서 칼로리가 가장 높은 요리를 찾는다고 가정하자. Collectors에 정의되어 있는 maxBy(), minBy()를 이용하여 최댓값 최소값을 계산할 수 있다.

Comparator<Dish> dishCaloriesComparator = Comparator.comparingInt(Dish::getCalories);

Optional<Dish> mostCalorieDish = menu.stream().collect(maxBy(dishCaloriesComparator));

요약 연산

Collectors 클래스는 스트림에 있는 객체의 숫자 필드의 합계나 평균 등을 반환하는 연산 또한 지원한다.
summingInt, averagingInt 등 합, 평균값 계산 등 여러가지 연산이 지원된다.

int totalCalories = menu.stream().collect(summingInt(Dish::getCalories));

위의 코드는 메뉴 리스트의 합계를 계산하는 코드이다. 이처럼 Collectors 또한 스트림의 리듀싱처럼 여러가지 연산을 할 수 있다.

이러한 단순 합계외에 요소 수, 최댓값 최소값, 합계와 평균을 한꺼번에 계산하여 반환해주는 summarizingInt 또한 지원해준다.

IntSummaryStatistics menuStatistics = menu.stream().collect(summarizingInt(Dish::getCalories));

위의 코드를 실행하면 IntSummaryStatistics로 모든 정보가 수집된다. menuStaticstics 객체를 출력하면 다음과 같은 정보를 확인할 수 있다.

IntSummaryStatistics { count = 9, sum=4300, min=120, average=477.777778, max=800}

앞에서는 int만 설명했지만 이와 비슷한 Double, Long에 대한 클래스도 있다.

문자열 연결

컬렉터는 스트림의 각 객체를 연결하여 하나의 문자열로 연결하는 joining 팩토리 메서드를 지원한다.

String shortMenu = menu.stream().map(Dish::getName).collect(joining(", "));

위의 코드는 각 객체를 , 로 연결해주는 코드이다.

범용 리듀싱 요약 연산

지금까지 살펴본 모든 컬렉터는 reducing 팩토리 메서드로도 정의할 수 있다. 즉, 범용 Collectors.reducing으로도 구현할 수 있다.

int totalCalories = menu.stream().collect(reducing(0, Dish::getCalories, (i, j) -> i + j));

위의 코드는 reducing 메서드로 만들어진 컬렉터로 메뉴의 모든 칼로리 합계를 계산할 수 있다.
reducing은 인수 세 개를 받는다.

1. 첫 번째 인수는 리듀싱 연산의 시작값이거나 스트림에 인수가 없을 때는 반환값이다.
2. 두 번째 인수는 요리를 칼로리 정수로 변환할 때 사용한 변환 함수다.
3. 세 번째 인수는 같은 종류의 두 항목을 하나의 값으로 더하는 BinaryOperator다. 예제에서는 두 개의 int가 사용되었다.

그룹화

맨 처음 보았던 통화 그룹화 예제에서 확인 했듯이 명령형 프로그래밍으로 그룹화를 구현하려면 까다롭고, 할일이 많으며, 에러도 많이 발생한다. 하지만 자바 8의 함수형을 이용하면 가독성 있는 한 줄의 코드로 그룹화를 구현할 수 있다.

이번 코드는 요리를 고기, 생선, 나머지 그룹으로 그룹화하는 코드이다.

Map<Dish.Type, List<Dish>> dishesByType = menu.stream().collect(groupingBy(Dish::getType));
// result
{FISH =[prawns, salmon], OTHER={french fries, rice, season fruit, pizza], MEAT=[pork, beef, chicken]}

이처럼 groupingBy를 사용하여 원하는 그룹으로 분류할 수 있다. 따라서 이를 분류 함수라고 부른다.

위처럼 단순 속성 접근자 대신 더 복잡한 분류 기준이 필요한 상황에서는 메서드 참조를 사용할 수 없다.
다음은 400 칼로리 이하를 diet로 400~ 700칼로리를 normal로, 700 칼로리 초과를 fat 요리로 분류한다고 가정한다.
이 분류 기준을 메서드 참조대신 람다 표현식으로 나타낼 수 있다.

public enumCaloricLevel { DIET, NORMAL, FAT}

        Map<CaloricLevel, List<Dish>> dishesByCaloricLevel = menu.stream().collect(groupingBy(dish->{
            if(dish.getCalories() <= 400) return CaloricLevel.DIET;
            else if(dish.getCalories() <= 700) return CaloricLevel.NORMAL;
            else return CaloricLevel.FAT;
        }));

그룹화된 요소 조작

앞선 예제를 통해 groupBy 메서드를 이용하여 한 가지 기준으로 그룹화하는 방법을 살펴보았다. 그렇다면 2가지 이상의 기준으로 그룹화할 수 있을까?

우선 스트림의 filter 메서드를 사용하면 될 것이라고 생각할 수 있다.

Map<Dish.Type, List<Dish>> caloricDishesByType = 
                menu.stream().filter(dish -> dish.getCalories() > 500)
                             .collect(groupingBy(Dish::getType));

위 코드로 문제를 해결할 수 있지만 단점이 존재한다.
{ OTHER=[french fries, pizza], MEAT=[pork, beef]}
문제가 무엇인지 발견했는가? FISH는 filter를 만족하는 요소가 없으므로 FISH 항목이 아예 빠져있다.
이를 해결하기 위해 Collectors 클래스는 groupingBy 팩토리 메서드의 두 번째 인수를 갖는 오버로딩을 사용한다.

Map<Dish.Type, List<Dish>> caloricDishesByType =
        menu.stream()
            .collect(groupingBy(Dish::getType,
                    filtering(dish -> dish.getCalories() > 500, toList())));

// result
{OTHER=[french fries, pizza], MEAT=[pork, beef], FISH=[]}

결과를 보면 알수 있듯이 목록이 비어있는 FISH도 항목으로 추가된다.

다수준 그룹화

두 인수를 받는 팩토리 메서드 Collectors.groupingBy를 이용해서 항목을 다수준으로 그룹화할 수 있다. Collectors.groupingBy는 일반적인 분류 함수와 컬렉터를 인수로 받는다. 즉, 두 가지 기준으로 항목을 그룹화할 수 있다.

Map<Dish.Type, Map<CaloricLevel, List<Dish>>> dishesByTypeCaloricLevel =
                menu.stream().collect(
                        groupingBy(Dish::getType,
                                groupingBy(dish -> {
                                    if(dish.getCalories() <= 400)
                                        return CaloricLevel.DIET;
                                    else if(dish.getCalories() <= 700)
                                        return CaloricLevel.NORMAL;
                                    else
                                        return CaloricLevel.FAT;
                                })
                        })
                );

그룹화 결과로 다음과 같은 두 수준의 맵이 만들어 진다.

{MEAT={DIET=[chicken], NORMAL=[beef], FAT=[pork]}, FISH={DIET=[prawns], NORMAL=[salmon]},
OTHER={DIET=[rice, sasonal fruit], NORMAL=[french fries, pizza]}}

첫 번째 분류 함수에서는 fish, meat, other를 기준으로, 두 번째는 normal, diet, fat을 기준으로 그룹화 된다.

서브그룹으로 데이터 수집

groupingBy 컬렉터에 두 번째 인수로 counting 컬렉터를 전달해서 메뉴에서 요리 수를 종류별로 계산할 수 있다.

Map<Dish.Type, Long> typesCount = menu.stream().collect(groupingBy(Dish::getType, counting()));
// result
{MEAT=3, FISH=2, OTHER=4}

분류 함수 한 개의 인수를 갖는 groupingBy(f)는 사실 groupingBy(f, toList())의 축약형이다.

컬렉터 결과를 다른 형식에 적용하기

마지막 그룹화 연산에서 맵의 모든 값을 Optional로 감쌀 필요가 없으므로 Optional을 삭제할 수 있다. 즉, 다음처럼 팩토리 메서드 Collectros.collectingAndThen으로 컬렉터가 반환한 결과를 다른 형식으로 활용할 수 있다.

Map<Dish.Type, Dish> mostCaloricByType =
                menu.stream()
                    .collect(groupingBy(Dish::getType,
                            collectingAndThen(
                                    maxBy(comparingInt(Dish::getCalories)), 
                            Optional::get)));

팩토리 메서드 collectingAndThen은 적용할 컬렉터와 변환 함수를 인수로 받아 다른 컬렉터를 반환한다.

분할

분할은 분할 함수라 불리는 프레디 케이트를 분류 함수로 사용하는 특수한 그룹화 기능이다. 분할 함수는 불리언을 반환하므로 맵의 키 형식은 Boolean이다. 결과적으로 그룹화 맵은 최대 (true or false) 두 개의 그룹으로 분류된다.
예를 들어 채식인 요리와 아닌 요리로 구분하고 싶다면 다음과 같은 코드를 사용하면된다.

Map<Boolean, List<Dish>> partitioneMenu = menu.stream().collect(partitioningBy(Dish::isVegetarina));
// result
{false=[pork, beef, chicken, prawns, salmon],
true=[french fries, rice, season fruit, pizza]}

이제 참값의 키로 맵에서 모든 채식 요리를 얻을 수 있다.

List<Dish> vegetarianDishes = partitionedMenu.get(true);

Collector 인터페이스

이번 장에서는 Collector 인터페이스를 직접 구현해서 더 효율적으로 문제를 해결하는 컬렉터를 만드는 방법을 살펴본다.

public interface Collector<T, A, R> {
            Supplier<A> supplier();
            BiConsumer<A, T> accumulator();
            Function<A, R> finisher();
            BinaryOperator<A> combiner();
            Set<Characteristics> characteristics();
        }

위의 코드는 Collector 인터페이스의 시그니처와 다섯 개의 메서드 정의를 보여준다. 이것은 다음처럼 설명할 수 있다.

• T는 수집될 스트림 항목의 제네릭 형식이다.
• A는 누적자, 즉 수집 과정에서 중간 결과를 누적하는 객체의 형식이다.
• R은 수집 연산 결과 객체의 형식(항상 그런 것은 아니지만 대개 컬렉션 형식)이다.

이 Collector 인터페이스의 5가지 메서드를 하나씩 살펴보자. 먼저 살펴볼 네 개의 메서드는 collect 메서드에서 실행하는 함수를 반환하는 반면, 다섯 번째 메서드 characteristics는 collect 메서드가 어떤 최적화를 이용해서 리듀싱 연산을 수행할 것인지 결정하도록 돕는 힌트 특성 집합을 제공한다.

• supplier 메서드 : 새로운 결과 컨테이너 만들기
• accumulator 메서드 : 결과 컨테이너에 요소 추가하기
• finisher 메서드 : 최종 변환값을 결과 컨테이너로 적용하기
• combiner 메서드 : 두 결과 컨테이너 병합
• Characteristics 메서드 : 컬렉터의 연산을 정의하는 Characteristics 형식의 불변 집합을 반환한다.

이를 이용하여 커스텀 컬렉터를 개발할 수 있다.

마치며

• collect는 스트림의 요소를 요약 결과로 누적하는 다양한 방법(컬렉터라 불리는)을 인수로 갖는 최종 연산이다.
• 스트림의 요소를 하나의 값으로 리듀스하고 요약하는 컬렉터뿐 아니라 최솟값, 최대값, 평균값을 계산하는 컬렉터 등이 미리 정의되어 있다.
• 미리 정의된 컬렉터인 groupingBy로 스트림의 요소를 그룹화하거나, partitioningBy로 스트림의 요소를 분할할 수 있다.
• 컬렉터는 다수준의 그룹화, 분할, 리듀싱 연산에 적합하게 설계되어 있다.
• Collector 인터페이스에 정의된 메서드를 구현해서 커스텀 컬렉터를 개발할 수 있다.

람다 표현식

람다란 무엇인가?

람다 표현식은 메서드로 전달할 수 있는 익명 함수를 단순화한 것이라고 할 수 있다.

람다 특징

• 익명 - 보통의 메서드와 달리 이름이 없으므로 익명이라 표현한다. 구현해야 할 코드에 대한 걱정거리가 줄어든다.
• 함수 - 람다는 메서드처럼 특정 클래스에 종속되지 않으므로 함수라고 부른다. 하지만 메서드처럼 파라미터 리스트, 바디, 반환 형식, 가능한 예외 리스트를 포함한다.
• 전달 - 람다 표현식을 메소드 인수로 전달하거나 변수로 저장할 수 있다.
• 간결성 - 익명 클래스처럼 많은 자질구레한 코드를 구현할 필요가 없다.

람다 표현식을 사용함으로써 앞서 2장에서 본 자질구레한 코드들을 간결하게 줄일 수 있다.

Comparator<Apple> byWeight = new Comparator<Apple>(){
            public int compare(Apple a1, Apple a2) {
                return a1.getWeight().compareTo(a2.getWeight());
            }
        };

Comparator<Apple> byWeight = (Apple a1, Apple a2) -> a1.getWeight().compareTo(a2.getWeight());

위의 두 코드를 비교하면 확실히 간결해 진것을 알 수 있다. 우리는 이런 비용과 가독성 등 여러가지 이득을 위해 람다를 꼭 공부해야한다.

람다 표현식은 아래 코드처럼 화살표를 기준으로 파라미터, 화살표, 바디로 이루어진다.

(Apple a1, Apple a2) -> a1.getWeight().compareTo(a2.getWeight());

람다 표현식은 어디에 사용하는가?

List<Apple> greenApples = filter(inventory, (Apple a) -> GREEN.equals(a.getColor()));

람다 표현식을 배웠으니 우리는 이를 써먹어야한다. 람다 표현식은 어디에, 어떻게 사용할 수 있는가? 앞서 공부한 2장에서 구현했던 필터 메서드에도 람다를 활용할 수 있었다. 또한 이제 소개할 함수형 인터페이스라는 문맥에서 람다 표현식을 사용할 수 있다. 위의 예제에서는 함수형 인터페이스 Predicate를 기대하는 filter 메서드의 두 번째 인수로 람다 표현식을 전달한 것을 확인할 수 있다. 그렇다면 함수형 인터페이스는 무엇일까?

함수형 인터페이스

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

2장에서 만든 Predicate 인터페이스를 통해 사과의 색깔, 무게를 필터링할 수 있었다. 바로 이 Predicate가 함수형 인터페이스이다. 간단히 말해 함수형 인터페이스는 정확히 하나의 추상 메서드를 지정하는 인터페이스다.
함수형 인터페이스를 알아보았으니 이것을 가지고 무엇을 할 수 있을까? 앞서 언급한 람다 표현식으로 함수형 인터페이스의 추상 메서드 구현을 직접 전달할 수 있으므로 전체 표현식을 함수형 인터페이스의 인스턴스로 취급할 수 있다. 이와 비슷하게 조금 덜 깔끔하지만 익명 내부 클래스로도 같은 기능을 구현할 수 있다.

람다 활용 : 실행 어라운드 패턴

자원 처리에 사용하는 순환 패턴은 자원을 열고, 처리한 다음, 자원을 닫는 순서로 이루어진다. 설정과 정리 과정은 대부분 비슷하다. 즉, 실제 자원을 처리하는 코드를 설정과 정리 두 과정이 둘러싸는 형태를 갖는다. 이러한 것을 실행 어라운드 패턴이라고 부른다.

함수형 인터페이스 사용

자바 8 라이브러리 설계자들은 java.util.function 패키지로 여러 가지 새로운 함수형 인터페이스를 제공한다.

표에 나타난 3가지 이외에도 자바 8 이후에서는 Supplier, UnaryOperator 등 여러 가지 함수형 인터페이스를 제공한다.

메서드 참조

메서드 참조를 이용하면 기존의 메서드 정의를 재활용해서 람다처럼 전달할 수 있다. 이번 우테코에서 미션들을 진행하면서 LottoGenerate::Lotto 와 같은 메서드들을 접하였는데 책에서 접하니 더 이해하기 쉽고 친숙했다.
그렇다면 이 메서드 참조는 왜 중요할까? 메서드 참조는 특정 메서드만을 호출하는 람다의 축약형이라고 생각할 수 있다. 이때 명시적으로 메서드명을 참조함으로써 가독성을 높일 수 있다. 메서드 참조는 앞서 언급했던 것처럼 메서드명 앞에 구분자(::)를 뭍이는 방식으로 메서드 참조를 활용할 수 있다. 예를 하나 더 들자면 Apple::getWeight는 Apple 클래스에 정의된 getWeight의 메서드 참조다. 이것은 람다 표현식 (Apple a) -> a.getWeight()를 축약한 것이다.

메서드 참조를 만드는 방법

메서드 참조는 세 가지 유형으로 구분할 수 있다.

1. 정적 메서드 참조 - Integer의 parseInt 메서드는 Integer::parseInt로 표현할 수 있다.
2. 다양한 형식의 인스턴스 메서드 참조 - String의 length 메서드는 String::length로 표현할 수 있다.
3. 기존 객체의 인스턴스 메서드 참조 - Transcation 객체를 할당받은 expensiveTranscation 지역 변수가 있고, Transcation 객체에는 getValue 메서드가 있다면, 이를 expensiveTransaction::getValue라고 표현할 수 있다.

책에서는 3가지로 구분하였지만 쓰는 방식은 비슷한 것 같다.
기존의 메서드 구현을 재활용해서 메서드 참조를 만드는 방법을 살펴 보았는데, 클래스의 생성자를 이용하는 방법도 있다.

생성자 참조

ClassName::new처럼 클래스명과 new 키워드를 이용해서 기존 생성자의 참조를 만들 수 있다.

Supplier<Apple> c1 = () -> new Apple();
Apple a1 = c1.get();

Supplier<Apple> c1 = Apple::new;
Apple a1 = c1.get();

위의 코드처럼 람다 표현식을 생성자 참조로 바꿀 수 있다.

람다, 메서드 참조 활용하기

앞서 배운 람다 표현식과 메서드 참조를 활용하여 사과 리스트 정렬 문제를 간단한 코드로 만들 수 있다.

1단계 : 코드 전달

        public class AppleComparator implements Comparator<Apple> {
            public int compare(Apple a1, Apple a2) {
                return a1.getWeight.compareTo(a2.getWeight());
            }
        }
        inventory.sort(new AppleComparator());

sort 메서드는 다음과 같다 .
void sort(Comparator<? super E> c)
이 메서드는 Comparator 객체를 인수로 받아 두 대상을 비교한다. 이 sort를 활용하여 1단계 코드를 완성 시킨 것을 볼 수 있다.

2단계 : 익명 클래스 사용

한 번만 사용할 Comparator를 1단계 처럼 구현하는 것 보다는 익명 클래스를 이용하는 것이 좋다.

        inventroy.sort(new Comparator<Apple>()){
            public int compare(Apple a1, Apple a2){
                return a1.getWeight().compareTo(a2.getWeight());
            }
        }

3단계 : 람다 표현식 사용

2단계 코드는 아직 코드의 부피가 커다란 편이다. 앞서 배운 람다를 활용하여 코드를 더욱 간단히 리펙토링 할 수 있다.

inventory.sort(comparing(apple -> apple.getWeight()));

4단계 : 메서드 참조 사용

마지막으로 메서드 참조를 활용하면 더 깔끔하게 전달할 수 있다.

inventory.sort(comparing(Apple::getWeight));

코드의 길이도 짧아지고 코드의 의미 또한 명확해진 것을 볼 수 있다. 코드 자체로 'Apple을 weight별로 비교해서 inventory에 sort하라'라는 의미를 전달할 수 있다. 1단계와 비교해보면 엄청난 변화가 이루어 진 것을 확인할 수 있다.

람다 표현식 정리

• 람다 표현식은 익명 함수의 일종이다. 이름은 없지만, 파라미터 리스트, 바디, 반환 형식을 가지며 예외를 던질 수 있다
• 람다 표현식으로 간결한 코드를 구현할 수 있다.
• 함수형 인터페이스는 하나의 추상 메서드만을 정의하는 인터페이스다.
• 함수형 인터페이스를 기대하는 곳에서만 람다 표현식을 사용할 수 있다.
• 람다 표현식을 이용해서 함수형 인터페이스의 추상 메서드를 즉석으로 제공할 수 있으며 람다 표현식 전체가 함수형 인터페이스의 인스턴스로 취급된다.
• java.util.function 패키지는 Predicate, Function<T, R>, Supplier, Consumer, BinaryOperator 등을 포함해서 자주 사용하는 다양한 함수형 인터페이스를 제공한다.
• 자바 8은 Predicate와 Function<T, R> 같은 제네릭 함수형 인터페이스와 관련한 박싱 동작을 피할 수 있는 IntPredicate, IntToLongFunction 등과 같은 기본형 특화 인터페이스도 제공한다.
• 실행 어라운드 패턴을 람다와 활용하면 유연성과 재사용성을 추가로 얻을 수 있다.
• 람다 표현식의 기대 형식을 대상 형식이라고한다.
• 메서드 참조를 이용하면 기존의 메서드 구현을 재사용하고 직접 전달할 수 있다.
• Comparator, Predicate, Function 같은 함수형 인터페이스는 람다 표현식을 조합할 수 있는 다양한 디폴트 메서드를 제공한다.

병렬 데이터 처리와 성능

4~6장에서는 새로운 스트림 인터페이스를 이용해서 데이터 컬렉션을 선언형으로 제어하는 방법을 살펴보았다. 우리는 이제 속도와 성능을 생각해야한다. 그 해답은 병렬에 있다.

자바 7이 등장하기 이전 데이터 컬렉션을 병렬로 처리하기 어려웠다. 우선 데이터를 서브파트로 분할하고 스레드를 할당하고 race condition이 발생하지 않도록 동기화를 추가하며 마지막으로 부분 결과를 합쳐야한다. 이 얼마나 어려운가!
자바 7은 더 쉽게 병렬화를 수행하면서 에러를 최소화할 수 있도록 포크/조인 프레임워크 기능을 제공한다.

포크/조인 프레임워크를 소개하기 전 우리 장의 핵심인 스트림으로 데이터 컬렉션 관련 동작을 얼마나 쉽게 병렬로 실행할 수 있는지 설명한다. 스트림을 이용하면 순차 스트림을 병렬 스트림으로 자연스럽게 바꿀 수 있다.

병렬 스트림

우선 병렬 스트림을 생성하려면 간단히 컬렉션에 parallelStream을 호출하면 된다. 이 얼마나 간단한가!
병렬 스트림이 무엇인지 모르는 사람들을 위해 간단히 설명하자면 각각의 스레드에서 처리할 수 있도록 스트림 요소를 여러 청크로 분할한 스트림이다. 따라서 병렬 스트림을 이용하면 모든 멀티코어 프로세서가 각각의 청크를 처리하도록 할당할 수 있다.

    public long parallelSum(long n) {
        return Stream.iterate(1l, i -> i + 1)
                .limit(n)
                .parallel()
                .reduce(0L, Long::sum);
    }

1부터 n까지 모든 숫자를 더하는 메서드이다. 병렬로 처리하기 위해 중간에 parallel를 볼 수 있다.
반대로 sequential을 사용하면 병렬 스트림을 순차 스트림으로 바꿀 수 있다.
이 두 메서드를 이용해서 어떤 연산을 병렬로 실행하고 어떤 연산을 순차로 실행할지 제어할 수 있다.
parallel과 sequential 두 메서드 중 최종적으로 호출된 메서드가 전체 파이프라인에 영향을 미친다.

스트림 성능 측정

병렬화를 왜 사용할까? 당연히 성능, 속도 때문이 아닐까라고 생각한다.
무조건 병렬화를 사용하면 성능이 좋아질까? 이러한 생각은 위험한 생각이다.
그렇다면 어떨때 병렬화를 사용하고, 순차를 사용할까? 직접 속도를 측정하여 빠른 것을 사용하면 된다!
iterate를 이용해서 1부터 n까지 더하는 예제를 보자
실제로 병렬화를 사용한 것보다 순차적으로 계산한 방법이 약 5배 빨랐다. 왜 이런 결과가 나온 것일까?
우리는 Iterate에 집중해야한다. iterate로 숫자를 생성하면 하나씩 생산하므로 전체 숫자를 한꺼번에 받아 나누어 처리하는 병렬방식이 더 느린 것이다.
이처럼 병렬 프로그래밍은 까다롭고 때로는 이해하기 어려운 함정이 숨어있다. 심지어 병렬 프로그래밍을 잘못 사용하면 오히려 전체 프로그램의 성능이 더 나빠질 수도 있다. 따라서 parallel 메서드를 호출했을 때 내부적으로 어떤 일이 일어나는지 꼭 이해해야한다.

병렬 스트림 효과적으로 사용하기

• 확신이 서지 않으면 직접 측정하라. 순차 스트림을 병렬 스트림으로 쉽게 바꿀 수 있다. 하지만 무조건 병렬 스트림으로 바꾸는 것이 능사는 아니다. 이미 살펴본 것 처럼 언제나 병렬 스트림이 순차 스트림보다 빠른 것은 아니기 때문이다. 더욱이 병렬 스트림의 수행 과정은 투명하지 않을 때가 많다. 따라서 순차 스트림과 병렬 스트림 중 어떤 것이 좋을 지 모르겠다면 적절한 벤치마크로 직접 성능을 측정하는 것이 바람직하다.
• 박싱을 주의하라. 자동 박싱과 언박싱은 성능을 크게 저하시킬 수 있는 요소다.
• 순차 스트림보다 병렬 스트림에서 성능이 떨어지는 연산이 있다. 특히 limit나 findFirst처럼 요소의 순서에 의존하는 연산을 병렬 스트림에서 수행하려면 비싼 비용을 치러야 한다.
• 스트림에서 수행하는 전체 파이프라인 연산 비용을 고려하라. 처리해야 할 요소 수가 N이고 하나의 요소를 처리하는데 드는 비용을 Q라 하면 전체 스트림 파이프라인 처리 비용을 N*Q로 예상할 수 있다. Q 가 높아진다는 것은 병렬 스트림으로 성능을 개선할 수 있는 가능성이 있음을 의미한다.
• 소량의 데이터에서는 병렬 스트림이 도움이 되지 않는다.
• 스트림을 구성하는 자료구조가 적절한지 확인하라. 예를 들어 ArrayList를 LinkedList보다 효율적으로 분할할 수 있다.
• 스트림의 특성과 파이프라인의 중간 연산이 스트림의 특성을 어떻게 바꾸는지에 따라 분해 과정의 성능이 달라질 수 있다. 예를 들어 SIZED 스트림은 정확히 같은 크기의 두 스트림으로 분할할 수 있으므로 효과적으로 스트림을 병렬 처리할 수 있다. 반면 필터 연산이 있으면 스트림의 길이를 예측할 수 없으므로 효과적으로 스트림을 병렬 처리할 수 있을지 알 수 없게 된다.
• 최종 연산의 병합 과정 비용을 살펴보라.
• 병렬 스트림과 병렬 계산에서 공유된 가변 상태를 피해야 한다. 이는 성능의 문제가 아니라 완전히 다른 값이 나올 수 있다.

포크/조인 프레임 워크

Spliterator 스트림 데이터 쪼개기

마치며

• 내부 반복을 이용하면 명시적으로 다른 스레드를 사용하지 않고도 스트림을 병렬로 처리할 수 있다.
• 간단하게 스트림을 병렬로 처리할 수 있지만 항상 병렬 처리가 빠른 것은 아니다. 병렬 소프트웨어 동작 방법과 성능은 직관적이 않을 때가 많으므로 병렬 처리를 사용했을 때 성능을 직접 측정해봐야한다.
• 병렬 스트림으로 데이터 집합을 병렬 실행할 때 특히 처리해야 할 데이터가 아주 많거나 각 요소를 처리하는 데 오랜 시간이 걸릴 때 성능을 높일 수 있다.
• 가능하면 기본형 특화 스트림을 사용하는 등 올바른 자료구조 선택이 어떤 연산을 병렬로 처리하는 것보다 성능적으로 더 큰 영향을 미칠 수 있다.
• 포크/조인 프레임 워크에서는 병렬화할 수 있는 태스크를 작은 태스크로 분할한 다음에 분할된 태스크를 각각의 스레드로 실행하며 서브태스크 각각의 겨로가를 합쳐서 최종 결과를 생산한다.
• Spliterator는 탐색하려는 데이터를 포함하는 스트림을 어떻게 병렬화할 것인지 정의한다.

스트림 소개

스트림이란 무엇인가?

스트림은 자바 8 API에 새로 추가된 기능이다. 스트림을 이용하면 선언형으로 컬렉션 데이터를 처리할 수 있다. 먼저 자바 7 코드와 자바 8 코드를 비교해보자.

List<Dish> lowCaloricDishes = new ArrayList<>();
        for (Dish dish : menu) {
            if (dish.getCalories() < 400) {
                lowCaloricDishes.add(dish);
            }
        }
        Collections.sort(lowCaloricDishes, new Comparator<Dish>() {
            public int compare(Dish dish1, Dish dish2) {
                return Integer.compare(dish1.getCalories, dish2.getCalories());
            }
        });
        List<String> lowCaloricDishesName = new ArrayList<>();
        for (Dish dish : lowCaloricDishes) {
            lowCaloricDishesName.add(dish.getName());
        }

List<String> lowCaloricDishesName = 
                menu.stream()
                    .filter(d -> d.getCalories() < 400)
                    .sorted(comparing(Dish::getCalories))
                    .map(Dish::getName)
                    .collect(toList());

칼로리가 400 이하인 음식들을 구하는 코드를 자바 컬렉션과 스트림 두가지 방법으로 구현한 것이다.

자바 8의 스트림 API의 특징

• 선언형 : 더 간결하고 가독성이 좋아진다.
• 조립할 수 있음 : 유연성이 좋아진다.
• 병렬화 : 성능이 좋아진다.

스트림 시작하기

스트림이란 정확히 무엇일까? 스트림이란 '데이터 처리 연산을 지원하도록 소스에서 추출된 연속된 요소'로 정의할 수 있다. 정의에 나와있는 단어를 하나씩 살펴보자

스트림 정의 살펴보기

• 연속된 요소 : 컬렉션과 마찬가지로 스트림은 특정 요소 형식으로 이루어진 연속된 값 집합의 인터페이스를 제공한다. 컬렉션은 자료구조이므로 컬렉션에서는 시간과 공간의 복잡성과 관련된 요소 저장 및 접근 연산이 주를 이룬다. 반면 스트림은 filter, sorted, map처럼 표현 계산식이 주를 이룬다. 즉, 컬렉션의 주제는 데이터고 스트림의 주제는 계산이다.
• 소스 : 스트림은 컬렉션, 배열, I/O 자원 등의 데이터 제공 소스로부터 데이터를 소비한다. 정렬된 컬렉션으로 스트림을 생성하면 정렬이 그대로 유지된다. 즉, 리스트로 스트림을 만들면 스트림의 요소는 리스트의 요소와 같은 순서를 유지한다.
• 데이터 처리 연산 : 스트림은 함수형 프로그래밍 언어에서 일반적으로 지원하는 연산과 데이터베이스와 비슷한 연산을 지원한다. 예를 들어 filter, map, reduce, find, match, sort 등으로 데이터를 조작할 수 있다. 스트림 연산은 순차적으로 또는 병렬로 실행할 수 있다.

스트림 특징

• 파이프라이닝 : 대부분 스트림 연산은 스트림 연산끼리 연결해서 커다란 파이프라인을 구성할 수 있도록 스트림 자신을 반환한다. 그 덕분에 게으름, 쇼트서킷 같은 최적화도 얻을 수 있다. 연산 파이프라인은 데이터 소스에 적용하는 데이터베이스 질의와 비슷하다.
• 내부 반복 : 반복자를 이용해서 명시적으로 반복하는 컬렉션과 달리 스트림은 내부 반복을 지원한다.

아래 예제 코드를 통해 스트림의 정의와 특징을 다시 한번 살펴보자

List<String> threeHighCaloricDishNames =
                menu.stream()
                    .filter(dish -> dish.getCalories() > 300)
                    .map(Dish::getName)
                    .limit(3)
                    .collect(toList());

우선 요리 리스트를 포함하는 menu에 stream 메서드를 호출해서 스트림을 얻었다. 여기서 데이터 소스는 요리 리스트(메뉴)이다. 데이터 소스는 연속된 요소를 스트림에 제공한다. 다음으로 스트림에 filter, map, limit, collect로 이어지는 일련의 데이터 처리 연산을 적용한다. collect를 제외한 모든 연산은 서로 파이프라인을 형성할 수 있도록 스트림을 반환한다.

스트림과 컬렉션

예제 코드를 통해 스트림을 알아보았다. 그렇다면 스트림과 컬렉션은 무엇이 다른 것일까?
그것은 데이터를 언제 계산하느냐가 컬렉션과 스트림의 가장 큰 차이다. 컬렉션은 현재 자료구조가 포함하는 모든 값을 메모리에 저장하는 자료구조다. 즉, 컬렉션의 모든 요소는 컬렉션에 추가하기 전에 계산되어야 한다.
반면 스트림은 이론적으로 요청할 때만 요소를 계산하는 고정된 자료구조다.
또한 스트림은 사용자가 데이터를 요청할 때만 값을 계산하고, 컬렉션은 모든 데이터를 수집한 후(팔기도 전에 창고를 가득 채움) 사용자에게 알린다.

외부 반복과 내부 반복

컬렉션과 스트림의 또다른 차이점은 데이터 반복 처리 방법이다.
컬렉션 인터페이스를 사용하려면 사용자가 직접 요소를 반복해야 한다. 이를 외부 반복이라고 한다. 반면 스트림 라이브러리는 내부 반복을 사용한다.

스트림 연산

List<String> threeHighCaloricDishNames =
                menu.stream()
                    .filter(dish -> dish.getCalories() > 300)
                    .map(Dish::getName)
                    .limit(3)
                    .collect(toList());

위의 코드에서 연산을 두 그룹으로 구분할 수 있다.

• filter, map, limit는 서로 연결되어 파이프라인을 형성한다.
• collect로 파이프라인을 실행한 다음에 닫는다.

연결할 수 있는 스트림 연산을 중간 연산이라고 하며, 스트림을 닫는 연산을 최종 연산이라고 한다. 중간 연산과 최종 연산은 스트림에서 중요한 구분이다.

중간 연산

중간 연산은 filter나 sorted같은 연산이며 다른 스트림을 반환한다. 따라서 여러 중간 연산을 연결해서 질의를 만들 수 있다. 중간연산의 중요한 특징은 단말 연산을 스트림 파이프라인에 실행하기 전까지는 아무 연산도 수행하지 않는다는 것, 즉 게으르다는 것이다.

최종 연산

최종 연산은 스트림 파이프라인에서 결과를 도출한다. 보통 최종 연산에 의해 List, Integer, void 등 스트림 이외의 결과가 반환된다.

마치며

• 스트림은 소스에서 추출된 연속 요소로, 데이터 처리 연산을 지원한다.
• 스트림은 내부 반복을 지원한다. 내부 반복은 filter, map, sorted 등의 연산으로 반복을 추상화한다.
• 스트림에는 중간 연산과 최종 연산이 있다.
• 중간 연산은 filter와 map처럼 스트림을 반환하면서 다른 연산과 연결되는 연산이다. 중간 연산을 이용해서 파이프라인을 구성할 수 있지만 중간 연산으로는 어떤 결과도 생성할 수 없다.
• forEach나 count처럼 스트림 파이프라인을 처리해서 스트림이 아닌 결과를 반환하는 연산을 최종 연산이라고 한다.
• 스트림 요소는 요청할 때 게으르게 계산된다.

스트림 활용

스트림 API는 필터링, 슬라이싱, 매핑, 검색, 매칭, 리듀싱 등 다양한 방식으로 데이터 처리를 할 수 있다. 이번 챕터에서는 스트림의 다양한 연산들을 살펴보고 직접 사용하며 공부할 것이다.

필터링

스트림 인터페이스는 filter 메서드를 지원한다. filter 메서드는 프레디케이트를 인수로 받아 프레디케이트와 일치하는 모든 요소를 포함하는 스트림을 반환한다.

List<Dish> vegetarianMenu = menu.stream().filter(Dish::isVegetarian).collect(toList());

위의 코드처럼 모든 채식요리를 필터링해서 채식 메뉴를 만들 수 있다.

고유 요소 필터링 (중복 제거)

스트림은 고유 요소로 이루어진 스트림을 반환하는 distinct 메서드도 지원한다.

List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5, 6);
        numbers.stream().filter(i -> i % 2 ==0).distinct().forEach(System.out::println);

위의 코드는 리스트의 모든 짝수를 선택하고 중복을 필터링한다.

스트림 슬라이싱

자바 9에서는 스트림 요소를 효과적으로 선택할 수 있도록 takeWhile, dropWhile 두 가지 새로운 메서드를 지원한다.

TAKEWHILE 활용

만약 메뉴에서 320 칼로리 이하의 요리를 선택하고 싶다면 filter를 사용할 수 있다. 하지만 이 방법은 전체 스트림을 반복하면서 각 요소에 프레디케이트를 적용하게 된다. 만약 List가 정렬되어 있다면, filter 대신 takeWhile 연산을 이용하여 처리할 수 있다.

List<Dish> slicedMenu1 = specialMenu.stream().takeWhile(dish -> dish.getCalories() < 320).collect(toList());

위의 코드처럼 takeWhile을 사용하여 320 칼로리가 넘는 요리가 나온다면 반복 작업을 중단한다.
그렇다면 나머지 요소들은 어떻게 반환할 수 있을까?

List<Dish> slicedMenu2 = specialMenu.stream().dropWhile(dish -> dish.getCalories() < 320).collect(toList());

dropWhile을 사용하게되면 반대 작업을 할 수 있다.

스트림 축소

스트림은 주어진 값 이하의 크기를 갖는 새로운 스트림을 반환하는 limit(n) 메서드를 지원한다. 다음 코드는 300칼로리 이상의 세 요리를 선택해서 리스트를 반환하는 코드이다.

List<Dish> dishes = specialMenu.stream().filter(dish -> dish.getCalories() > 300).limit(3).collect(toList());

요소 건너뛰기

스트림은 처음 n개 요소를 제외한 스트림을 반환하는 skip(n) 메서드를 지원한다. 만약 n개 이하의 요소를 포함하는 스트림에 skip(n)을 호출하면 빈 스트림이 반환된다. 아래의 코드는 300칼로리 이상의 요리 중 처음 두 요리를 건너뛴 다음 300 칼로리가 넘는 나머지 요리를 반환한다.

List<Dish> dishes = menu.stream().filter(d -> d.getCalories() > 300).skip(2).collect(toList());

매핑

스트림의 각 요소에 함수 적용하기

스트림은 함수를 인수로 받는 map 메서드를 지원한다. 인수로 제공된 함수는 각 요소에 적용되며 함수를 적용한 결과가 새로운 요소로 매핑된다. map메서드 끼리 연결 할 수 있다.

List<String> dishNames = menu.stream().map(Dish::getName).collect(toList());

위의 코드처럼 map 메서드를 통해 요리의 이름을 추출할 수 있다.

스트림 평면화(flatMap)

flatMap을 이해하기 전에 예제를 하나 들어 보겠다.
리스트에서 고유 문자로 이루어진 리스트를 반환해보자. 예를들어 ["Hello", "World"] 리스트가 있다면 결과로 ["H", "e", "l", "o", "W", "r", "d"]를 포함하는 리스트가 반환되어야 한다.
앞서 배운 distinct()를 활용하여 중복된 문자를 필터링하여 해결한다는 생각을 가질 수도 있다.

words.stream().map(word -> word.split("")).distinct().collect(toList());

위 코드에서 map으로 전달한 람다는 각 단어의 String[]을 반환한다는 점이 문제다. 따라서 map 메소드가 반환한 스트림의 형식은 Stream<String[]>이다. 우리가 원하는 것은 문자열 스트림을 표현할 Stream 이다. 우리는 이 문제는 flatMap 메서드를 이용하여 해결할 수 있다.

flatMap을 사용하면 다음처럼 문제를 해결할 수 있다.

List<String> uniqueCharacters = words.stream().map(word -> word.split("")).flatMap(Arrays::stream).distinct().collect(toList());

flatMap은 각 배열을 스트림이 아니라 스트림의 콘텐츠로 매핑한다. 즉, map과 달리 flatMap은 하나의 평면화된 스트림을 반환한다. 요약하자면 flatMap은 스트림의 각 값을 다른 스트림으로 만든 다음 모든 스트림을 하나의 스트림으로 연결하는 기능을 수행한다.

검색과 매칭

특정 속성이 데이터 집합에 있는지 여부를 검색하는 데이터 처리도 자주 사용된다. 스트림 API는 allMatch, anyMatch, noneMatch, findFirst, findAny 등 다양한 메서드를 제공한다.

anyMatch

프레디케이트가 적어도 한 요소와 일치하는지 확인

if (menu.stream().anyMatch(Dish::isVegetarian)) {
            System.out.println("This menu is vegetarian");
        }

anyMatch는 불리언을 반환하므로 최종연산이다.

allMatch

프레디케이트가 모든 요소와 일치하는지 검사

boolean isHealty = menu.stream().allMatch(dish -> dish.getCalories() < 1000);

noneMatch

noneMatch는 allMatch와 반대 연산을 수행한다.

boolean isHealty = menu.stream().noneMatch(dish -> dish.getCalories() >= 1000);

anyMatch, allMatch, noneMatch 세 메서드는 스트림 쇼트 서킷기법, 즉 자바의 && || 와 같은 연산을 활용한다.

요소 검색

요소 검색 메서드들을 살펴보기 전에 Optional부터 알아보겠다.
Optional 클래스는 값의 존재나 부재 여부를 표현하는 컨테이너 클래스이다. Optional은 값이 존재하는지 확인하고 값이 없을 때 어떻게 처리할지 강제하는 기능을 제공한다.
isPresent(), ifPresent, T get(), T orElse(T other)

menu.stream().filter(Dish::isVegetarian).findAny().ifPresent(dish -> System.out.println(dish.getName());

findAny

findAny 메서드는 현재 스트림에서 임의의 요소를 반환한다.

Optional<Dish> dish = menu.stream().filter(Dish::isVegetarian).findAny();

findFirst

스트림은 리스트의 첫 번째 요소를 찾을 수 있도록 findFirst 메서드를 지원한다.

List<Integer> someNumbers = Arrays.asList(1, 2, 3, 4, 5);
Optional<Integer> firstSquareDivisibleByThree = somNumbers.stream().map(n -> n * n).filter(n -> n % 3 == 0).findFirst(); //9

위의 코드는 숫자 리스트에서 3으로 나누어 떨어지는 첫 번째 제곱값을 반환하는 코드이다.

reduce

reduce는 스트림에서 누적값을 연산하는 메서드이다. reduce를 이용하여 sum, max, min 등 다양한 연산을 구현할 수 있다.
또한 초기값의 유무에 따라 Optional를 반환하는지가 결정된다.
아래는 reduce로 구현한 sum, max, min의 예제이다.

Optional<Integer> sum = numbers.stream().reduce(Integer::sum);
Optional<Integer> max = numbers.stream().reduce(Integer::max);
Optional<Integer> min = numbers.stream().reduce(Integer::min);

숫자형 스트림

스트림은 효율적으로 처리할 수 있도록 기본형 특화 스트림을 지원한다.
IntStream, DoubleStream, LongStream이 그 예이다.

앞선 예제인 menu.stream().map(Dish::getCalories).reduce(0, Integer::sum)에서 사실 박싱 비용이 숨어있다. 내부적으로 합계를 계산하기전 Integer를 기본형으로 언박싱해야한다. 이런점을 효율적으로 하기 위해 기본형 특화 스트림을 지원한다.

스트림 만들기

값으로 스트림 만들기

임의의 수를 인수로 받는 정적 메서드 Stream.of를 이용해서 스트림을 만들 수 있다.

Stream<String> stream = Stream.of("Modern", "Java", "In", "Action");

또한 다음처럼 empty 메서드를 이용하여 스트림을 비울 수 있다.

Stream<String> emptyStream = Stream.empty();

null이 될 수 있는 객체로 스트림 만들기

자바 9에서는 null이 될 수 있는 개체를 스트림으로 만들 수 있는 새로운 메소드가 추가되었다.

Stream<String> homeValueStream = Stream.ofNullable(System.getProperty("home"));

배열로 스트림 만들기

배열을 인수로 받는 정적 메서드 Arrays.stream을 이용해서 스트림을 만들 수 있다.

int[] numbers = {2, 3, 5, 7, 11, 13};
int sum = Arrays.stream(numbers).sum();

파일로 스트림 만들기

파일을 처리하는 등의 I/O 연산에 사용하는 자바의 API도 스트림 API를 활용할 수 있도록 업데이트 되었다.

함수로 무한 스트림 만들기

스트림 API는 함수에서 스트림을 만들 수 있는 두 정적 메서드 Stream.iterate와 Stream.generate를 제공한다. 이 메서드들을 이용해서 크기가 고정되지 않은 스트림을 만들 수 있다. 하지만 보통 무한한 값을 출력하지 않도록 limit(n)함수를 함께 연결해서 사용한다.
iterate 메서드 예제

Stream.iterate(0, n -> n+ 2).limit(10).forEach(System.out::println);

generate 메서드 예제

Stream.generate(Math::random).limit(5).forEach(System.out::println);

iterate와 generate의 차이점은 iterate는 생산된 값을 연속적으로 계산할 수 있고 generate는 새로운 값을 생성한다는 차이점이 있다.

마치며

• 스트림 API를 이용하면 복잡한 데이터 처리 질의를 표현할 수 있다.
• filter, distinct, takeWhile, dropWhile, skip, limit 메서드로 스트림을 필터링하거나 자를 수 있다.
• 소스가 정렬되어 있다는 사실을 알고 있을 때 takeWhile과 dropWhile 메소드를 효과적으로 사용할 수 있다.
• map, flatMap 메서드로 스트림의 요소를 추출하거나 변환할 수 있다.
• findFirst, findAny 메서드로 스트림의 요소를 검색할 수 있다. allMatch, noneMatch, anyMatch 메서드를 이용해서 주어진 프레디케이트와 일치하는 요소를 스트림에서 검색할 수 있다.
• 이들 메서드는 쇼트서킷, 즉 결과를 찾는 즉시 반환하며, 전체 스트림을 처리하지 않는다.
• reduce 메서드로 스트림의 모든 요소를 반복 조합하며 값을 도출할 수 있다. 예를 들어 reduce로 최댓값이나 모든 요소의 합계를 계산할 수 있다.
• filter, map등은 상태를 저장하지 않는 상태 없는 연산이다. reduce같은 연산은 값을 계산하는데 필요한 상태를 저장한다. sorted, distinct 등의 메서드는 새로운 스트림을 반환하기에 앞서 스트림의 모든 요소를 버퍼에 저장해야한다. 이런 메서드를 상태 있는 연산이라고 부른다.
• IntStream, DoubleStream, LongStream은 기본형 특화 스트림이다. 이들 연산은 각각의 기본형에 맞게 특화되어 있다.
• 컬렉션뿐 아니라 값, 배열, 파일, iterate와 generate 같은 메서드로도 스트림을 만들 수 있다.
• 무한한 개수의 요소를 가진 스트림을 무한 스트림이라 한다.

동적 파라미터화

자주 바뀌는 요구사항

프로그래밍을 하며 항상 바뀌는 고객의 니즈를 위해 우리는 그에 맞추어 대비해야한다.
이 책의 예를 인용하자면, 농부가 녹색 사과를 찾고 싶다는 요구사항이 다음날이면 150그램 이상인 사과를 찾고 싶다는 요구사항으로 바뀔 수 있다는 것이다. 이번 Chapter 2에서 소개하는 동작 파라미터화를 통해 이에 대한 문제를 효과적으로 대응할 수 있다.

동적 파라미터화의 장점

• 리스트의 모든 요소에 대해서 '어떤 동작'을 수행할 수 있음
• 리스트 관련 작업을 끝낸 다음에 '어떤 다른 동작'을 수행할 수 있음
• 에러가 발생하면 '정해진 어떤 다른 동작'을 수행할 수 있음

변화하는 요구사항에 대응하기 (사과)

이 책에서는 독자들로 하여금 사과를 예시로 들어 코드를 한 단계씩 발전시켜 설명한다. 복잡하고 중복되는 코드에서 점점 간단해지는 코드로 바뀌는 것을 볼 수 있다.

첫 번째 시도 : 녹색 사과 필터링

public static List<Apple> filterGreenApples(List<Apple> inventory) {
        List<Apple> result = new ArrayList<>();
        for(Apple apple: inventory){
            if(GREEN.equals(apple.getColor())){
                result.add(apple);
            }
        }
        return result;
    }

다음 코드는 사과 리스트 중 녹색 사과를 반환하는 메소드이다. 여기서 농부는 녹색 사과 이외에도 빨간 사과 또한 필터링하고 싶어졌다. 메소드를 복사하여 GREEN을 RED로 바꾸는 방법 등 여러 방법이 있지만 색이 추가되면 적절하게 대응할 수 없다. 이런 상황에서는 반복되는 부분을 추상화 해준다.

두 번째 시도 : 색을 파라미터화

public static List<Apple> filterApplesByColor(List<Apple> inventory, Color color) {
        List<Apple> result = new ArrayList<>();
        for(Apple apple: inventory){
            if(apple.getColor().equals(color)){
                result.add(apple);
            }
        }
        return result;
    }

두 번째 코드는 보다싶이 색깔을 파라미터로 넘겨받아 여러가지 색깔에 맞추어 대응할 수 있다. 하지만 농부가 색 이외에도 무게를 기준으로 필터링하고 싶다면 무게 정보 또한 파라미터로 추가해야한다. 하지만 이렇게 되면 기존에 Color로 필터링하는 함수와 중복되는 단점이 있다.

세 번째 시도 : 가능한 모든 속성으로 필터링

public static List<Apple> filterApples(List<Apple> inventory, Color color, int weight, boolean flag) {
        List<Apple> result = new ArrayList<>();
        for(Apple apple: inventory){
            if((flag && apple.getColor().equals(color)) ||
                    (!flag && apple.getWeight() > weight))
                result.add(apple);
            }
        }
        return result;
    }

세 번째 시도는 모든 속성을 파라미터로 넘겨주고 flag로 구분하는 방법이다. 이 방법은 얼마 공부하지 않은 내가 봐도 최악의 방법이라고 생각이 된다. 무엇을 나타내는 것인지 알 수 없는 flag, 너무 많은 파라미터, 또한 요구사항이 추가되면 파라미터는 더 길어지게 될 것이고 이는 가독성을 떨어뜨린다.

네 번째 시도 : 추상적 조건으로 필터링

public static List<Apple> filterApples(List<Apple> inventory, ApplePredicate p) {
        List<Apple> result = new ArrayList<>();
        for(Apple apple: inventory){
            if(p.test(apple)){
                result.add(apple);
            }
        }
        return result;
    }

이번에는 전략 디자인패턴(strategy design pattern)을 사용한 implements를 통해 앞선 코드보다 더 나은 방법을 찾아내었다. ApplePredicate객체를 파라미터화하여 내부적으로 다양한 동작을 수행할 수 있는 것이다. 다른 요구사항이 추가되면 우리는 ApplePredicate를 implements 받는 클래스를 구현하여 요구사항을 구현할 수 있다.

복잡한 과정 간소화

앞서 소개한 추상화를 통해 문제를 해결한 방법은 성공한 것처럼 보이지만, 새로운 동작을 또 전달하려면 ApplePredicate 인터페이스를 구현하는 여러 클래스를 정의한 다음 인스턴스화를 해야한다는 단점이 있다. 우리는 이를 또 개선해야한다.

다섯 번째 시도 : 익명 클래스 사용

List<Apple> redApples = filterApples(inventory, new ApplePredicate() {
            public boolean test(Apple apple){
                return RED.equals(apple.getColor());
            }
        });

위의 코드는 익명 클래스로 빨간 사과를 구하는 코드이다. 익명 클래스는 유용하지만 반복되고 공간을 많이 차지한다는 점에서 아직 부족하다. 또한 책에서는 많은 프로그래머가 익숙하지 않다는 단점을 추가로 이야기 하고 있다.

여섯 번째 시도 : 람다 표현식 사용

List<Apple> result = filterApples(inventry, (Apple apple) -> RED.equals(apple.getColor()));

이번 모던 인 액션 자바에서 많이 다룰 자바 8, 9, 10 중 자바 8에서 등장한 람다 표현식을 사용하였다. 앞에서 우리가 지나온 코드보다 훨씬 간단해져 있다는 것을 알 수 있다.