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

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

---

이번 아이템은 API 설계 요령들이다

• 잘 활용하면 배우기 쉽고, 쓰기 쉬우며, 오류 가능성이 적은 API를 만들 수 있을 것이다

메서드 이름은 신중히 짓자

• 항상 표준 명명 규칙을 따라야 한다(item 68)
• 이해할 수 있고 같은 패키지에 속한 다른 이름들과 일관되게 짓는게 중요하다
• 개발자 커뮤니티에서 널리 받아들여지는 이름을 사용하자
• 긴 이름은 피하고 애매하면 자바 라이브러리의 API 가이드를 참고하자
  • 자바 라이브러리가 너무 방대해서 일관되지 않은 이름도 많지만 대부분은 납득 가능하다

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

• 모든 메서드는 각각 자신의 소임을 다 해야한다
• 메서드가 너무 많은 클래스는 익히고, 사용하고, 문서화하고, 테스트하고, 유지보수가 어렵다
  • 인터페이스도 비슷하다
• 메서드가 너무 많으면 이를 구현하는 사람과 사용하는 사람 모두를 고통스럽게 한다
• 클래스나 인터페이스는 자신의 각 기능을 완벽히 수행하는 메서드로 제공해야 한다
• 아주 자주 쓰일 경우에만 별도의 약칭 메서드를 두기 바란다
• 확신이 서지 않으면 만들지 말자

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

• 4개 이하가 좋으며 4개가 넘어가면 매개변수를 모두 기억하기 어렵다
• 개발한 API에 이 제한을 넘는 메서드가 많다면 개발자들은 API 문서를 끼고 개발해야 할 것이다
• 같은 타입의 매개변수 여러 개가 연달아 나오는 경우가 특히 해롭다
  • 사용자가 매개변수의 순서를 기억하기 어려울뿐더러 실수로 순서를 바꿔 입력해도 그대로 컴파일되고 실행된다
    • 단지 의도와 다르게 동작할 뿐..
• 매개변수 목록을 짧게 줄여주는 세가지 기술
  1. 여러 메서드로 쪼갠다
     1. 쪼개진 메서드 각각은 원래 매개변수 목록의 부분집합을 받는다
     2. 잘못하면 메서드가 너무 많아질 수 있지만 직교성을 높여서 오히려 메서드가 줄어드는 효과도 있다
  2. 매개변수 여러 개를 묶어주는 도우미 클래스를 만들자
     1. 일반적으로 이런 도우미 클래스는 정적 멤버 클래스로 둔다
     2. 특히 잇따른 매개변수 몇 개를 독립된 하나의 개념으로 볼 수 있을 때 추천하는 기법이다
  3. 객체 생성에 사용한 빌더 패턴을 메서드 호출에 응용(앞의 두 기법을 혼합한것)
     1. 매개변수가 많은 경우, 특히 그 중 일부는 생략해도 괜찮은 경우 좋다
     2. 모든 매개변수를 하나로 추상화한 객체를 정의하고 클라이언트에서 이 객체의 세터를 호출해 필요한 값을 설정하게 하는 것
        1. 각 세터는 매개변수 하나 혹은 서로 연관된 몇 개만 설정하게 한다
     3. 클라이언트는 먼저 필요한 매개변수를 다 설정한 다음 execute 메서드를 호출해 앞서 설정한 매개변수들의 유효성을 검사한다
     4. 설정이 완료된 객체를 넘겨 원하는 계산을 수행한다

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

• 매개변수로 적합한 인터페이스가 있다면(구현한 클래스가 아닌) 그 인터페이스를 직접 사용하자
  • ex) 메서드로 넘길때 HashMap 이 아닌 Map을 보내면 HashMap, TreeMap 등 어떤 맵 구현체도 보낼수 있다
• 인터페이스 대신 클래스를 사용하면 클라이언트에게 특정 구현체만 사용 가능하도록 제한하는 모습이다
  • 혹시라도 입력 데이터가 다른 형태로 존재한다면 명시한 특정 구현체의 객체로 옮겨 담느라 비싼 복사 비용을 치뤄야 한다

boolean 보다는 원소 2개짜리 열거 타입이 낫다(메서드 이름상 boolean을 받아야 의미가 더 명확한 경우는 제외)

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