익명 클래스보다는 람다를 사용하라
람다 함수에서는 컴파일러가 타입을 추론하게 된다
람다 함수에서는 타입을 명시해야 코드가 더 명확할 때만 제외하고, 매개변수 타입은 생략하는게 좋다
람다는 이름이 없고 문서화를 할 수 없기 때문에, 코드 자체로 동작이 명확히 설명되지 않으면 사용하지 않아야 한다
람다는 한줄에서 세줄 사이인 것이 좋다
람다다는 메서드 참조를 사용하라
메서드 참조가 람다보다 간결하다면 메서드 참조를 사용해라
메서드 참조 유형
표준 함수형 인터페이스를 사용하라
필요한 용도에 맞는 게 있다면 직접 구현하지 말고 표준 함수형 인터페이스를 활용하는게 좋다
표준 함수형 인터페이스 대부분은 기본 타입만 지원하지만 기본 함수형 인터페이스에 박싱된 기본 타입을 넣어 사용하는 것은 좋지 못하다
직접 만든 함수형 인터페이스는 항상 @FunctionalInterface 애너테이션을 사용해야 한다
서로 다른 함수형 인터페이스를 같은 위치의 인수로 받는 메서드들을 다중 정의해서는 안 된다
스트림은 주의해서 사용하라
스트림 API는 다량의 데이터 처리 작업을 돕고자 추가
스트림 API가 제공하는 추상 개념
- 스트림은 데이터 원소의 유한 혹은 무한 시퀀스를 뜻한다
- 스트림 파이프라인은 이 원소들로 수행하는 연산 단계를 표현하는 개념
스트림 파이프라인은 소스 스트림에서 시작해 종단 연산으로 끝나며, 그 사이에 하나 이상의 중간 연산이 있을 수 있다
스트림 파이프 라인은 지연 평가 된다
평가는 종단 연산이 호출될 때 이루어지며, 종단 연산에 쓰이지 않는 데이터 원소는 계산에 쓰이지 않는다
이런 지연 평가가 무한 스트림을 다룰 수 있게 해준다
계산로직에서 스트림을 사용해야 하는 케이스
- 원소들이 시퀀스를 일관되게 반환
- 원소들이 시퀀스를 필터링
- 원소들의 시퀀스를 하나의 연산을 사용해 결합
- 원소들의 시퀀스 컬렉션에 모은다
- 원소들의 시퀀스에서 특정 조건을 만족하는 원소를 찾는다
스트림에서는 부작용 없는 함수를 사용하라
스트림 패러다임의 핵심은 계산을 일련의 변환으로 재구성하는 부분
forEach 연산은 스트림 계산 결과를 보고할 때만 사용하고, 계산하는 데는 쓰지 말아야 한다
collector을 사용하면 스트림 원소를 손쉽게 컬랜션으로 모을 수 있다
수집기의 종류
- toList()
- toSet()
- toMap()
- groupingBy()
- joining
반환 타입으로는 스트림보다 컬랙션이 낫다
원소 시퀀스를 반환하는 공개 API 반환 타입에는 Collectio이나 그 하위 타입을 쓰는 게 일반적
컬렉션을 반환할 수 있다면 그렇게 하는 것이 좋다
반환 전부터 이미 원소들을 컬렉션에 담아 관리하고 있거나 컬랙션을 하나 더 만들어도 될 정도로 원소 개수가 적다면 ArrayList 같은 표준 컬렉션에 담아 반환
컬렉션을 반환하는 게 불가능하면 스트림과 Iterable 중 더 자연스러운 것을 반환
스트림 병렬화는 주의해서 적용하라
동시성 프로그래밍을 할 때는 안전성과 응답 기능 상태를 유지하기 위해 애써야 하는데, 병렬 스트림 파이프라인 프로그래밍에서도 마찬가지
대체로 스트림의 소스가 ArrayList, HashMap, HashSet, ConcurrentHashMap의 인스턴슥거나 배열, int 범위, long 범위일 때 병렬화의 효과가 가장 좋다
스트림을 잘못 병렬화하면 성능이 나빠질 뿐만 아니라 결과 자체가 잘못되거나 예상 못한 동작이 발생할 수 있다
조건이 잘 갖춰지면 parallel 메서드 호출 하나로 프로세서 코어 수에 비례하는 성능 향상이 있을 수 있다
