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

개별 아이템으로 두기 애매한 API 설계요령을 모아놨다.

• 잘 활용하면 배우기 쉽고, 쓰기 쉬우며, 오류 가능성이 적은 API를 작성 가능하다!

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

항상 표준 명명규칙을 따라야 한다.

• 같은 패키지에 속한 다른 이름들과 일관되게 짓는게 최우선
• 개발자 커뮤니티에서 널리 받아들여지는 이름 사용
• 긴 이름은 피하자

자바 라이브러리가 워낙 방대하다 보니 일관되지 않은 이름도 제법 많지만 대부분 납득할 만한 수준이라고 한다.

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

메서드가 너무 많은 클래스 혹은 인터페이스는 익히고, 사용하고, 문서화하고, 테스트하고, 유지보수하기 어렵다.
각 기능을 완벽히 수행하는 메서드로 제공해야 한다
아주 자주 쓰일때만 약칭 메서드를 만드는걸 추천한다.

확신이 서지 않으면 만들지 말아라!

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

매개변수는 4개 이하가 좋다.
IDE를 사용하면(?) 수고를 많이 덜 수 있지만 매개변수 수는 적은 쪽이 좋다.
같은 타입의 매개변수가 여러개 연달아 나오면 특히 해롭다.

• 과하게 긴 매개변수 목록을 짧게 줄여주는 기술

  1. 여러 매소드로 쪼갠다.

     • 메서드가 너무 많아질 수 있지만, 직교성(orthogonality)을 높여 오히려 메서드 수를 줄여준다.

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

     • 보통 도우미 클래스는 정적 멤버 클래스로 둔다.

  3. 두 기법을 혼합하여 객체 생성에 사용한 빌더 패턴을 메서드 호출에 응용

     • 모든 매개변수를 하나로 추상화한 객체를 정의
     • 클라이언트에서 이 객체의 세터를 호출해 필요한 값을 설정
     • 각 세터 메서드는 매개변수 하나 혹은 서로 연관된 몇개만 설정
     • 필요 매개변수를 다 설정한 이후 execute 메서드를 호출해 앞서 설정한 매개변수들의 유효성 검사를 실행한다.
     • 설정이 완료된 객체를 넘겨 원하는 계산을 수행

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

매개변수로 적합한 인터페이스가 있다면 인터페이스를 직접 사용하자.
보통 메서드에 매개변수로 HashMap이 아닌 Map을 사용하는 것처럼.
Map을 매개변수로 넘기면 Map의 구현체들을 인수로 건낼 수 있다.
구현체를 인수로 넘기는 경우는 특정 구현체만 사용하도록 제한이 필요한 경우이다.
특정 구현체를 인수로 넘기고 다른 구현체로 변경해야 한다면, 비싼 복사비용을 치러야 한다.

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

특정 메소드의 인수를 true, false가 가장 명확한 경우를 제외하면 열거타입을 사용하는것이 낫다.
Thermometer.newInstance(true)보다는 Thermometer.newInstance(TemperatureScale.CELSIUS)가 더 명확하다.
boolean보다 명확하며, 확장성도 높아지게 된다.