[이펙티브 자바] 아이템 51. 메서드 시그니처를 신중히 설계하라

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

• 항상 표준 명명 규칙(아이템 68)을 따라야 한다.

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

• 메서드가 너무 많으면 테스트하기 어렵고 사용하는 사람도 힘들다. 확신이 서지 않으면 만들지 말자.

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

• 4개 이하가 좋다. 같은 타입의 매개변수 여러 개가 연달아 나오는 경우 특히 해롭다. 실수로 순서가 바뀌어도 컴파일된다.

• 매개변수 목록 짧게 줄이는 기술

  1. 여러 메서드로 쪼갠다. 쪼개진 메서드 각각은 원래 매개변수의 부분집합을 받는다. java.util.List 인터페이스가 좋은 예인데, 리스트에서 주어진 원소의 인덱스를 찾아야 하는데, 지정된 범위의 부분리스트에서 인덱스를 찾는다고 해보자. 원래라면 부분리스트의 시작, 부분리스트의 끝, 찾을 원소까지 총 3개의 매개변수가 필요하다. 그런데 List는 부분리스트를 반환하는 subList 메서드와 주어진 원소의 인덱스를 알려주는 indexOf 메서드로 분리했다. subList가 반환한 부분 리스트도 완벽한 List이므로 가능하다

  2. 매개변수 여러 개를 묶어주는 도우미 클래스를 만들기. 일반적으로 이런 도우미 클래스는 정적 멤버 클래스로 둔다(아이템 24). 예를 들어 카드게임을 클래스로 만들 때, 메서드 호출시 rank와 suit 두 매개변수를 묶는 하나의 도우미 클래스로 만들면 내부 구현이 깔끔해진다.

  3. 빌더 패턴(아이템2)을 메서드 호출에 응용한다. 특히 일부 매개변수를 생략해도 괜찮을 때 도움이 된다. 모든 매개변수를 하나로 추상화한 객체를 정의하고, 클라이언트에서 이 객체의 세터 메서드를 호출해 필요한 값을 설정하게 하는 것이다.

매개변수의 타입으로는 클래스보다는 인터페이스가 낫다.(아이템 64).

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

• 메서드 이름상 boolean을 받아야 의미가 더 명확할 때는 예외다. 예를 들어 온도계 클래스의 정적 팩터리 메서드가 이 열거 타입을 입력받아 적합한 온도계 인스턴스를 생성해준다고 해보자. Thermometer.newInstance(true) 보다는 Thermometer.newInstance(TemperatureScale.CELSIUIS)가 하는 일을 명확히 알려준다.