이번 챕터는 개별 Item으로 두기 애매한 API 설계 요령들에 대한 내용들이다.
그냥 지금까지 했던 내용들 복습하는 느낌으로 읽어도 무방
- 메서드 이름을 신중히 짓자
- 항상 표준 명명 규칙(Item 68)을 따르라.
- 이해할 수 있고, 같은 패키지에 속한 다른 이름들과 일관성을 지켜라
- 긴 이름은 피하되, 의미를 명확히 밝힐 수 없다면 차라리 긴 게 낫다.
- 개발자 커뮤니티에서 널리 받아지는 이름과 자바 라이브러리 API를 참조하라.
- 편의 메서드를 너무 많이 만들지 말자
- 메서드가 너무 많은 클래스나 인터페이스는 사용하고, 익히고, 문서화하고, 테스트하고, 유지보수하기 어렵다.
- 아주 자주 쓰일 경우에만 별도의 약칭 메서드를 두어라. 확신이 서지 않으면 만들지 마라.
- 매개변수 목록은 짧게 유지하다 (4개 이하)
- 여러 메서드로 쪼개라. 쪼개진 메서드 각각은 원래 매개변수 목록의 부분집합을 받는다.
- 메서드가 많아질 수는 있지만, 직교성(orthogonality)을 높여 줄여주는 효과도 있다.
- List 인터페이스의 부분 리스트를 반환하는 subList()와 주어진 원소의 인덱스를 알려주는 indexOf()를 별도로 제공하는 사례가 대표적이다.
- 매개변수 여러 개를 묶어주는 도우미 클래스를 만들라
- 일반적으로 도우미 클래스는 정적 멤버 클래스(Item 24)로 둔다.
- 잇따른 매개변수 몇 개를 독립된 하나의 개념으로 볼 수 있을 때 사용하라. (Address의 local, zipcode,...)
- 객체 생성에 사용한 빌더 패턴(Item 2)을 메서드 호출에 응용하라
- 매개변수는 많으나, 그 중 일부는 생략해도 괜찮을 때 좋다.
- 모든 매개변수를 하나로 추상화한 객체를 정의하고, setter 메서드로 필요한 값을 설정하라.
- 입력 후에 execute 메서드를 호출해, 설정한 매개변수들의 유효성을 검사하라
- 마지막으로, 설정이 완료도니 객체를 넘겨 원하는 작업을 수행하면 된다.
- 여러 메서드로 쪼개라. 쪼개진 메서드 각각은 원래 매개변수 목록의 부분집합을 받는다.
- 매개변수의 타입으로는 클래스보다 인터페이스가 더 낫다 (Item 64)
- 구체 클래스가 아닌 인터페이스를 받으면 메서드를 범용적으로 사용할 수 있다.
- 예를 들어, Map을 매개변수 타입으로 정하면 HashMap, TreeMap, ConcurrentHashMap 뿐 아니라, 아직 존재하지 않는 Map도 가능하다.
- boolean보다는 원소 2개짜리 열거 타입이 낫다
- Thermometer.newInstance(true)보다는 Thermometer.newInstance(TemperatureScale.CELSIUS)가 훨씬 명확하다.
- 이후 Kelvin 온도를 추가할 때도 별도의 정적 메서드 추가 필요 없이, 열거 타입에 추가하면 된다.
- 온도 단위에 대한 의존성을 개별 열거 타입 상수 메서드 안으로 리팩터링할 수도 있다. (Item 34)
- ex. double 타입 값으로 섭씨 온도로 변환하는 메서드를 열거 타입 상수 별로 정의