Effective Java ( 이펙티브 자바 ) - 아이템 51

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

---

이번 아이템에는 개별 아이템으로 두기 애매한 API 설계 요령들을 모아 놓았다.  배우기 쉽고, 쓰기 쉽고, 오류 가능성이 적은 API를 만들 수 있을 것이다.

 

메서드 이름을 신충히 짓자

   항상 표준 명명 규칙을 따라야 한다. 일관되고, 널리 받아들여지는 이름을 사용하는 것이다. 긴 이름은 피하자. 

 

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

   메서드가 너무 많은 클래스는 익히고, 사용하고, 문서화하고, 테스트하고, 유지보수하기 어렵다. 인터페이스도 마찬가지다. 메서드가 너무 많으면 이를 구현하는 사람과 사용하는 사람 모두를 고통스럽게 한다. 확신이 서지 않으면 만들지 말자. 

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

  4개 이하가 좋다. 일단 4개가 넘어가면 기억하기가 쉽지 않다. IDE를 사용하면 수고를 많이 덜 수 있지만, 여전히 매개변수 수는 적은 쪽이 훨씬 낫다. 같은 타입의 매개변수 여러 개가 연달아 나오는 경우가 특히 해롭다. 실수로 순서를 바꿔 입력해도 그대로 컴파일되고 실행된다. 단지 의도와 다르게 동작할 뿐이다.

 

과하게 긴 매개변수 목록을 짧게 줄여주는 기술 세 가지를 소개한다. 

1. 여러 메서드로 쪼갠다. 잘못하면 메서드가 너무 많아질 수 있지만. 직교성을 높여 오히려 메서드 수를 줄여주는 효과도 있다. List가 그 예시다. 전체 리스트가 아니라 지정된 범위의 부분리스트에서 인덱스를 찾는다고 해보자. 하나의 메서드로 구현하려면 '부분 리스트의 시작', '부분 리스트의 끝', '찾을 원소' 까지 총 3개의 매개변수가 필요하다. 그런데 List는 그 대신 부분리스트를 반환하는 subList 메서드와 indexOf 메서드를 별개로 제공한다. 조합하면 된다.
2. 매개변수 여러 개를 묶어주는 도우미 클래스를 만드는 것이다. 일반적으로 이런 도우미 클래스는 정적 멤버 클래스로 둔다. 특히 잇따른 매개변수 몇 개를 독립된 하나의 개념으로 볼 수 있을 때 추천하는 기법이다. 
3. 앞서의 두 기법을 혼합한 것으로, 객체 생성에 사용한 빌더 패턴을 메서드 호출에 응용한다고 보면 된다. 

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

  메서드에 HashMap을 넘길 일은 전혀 없다. Map을 사용하자. 이러면 심지어 아직 존재하지 않는 Map도 가능하다.

 

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

  열거 타입을 사용하면 코드를 읽고 쓰기가 더 쉬워진다. 나중에 선택지를 추가하기도 쉽다. 

public enum TemperatureScale { FAHRENHEIT, CELSIUS }

확실히 Thermometer.newInstance(true) 보다는 Thermometer.newInstance(TemperatureScale.CELSIUS)가 하는 일을 훨씬 명확히 알려준다. 나중에 캘빈온도도 지원해야 한다면, 열거 타입에 캘빈온도를 추가하면 된다.