Effective Java #40 메서드 시그니처는 신중하게 설계하라.

규칙 40은 API를 설계할 때 좋지만 별도 규칙으로 나눌 정도로 중요하지는 않은 팁들이다.

1. 메서드 이름은 신중하게 고르라.

모든 이름은 표준 작명 관습을 따라야 한다. 최우선 목표는 이해하기 쉬우면 서도 같은 패키지 안의 다른 이름들과 일관성이 유지되는 이름을 고르는 것이다.

2. 편의 메서드를 제공하는데 너무 열올리지 마라.

모든 메서드는 맡은 일에 명확하고 충실해야한다. 클래스에 메서드가 너무 많으면 학습, 사용, 테스트, 유지보수 등의 모든 측면에서 어렵다. 인터페이스의 경우에는 메서드가 많으면 문제가 두 배는 더 심각하다.

단축 메서드는 자주 쓰일 때만 추가하라. 그럴지 잘 모르겠다면, 빼버려라

3. 인자리스트를 길게 만들지 마라

4개 이하가 되도록 애쓰라. 대부분의 프로그래머는 인자 리스트가 길어지면 제대로 기억하지 못한다. 이 한계를 넘는 메서드가 많은 API는 문서를 계속 봐야만 사용할 수 있다. 자료형이 같은 인자들이 길게 연결된 인자리스트는 더욱 위험하다. 

긴 인자리스트를 줄이는 방법은 3가지이다. 하나는 여러 메서드로 나누는 것이다. 두 번째는 도움 클래스를 만들어 인자들을 그룹별로 나누는 것이다. 세 번째는 앞 두 방법을 결합한 것으로, 빌더 패턴을 고쳐서 객체 생성 대신 메서드 호출에 적용하는 것이다. 

4. 인자의 자료형으로는 클래스보다 인터페이스가 좋다.

예를들어 HashMap을 인자 자료형으로 사용하는 메서드를 만들 이유는 없다. Map을 사용하면 된다. 그렇게 하면 해당 메서드는 HashTable, HashMap, TreeMap 과 같은 하위 자료형, 아직 만들어 지지 않은 모든 Map 하위 클래스 객체를 인자로 받을 수 있다. 인터페이스 대신에 클래스를 사용하면 특정한 구현에 종속된다. 게다가 입력으로 이용할 데이터가 다른 형태에 객체에 보관되어 있는 경우에는변환하고 복사하는 비용까지 짊어져야한다.

5. 인자 자료형으로 boolean을 쓰는 것보다는, 원소가 2개인 enum 자료형을 쓰는 것이 낫다.