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

다음은 API 설계 요령들을 모아 놓은 것이다. 이 요령들을 잘 활용하면 배우기 쉽고, 쓰기 쉬우며, 오류 가능성이 적은 API를 만들 수 있을 것이다.

## 메서드 이름을 신중히 짓자.

- 항상 표준 명명 규칙을 따라야 한다. 이해할 수 있고, 같은 패키지에 속한 다른 이름들과 일관되게 짓는 게 최우선 목표다.
- 긴 이름은 피하도록 한다. 애매하면 자바 라이브러리의 API 가이드를 참조하도록 한다. 대부분은 납득할만한 수준이다.

## 편의 메서드를 너무 많이 만들지 말자.

- 메서드가 너무 많은 클래스는 익히고, 사용하고, 문서화하고, 테스트하고, 유지보수하기 어렵다. 인터페이스도 마찬가지다.
- 클래스나 인터페이스는 자신의 각 기능을 완벽히 수행하는 메서드로 제공해야 한다.
- 아주 자주 쓰일 경우에만 별도의 약칭 메서드를 두도록 한다. **확신이 서지 않으면 만들지 않도록 한다.**

## 매개변수 목록은 짧게 유지하자.

- 4개 이하가 좋다. 일단 4개가 넘어가면 매개변수를 전부 기억하기가 쉽지 않다.
- **같은 타입의 매개변수 여러 개가 연달아 나오는 경우가 특히 해롭다.**
    - 사용자가 매개변수 순서를 기억하기도 어렵고, 실수로 순서를 바꿔 입력해도 그대로 컴파일되고 실행된다. 그리고, 의도와 다르게 동작한다.

### 과하게 긴 매개변수 목록을 짧게 줄여주는 기술

- 첫 번째. 여러 메서드로 쪼갠다.
    - 쪼개진 메서드 각각은 원래 매개변수 목록의 부분집합을 받는다.
    - 잘못하면 메서드가 너무 많아질 수 있지만, 직교성(orthohonality)을 높여 오히려 메서드 수를 줄여주는 효과도 있다.

> "직교성이 높다"라고 하면 "공통점이 없는 기능들이 잘 분리되어 있다" 혹은 "기능을 원자적으로 쪼개 제공한다" 정도로 해석할 수 있다.
> 기능을 원자적으로 쪼개다 보면, 자연스럽게 중복이 줄고 결합성이 낮아져 코드를 수정하기 수월해지며 테스트하기 쉬워진다.
> 일반적으로 직교성이 높은 설계는 가볍고 구현하기 쉽고 유연하고 강력하다. 단, API가 다루는 개념의 추상화 수준에 맞게 조절해야 한다.
> 또한 특정 조합의 패턴이 상당히 자주 사용되거나 최적화하여 성능을 크게 개선할 수 있다면 직교성이 낮아지더라도 편의 기능으로 제공하는 편이 나을 수도 있다.

- 두 번째. 매개변수 여러 개를 묶어주는 도우미 클래스를 만든다.
- 세 번째. 객체 생성에 사용한 빌더 패턴을 메서드 호출에 응용한다.
    - 이 기법은 매개변수가 많을 때, 특히 그중 일부는 생략해도 괜찮을 때 도움이 된다.
    - 먼저 모든 매개변수를 하나로 추상화한 객체를 정의하고, 클라이언트에서 이 객체의 세터(setter) 메서드를 호출해 필요한 값을 설정하게 한다.
    - 이때 각 세터 메서드는 매개변수 하나 혹은 서로 연관된 몇 개만 설정하게 한다.
    - 클라이언트는 먼저 필요한 매개변수를 다 설정한 다음, 앞어 설정한 매개변수들의 유효성을 검사한다.
    - 마지막으로, 설정이 완료된 객체를 넘겨 원하는 계산을 수행한다.

## 매개변수의 타입으로는 클래스보다는 인터페이스가 더 낫다.

- 매개변수로 적합한 인터페이스가 있다면 (이를 구현한 클래스가 아닌) 그 인터페이스를 직접 사용하도록 한다.
    - ex. 메서드에 HashMap을 넘길 일은 전혀 없다. 대신 Map을 사용한다. 그러면 다른 Map 구현체도 인수로 건넬 수 있다.
- 인터페이스 대신 클래스를 사용하면 클라이언트에게 특정 구현체만 사용하도록 제한하는 꼴이며, 혹시라도 입력 데이터가 다른 형태로 존재한다면 명시한 특정 구현체의 객체로 옮겨 담느라 비싼 복사 비용을 치러야 한다.

## boolean보다는 원소 2개짜리 열거 타입이 낫다.

- 단, 메서드 이름상 boolean을 받아야 의미가 더 명확할 때는 예외다.
- 열거 타입을 사용하면 코드를 읽고 쓰기가 더 쉬워지며, 나중에 선택지를 추가하기도 쉽다.
- 열거 타입을 사용하면 개별 열거 타입 상수 각각에 특정 동작을 수행하는 메서드를 정의해둘 수도 있다.
