Item51. method 시그니처를 신중히 설계하라

이번 아이템에서는 API 설계 권고 사항들을 정리하였다.

method 이름을 신중히 짓자.

• 항상 표준 명명 규칙 (Item68)을 따라야 한다.
• 같은 패키지에 속한 다른 이름들과 일관되게 짓는게 최우선이다.
• 개발자 커뮤니티에서 널리 받아 들여지는 이름을 사용하자
• 긴 이름은 피하자

편의 method를 너무 많이 만들지 말자

• method가 너무 많은 class는 익히고 , 사용하고, 문서화하고 , 테스트하고 유지보수하기 어렵다. 따라서 아주 자주 쓰일때만 편의 method로 만들자

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

• 매개변수가 4개를 넘어가면 가독성이 떨어진다.
• 같은 type의 매개변수가 여러개 연달아 나오는 경우에는 특히 순서가 변경되어도 그대로 실행됨으로 좋지 않다.

매개변수 목록을 줄이는 방법

1. 여러 method로 분리하고, 분리한 method는 매개변수의 부분 집합을 받는다.

method가 너무 많아질 수 있으나, 직교성을 높여 오히려 method수를 줄여주는 효과도 있다.
여기서 직교성을 높인다는 말은 method간에 중복이 줄고, 결합성이 낮아져서 method들을 통해서 필요한 기능을 조합해서 만들수 있음으로 method수가 낮아질 수도 있다는 말이다.

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

일반적으로 이러한 도우미 class는 정적 멤버 class로 둔다.

3. 빌더 패턴과 유사한 방식으로, 모든 매개변수를 하나로 추상화한 객체를 정의하고, client에서 이 객체의 setter method를 호출해 필요한 값을 설정하게 하는 것이다.

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

인터페이스를 넘기면, 그 인터페이스의 모든 구현체를 인수로 전달할 수 있다. 만약 클래스를 인수로 받게 하면 해당 구현체만 사용하도록 제한하게 된다.

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

예를 들어 아래와 같이 화씨온도(FAHREHEIT) 와 섭씨온도(CELSIUS)를 원소로 정의한 열거 타입이 있다고 가정하자.

public enum TemperatureScale {
    FAHRENHEIT , CELSIUS
}

온도계 class가 있고, TemperatureScale enum class 타입에 따라 적합한 온도계 class를 생성한다고 하면 아래와 같은 정적 팩토리 method를 만들 수 있을 것이다.

static Thermometer newInstance(TemperatureScale scale){
    // ...
}

만약 매개변수로 enum type을 받지 않고, boolean type으로 true이면 화씨온도계, false면 섭씨온도계로 온도계 class의 instance를 만든다면 가독성도 떨어지고, 확장성도 떨어진다.