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

메서드 이름을 신중히 짓자

• 항상 표준 명명 규칙을 따를 것(item68)

• 이해하기 쉽고 같은 패키지에 속한 다른 이름들과 일관되게 짓는 게 최우선이다.

• 개발자 커뮤니티에서 널리 받아들여지는 이름을 사용한다. 자바 라이브러리의 API 가이드 참조해도 좋다.

• 긴 이름은 피하도록 한다.

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

• 클래스나 인터페이스가 제공하는 모든 메서드는 각각 자신의 역할을 완벽히 수행해야 한다.

• 메서드가 너무 많은 클래스는 익히고, 사용하고, 문서화하고, 테스트하고, 유지보수하기 어렵다.

• 아주 자주 쓰일 경우에만 별도의 약칭 메서드를 두되, 확신이 서지 않으면 만들지 않는 것이 좋다.

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

• 매개변수 목록이 4개가 넘어가면 전부 기억하기 어려우므로 4개 이하가 좋다.

• 같은 타입의 매개변수 여러 개가 연달아 나오는 경우, 실수로 순서를 바꿔 입력해도 정상적으로 컴파일되어 실행될 위험이 있다.

• 과하게 긴 매개변수 목록을 짧게 줄이는 방법

  • 방법 1) 여러 메서드로 쪼개고, 쪼개진 메서드 각각은 원래 매개변수 목록의 부분집합을 받는다.

  • 방법 2) 매개변수 여러 개를 묶어주는 도우미 클래스(ex. 정적 멤버 클래스)를 만든다. 매개변수 여러개를 독립된 하나의 개념으로 볼 수 있을 때 추천하는 방식이다.

  • 방법 3) 위의 두 방법을 혼합한 것으로, 객체 생성에 사용한 빌더 패턴을 메서드 호출에 응용한다. 매개변수가 많고, 그중 일부는 생략해도 괜찮을 때 사용한다. 모든 매개변수를 하나로 추상화한 객체를 정의하고, setter를 사용해 필요한 값을 설정한다. 이후 execute 메서드를 호출해 매객변수들의 유효성을 검사하고 객체를 매개변수로 넘긴다.

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

• 매개변수로 적합한 인터페이스가 있다면 구현 클래스보다는 인터페이스를 직접 사용하도록 한다.

• 인터페이스 대신 클래스를 사용하면 클라이언트에게 특정 구현체만 사용하도록 제한하므로, 혹시라도 입력 데이터가 다른 형태로 존재한다면 명시한 특정 구현 클래스의 객체로 옮겨 담느라 비싼 복사 비용이 필요하다.

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

• 메서드 이름 상 boolean 받아야 의미가 명확할 때에는 boolean을 사용한다.

• 그 외의 경우는 열거 타입을 사용하면 코드를 읽고 쓰기가 더 쉬워지며, 나중에 선택지를 추가하기도 쉽다.