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

이번 아이템은 API 설계요령을 설명한다.

 

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

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

 

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

모든 메서드는 각각 자신의 소임을 다해야 한다. 메서드가 너무 많은 클래스는 익히고, 사용하고, 문서화하고, 테스트하고, 유지보수하기 어렵다.

아주 자주 쓰일 경우에만 별도의 약칭 메서드를 두자.

 

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

4개 이하가 좋다. 4개가 넘어가면 매개변수를 전부 기억하기가 쉽지 않다.

같은 타입의 매개변수 여러 개가 연달아 나오는 경우가 특히 좋지 않다.

 

 

과하게 긴 매개변수 목록을 짧게 줄여주는 기술 3가지가 있다.

 

1. 여러 메서드로 쪼갠다.

잘못하면 메서드가 너무 많아질 수 있지만 직교성을 높여 오히려 메서드가 줄어드는 효과도 있다.

리스트에서 주어진 원소의 인덱스를 찾아야 하는데, 전체 리스트가 아니라 지정된 범위의 부분리스트에서의 인덱스를 찾는다고 가정해보자

List<Integer> list = new ArrayList<>();
int index = list.indexOfSubList(1, 5, 2);

 

부분 리스트의 시작과 끝, 찾을 원소까지 총 3개의 매개변수가 필요하다.

위 요구 조건을 부분리스트, 주어진 원소의 인덱스를 찾는 부분으로 메서드를 나눠 별개의 메서드를 제공한다면 두 메서드를 조합해 원하는 목적을 이룰 수 있다.

List<Integer> list = new ArrayList<>();
List<Integer> subList = list.subList(1, 5);
int index = subList.indexOf(2);

 

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

일반적으로 이런 도우미 클래스는 정적 멤버 클래스로 둔다. 특히 잇따른 매개변수 몇 개를 독립된 하나의 개념으로 볼 수 있을 때 추천한다. 예를 들어 카드게임을 클래스로 만든다고 해보자. 메서드를 호출할 때 카드의 숫자와 무늬를 뜻하는 두 매개변수를 전달한다고 가정하자

public class Card {
    private int number;
    private String pattern;

    public Card(int number, String pattern) {
        this.number = number;
        this.pattern = pattern;
    }

    public int getNumber() {
        return number;
    }

    public String getPattern() {
        return pattern;
    }
}

Card card = new Card(1, "spade");
cardGame.check(card);

 

3. 위 두 기법을 혼합한 것으로, 객체 생성에 사용한 빌더 패턴을 메서드 호출해 응용한다.

이 기법은 매개변수가 많을 때, 특히 그중 일부는 생략해도 괜찮을 때 도움이 된다.

먼저 매개변수를  하나로 추상화한 객체를 정의하고, 클라이언트에서 이 객체의 세터 메서드를 호출해 필요한 값을 설정하게 한다. 클라이언트가 매개변수를 설정한 다음, execute 메서드를 호출해 매개변수의 유효성을 검사한다.

 

 

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

더 유현하게 매개변수를 보낼 수 있으니 당연하다.

 

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

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