이펙티브 자바 3/E

8장. 람다와 스트림

49. 매개변수가 유효한지 검사하라.

핵심 정리

메서드나 생성자를 작성할 때면, 그 매개변수들에 어떤 제약이 있을지 생각해야한다. 그 노력은 유효성 검사가 실제 오류를 처음 걸러낼 때 충분히 보상받을 것이다.

50. 적시에 방어적 복사본을 만들라.

핵심 정리

클래스가 클라이언트로부터 혹은 클라이언트로 반환하는 구성요소가 가변이라면 그 요소는 반드시 방어적으로 복사해야 한다.
복사 비용이 너무 크거나 클라이언트가 그 요소를 잘못 수정할 일이 없음을 신뢰한다면 방어적 복사를 수행하는 대신 해당 구성요소를 수정했을 때의 책임이 클라이언트에 있음을 문서에 명시하도록 하자.

51. 메서드 시그니처를 신중히 설계하라.

핵심 정리

메서드 이름을 신중히 짓자.
편의 메서드를 너무 많이 만들지 말자.
- 메서드가 너무 많으면 이를 구현하는 사람과 사용하는 사람 모두를 고통스럽게 한다.
- 확신히 서지 않으면 만들지 말자.
매개변수 목록은 짧게 유지하자. (4개 이하)
- 같은 타입의 매개변수 여러 개가 연달아 나오는 경우가 특히 해롭다.
- 도우미 클래스를 만들어 여러 개를 묶는다.
- 매개변수가 많고, 그 중 일부는 없어도 될 경우 빌더 패턴을 을용한다.
- 하나의 메서드에 여러가지 일을 할 경우, 여러 메서드로 쪼개는 것도 방법이다.
매개변수의 타입으로 클래스보다는 인터페이스가 더 낫다.
- 예) Map (O) > HashMap(X)
boolean보다는 원소 2개짜리 Enum(열거) 타입이 낫다.

52. 다중 정의는 신중히 하라.

핵심 정리

프로그래밍 언어가 다중 정의를 허용한다고 해서 다중 정의를 꼭 활용하란 뜻은 아니다.
일반적으로 매개변수 수가 같을 때는 다중정의를 피하는 게 좋다.
상황에 따라, 특히 생성사라면 이 조언을 따르기가 불가능할 수 있다. 그럴 때는 헷갈릴 만한 매개변수는 형변환하여 정확한 다중정의 메서드가 선택되도록 해야 한다.
이것이 불가능하면, 예컨대 기존 클래스를 수정해 새로운 인터페이스를 구현해야 할 때는 같은 객체를 입력받는 다중 정의 메서드들이 모두 동일하게 동작하도록 만들어야 한다.
(그렇지 못하면 프로그래머들은 다중 정의된 메서드나 생성자를 효과적으로 사용하지 못할 것이고, 의도대로 동작하지 않는 이유를 이해하지 못할 것이다.)

53. 가변인수는 신중히 사용하라.

핵심 정리

인수 개수가 일정하지 않은 메서드를 정의해야 한다면 가변인수가 반드시 필요하다.
메서드를 정의할 때 필수 매개변수는 가변인수 앞에 두고, 가변인수를 사용할 때는 성능 문제까지 고려하자.

54. null이 아닌, 빈 컬렉션이나 배열을 반환하라

핵심 정리

null을 반환하는 API는 사용하기 어렵고 오류 처리 코드도 늘어난다. 그렇다고 성능이 좋은것도 아니다.
null이 아닌, 빈 컬렉션이나 배열을 반환하라

55. Optional 반환은 신중히 하라.

핵심 정리

값을 반환하지 못할 가능성이 있고, 호출할 때마다 반환값이 없을 가능성을 염두에 둬야하는 메서드라면 옵셔널을 반환해야 할 상황일 수 있다.
하지만 Optional 반환에는 성능 저하가 뒤따르니, 성능에 민감한 메서드라면 null을 반환하거나 예외를 던지는 편이 나을 수 있다. 그리고 Optional을 반환값 이외의 용도로 쓰는 경우는 매우 드물다.

56. 공개된 API 요소에는 항상 문서화 주석을 사용하라.

핵심 정리

문서화 주석은 여러분 API를 문서화하는 가장 훌룡하고 효과적인 방법이다. 공개 API라면 빠짐없이 설명을 달아야 한다.
표준 규약을 일관되게 지키자. 문서화 주석에 임의의 HTML 태그를 사용할 수 있음을 기억하라. 단, HTML 메타문자는 특별하게 취급해야 한다.