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

이번 아이템에는 개별 아이템으로 두기 애매한 API 설계 요령들을 모아 놓았다.

• 메서드 이름을 신중히 짓자.
  • 항상 표준 명명 규칙을 따라야 한다. 이해할 수 있고, 같은 패키지에 속한 다른 이름들과 일관되게 짓는 게 최우선 목표
  • 그 다음 목표는 개발자 커뮤니티에서 널리 받아들여지는 이름을 사용하는 것
  • 긴 이름은 피하자.
  • 애매하면 자바 라이브러리의 API 가이드를 참조하라.

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

  • 메서드가 너무 많은 클래스는 익히고, 사용하고, 문서화하고, 테스트하고, 유지보수 하기 어렵다.
  • 아주 자주 쓰일 경우에만 별도의 약칭 메서드를 두기 바란다. 확신이 서지 않으면 만들지 말자.

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

  • 4개 이하가 좋다. 4개가 넘어가면 매개변수를 전부 기억하기가 쉽지 않다.
  • 같은 타입의 매개변수 여러 개가 연달아 나오는 경우가 특히 해롭다.

매개변수 목록을 짧게 줄여주는 기술 3가지

1. 여러 메서드로 쪼갠다.
   • 쪼개집 메서드 각각은 원래 매개변수 목록의 부분집합을 받는다.
   • 잘못하면 메서드가 너무 많아질 수 있지만 직교성(orthogonality)을 높여 오리혀 메서드 수를 줄여주는 효과도 있다.
   • java.util.List 인터페이스가 좋은 예다.

직교란? 수학에서 온 용어로, 서로 직각을 이루며 교차한다는 뜻. 수학의 관점에서 직교하는 요소들은 서로 독립적이다.
이 개념을 소프트웨어 설계 영역으로 가져와 "직교성이 높다"라고 하면 "공통점이 없는 기능들이 잘 분리되어 있다"
혹은 "기능을 원자적으로 쪼개 제공한다" 정도로 해석할 수 있다.

2. 매개변수 여러 개를 묶어주는 도우미 클래스는 만든다.

3. 앞서의 두 기법을 혼합한 것으로, 객체 생성에 사용한 빌더 패턴을 메서드 호출에 응용한다고 보면 된다.

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

  • 예를 들어 메서드에 HashMap을 넘길 일은 전혀 없다. 대신 Map을 사용하자. 그러면 HashMap, TreeMap, ConcurrentMap, TreeMap의 부분맵 등 어떤 Map 구현체도 건넬 수 있다. 심지어 아직 존재하지 않는 Map도 가능하다.

• boolean보다는 원소 2개 짜리 열거 타입이 낫다. 열거 타입을 사용하면 코드를 읽고 쓰기가 더 쉬워진다.

public enum TemperatureScale { FAHRENHEIT, CELSISUS }

온도계 클래스의 정적 팩터리 메서드가 이 열거 탕비을 입력 받아 적합한 온도계 인스턴스를 생성해준다고 해보자.

확실히 Thermometer.newInstance(true)보다는 Thermometer.newInstance(TemperatureScale.CELSIUS)가 하는 일을 명확히 알려준다.

나중에 캘빈온도도 지원해야 한다면, Thermometer에 또 다른 정적 메서드를 추가할 필요 없이 TemperatureScale 열거 타입에 캘빈온도(KELVIN)를 추가하면 된다.

또한, 온도 단위에 대한 의존성을 개별 열거 타입 상수의 메서드 안으로 리팩터링해 넣을 수도 있다.

예컨대 double 값을 받아 섭씨온도로 변환해주는 메서드를 열거 타입 상수 각각에 정의해둘 수도 있다.