| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 | 31 |
- Route53
- 개발공부
- 도커
- 캡스톤디자인프로젝트
- 생활코딩
- 게임개발동아리
- 라피신
- 전국대학생게임개발동아리연합회
- 스프링부트
- Spring boot
- CICD
- AWS
- 프리티어
- 체크인미팅
- 인프라
- spring ai
- 42서울
- UNIDEV
- 프롬프트엔지니어링
- UNICON
- bastion host
- 오블완
- UNICON2023
- Redis
- 프로그래밍
- 티스토리챌린지
- 백엔드개발자
- NAT gateway
- openAI API
- EC2
- Today
- Total
Hyun's Wonderwall
[Java] 이펙티브 자바 - 7장(2/2), 8장(1/2) (아이템 46~54) 본문
7장 람다와 스트림
아이템 46. 스트림에서는 부작용 없는 함수를 사용하라
스트림 패러다임의 핵심: 계산을 일련의 변환으로 재구성.
- 각 변환 단계는 가능한 한 이전 단계의 결과를 받아 처리하는 순수 함수여야 한다.
- 순수 함수: 오직 입력만이 결과에 영향을 주는 함수. 다른 가변 상태를 참조하지 않고, 함수 스스로도 다른 상태를 변경하지 x
- 이렇게 하려면 스트림 연산에 건네지는 함수 객체가 모두 side effect이 없어야 한다.
forEach 연산은 스트림 계산 결과를 보고할 때만 사용하고, 계산 자체에 쓰지 말자.
- collect: 축소 전략을 캡슐화한 블랙박스 객체. 스트림의 원소들을 객체 하나에 취합함. 수집기가 생성하는 객체는 일반적으로 컬렉션.
- 수집기를 사용하면 스트림의 원소를 손쉽게 컬렉션으로 모울 수 있다. (ex. toList(), toSet(), toCollection(collectionFactory))
가장 중요한 수집기 팩터리는 toList, toSet, toMap, groupingBy, joining.
아이템 47. 반환 타입으로는 스트림보다 컬렉션이 낫다
스트림은 반복을 지원하지 않는다.
원소 시퀀스를 반환하는 메서드를 작성할 때는, 이를 스트림으로 처리하길 원하는 사용자와 반복으로 처리하길 원하는 사용자가 있음을 떠올리고 양쪽을 다 만족시키려 노력하자.
원소 시퀀스를 반환하는 공개 API의 반환 타입에는 Collection이나 그 하위 타입을 쓰는 게 일반적으로 최선.
표준 컬렉션에 담아 반환하라. (그렇지 않으면 전용 컬렉션을 구현할지 고민하라)
컬렉션을 반환하는 게 불가능하면 스트림과 Iterable중 더 자연스러운 것을 반환하라.
+) Iterable을 stream으로 변환하기
https://www.baeldung.com/java-iterable-to-stream
아이템 48. 스트림 병렬화는 주의해서 적용하라
parallel 메서드로 스트림 파이프라인 병렬 실행이 가능하다.
대체로 스트림의 소스가 ArrayList, HashMap, HashSet, ConcurrentHashMap의 인스턴스거나 배열, int 범위, long 범위일 때 병렬화의 효과가 가장 좋다.
조건이 잘 갖춰지면 parallel 메서드 호출 하나로 거의 프로세서 코어 수에 비례하는 성능 향상을 만끽할 수 있다.
그러나, 스트림을 잘못 병렬화하면 프로그램이 오동작하거나 성능이 급격하게 떨어진다.
병렬화 시 수정 후 코드가 여전히 정확한지 꼭 체크할 것.
8장 메서드
메서드를 설계할 때 주의할 점
- 매개변수와 반환값 처리, 메서드 시그니처 설계, 문서화 방법
- 메서드뿐 아니라 생성자에도 적용
아이템 49. 매개변수가 유효한지 검사하라
메서드와 생성자 대부분은 입력 매개변수의 값이 특정 조건을 만족하기를 바란다.
이런 제약은 반드시 문서화해야 하며 메서드 body가 시작되기 전에 검사해야 한다. (오류를 가능한 한 빨리 잡기 위해)
메서드 몸체가 실행되기 전에 매개변수를 확인한다면 잘못된 값이 넘어왔을 때 즉각적이고 깔끔한 방식으로 예외를 던질 수 있다.
매개변수 검사를 제대로 하지 못하면 생길 수 있는 문제들:
(1) 메서드 수행 도중 모호한 예외를 던짐
(2) 메서드가 잘 수행됐지만 잘못된 결과 반환
(3) 메서드는 문제없이 수행됐지만 어떤 객체를 이상한 상태로 변경해 미래에 메서드와는 관련없는 오류를 발생시킴
-> 매개변수 검사에 실패하면 실패 원자성을 어기는 결과를 낳을 수 있다.
public과 protected 메서드는 매개변수 값이 잘못됐을 때 던지는 예외를 문서화해야 한다.
자바에 Objects.requireNonNull 메서드를 통해 값을 사용하는 동시에 null 검사를수행할 수 있다.
(반환값은 그냥 무시하고 어디서든 써도 됨)
아이템 50. 적시에 방어적 복사본을 만들라
클래스가 클라이언트로부터 받는/반환하는 구성요소가 가변이라면 반드시 방어적으로 복사해야 한다.
복사 비용이 너무 크거나 클라이언트가 그 요소를 잘못 수정할 일이 없음을 신뢰한다면, 방어적 복사를 수행하는 대신 해당 구성요소를 수정했을 때의 책임이 클라이언트에 있음을 문서에 명시.
아이템 51. 메서드 시그니처를 신중히 설계하라
1. 메서드 이름을 신중히 짓자. 항상 표준 명명규칙을 따를 것.
2. 편의 메서드를 너무 많이 만들지 말자. 확신이 서지 않으면 만들지 말자.
3. 매개변수 목록은 짦게 유지하자. 같은 타입 매개변수가 연달아 나오는 경우가 가장 위험.
4. 매개변수의 타입은 클래스보다는 인터페이스가 더 낫다.
5. boolean보다는 원소 2개짜리 열거 타입이 낫다.
아이템 52. 다중정의는 신중히 사용하라
매개변수 수가 같을 때는 다중정의를 피하는 게 좋다.
형변환을 이용해 정확한 다중정의 메서드가 선택되도록 해라.
아이템 53. 가변인수는 신중히 사용하라
인수 개수가 일정하지 않은 메서드를 정의해야 한다면 가변인수가 반드시 필요하다.
가변인수 사용 시
- 필수 매개변수는 가변인수 앞에 두라.
- 선능 문제를 고려하자.
아이템 54. null이 아닌, 빈 컬렉션이나 배열을 반환하라
null을 반환하면 사용하기 어렵고 오류 처리 코드도 늘어난다.성능이 좋은 것도 아니다.
'Study > Java' 카테고리의 다른 글
| [Java] 이펙티브 자바 - 9장(2/2), 10장(1/2) (아이템 64-72) (0) | 2025.09.06 |
|---|---|
| [Java] 이펙티브 자바 - 8장(2/2), 9장(1/2) (아이템 55-63) (1) | 2025.08.30 |
| [Java] 이펙티브 자바 - 6장(2/2), 7장(1/2) (아이템 37~45) (2) | 2025.08.16 |
| [Java] 이펙티브 자바 - 5장(2/2), 6장(1/2) (아이템 28~36) (4) | 2025.08.16 |
| [Java] 이펙티브 자바 - 4장(2/2), 5장(1/2) (아이템 19~27) (4) | 2025.08.02 |