메서드 이름을 신중히 짓자

• 항상 표준 명명 규칙을 따르자
• 이해할 수 있고, 같은 패키지에 속한 다른 이름들과 일관되게 짓는 게 최우선 목표다
• 그 다음은 개발자 커뮤니티에서 널리 받아들여지는 이름을 사용하자
• 긴 이름을 피하자
• 애매하면 자바 API 가이드를 참조하자

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

• 메서드가 너무 많으면 클래스를 익히고 사용하고 문서화하고 테스트하고 유지보수가 어렵다
• 메서드가 너무 많으면 이를 구현사는 사람과 사용하는 사람 모두가 고통스럽다.
• 클래스나 인터페이스는 자신이 각 기능을 완벽히 수행하는 메서드로 제공하자
• 아주 자주 쓰일 경우에만 별도의 약칭 메서드로 두자.

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

• 4개 이하가 좋다. 그 이상은 기억하기 쉽지 않다
• 같은 타입의 매개 변수가 여러 개 연달아 나올 경우 쉽지 않다.
  • 실수로 순서를 바꿔도 컴파일이 된다.

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

1. 여러 메서드로 쪼갠다

쪼개진 메서드 각각은 원래 매개변수 목록의 부분집합을 받는다.

예를 들어 java.utilList 인터페이스이다.

리스트에서 주어진 원소의 인덱스를 찾아야 하는데, 전체 리스트가 아니라 지정된 범위의 부분리스트에서 인덱스를 찾는다고 가정해보자.

필요한 매개변수는

• 부분 리스트의 시작
• 부분 리스트이 끝
• 찾을 원소

총 3개가 필요하다.

하지만 List는 그대신

• subList()
• indexOf()

두 메서드를 조합하면 원하는 목적을 이룰 수 있다.

2. 도우미 메서드를 만든다

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

일반적으로 이런 도우미 클래스는 정적 멤버 클래스로 둔다.

특히 잇따른 매개변수 몇 개를 독립된 하나의 개념으로 볼 수 있을 때 추천하는 방법이다.

예를 들어 카드의 숫자와 무늬를 뜻하는 두 매개변수를 항상 같은 순서를 전달하려할 때, 이 둘을 묶는 도우미 클래스를 만들어 하나의 매개변수로 주고 받으면 깔끔해진다

3. 빌더패턴 응용

이 방법은 앞의 두 기법을 혼합한 것으로, 객체 생성에 사용한 빌더패턴을 메서드 호출에 응용한것이라고 보면 된다.

이 기법은 매개변수가 많을 때, 특히 그 중 일부는 생략해도 괜찮을 때 도움이 된다.

먼저 모든 매개변수를 하나의 추상화한 객체를 정의하고 클라이언트에서 이 객체의 세터 메서드를 호출해 필요한 값을 설정하게 하는 것이다.

이때 각 세터 메서드는 매개변수 하나 혹은 서로 연관된 몇 개만 설정하게 한다.

클라이언트는 먼저 필요한 매개변수를 다 설정한 다음, execute 메서드를 호출해 앞서 설정한 매개변수들의 유효성을 검사한다.

마지막으로, 설정이 완료된 객체를 넘겨 원하는 계산을 수행한다.

매개변수의 타입으로는 인터페이스로

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

예를 들어 HashMap 대신 Map을 사용하자, 그러면 Map의 구현체를 다 받을 수 있어, 유연해진다.

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

Boolean 대신 ENUM 타입

Boolean 타입보다는 원소 2개짜리 ENUM이 더 낫다.

열거 타입을 사용하면 코드를 읽고 쓰기가 쉽고, 나중에 선택지를 추가 하기도 쉽다.

예를 들어 화씨,섭씨 원소를 열거 타입이 있다고 가정하자.

public enum TemperatureScale { FAHRENHEIT, CELSIUS}

이 온도계 클래스를 정적 팩터리 메서드가 이 열거 타입을 입력받아 적합한 온도계 인스턴스를 생성해준다고 해보자.

Thermemeter.newInstance(true); // 이것 보단

Thermemeter.newInstance(TemperatureScale.CELSIUS); // 이게 더 낫다.

나중에 캘빈 온도도 지원한다고 한다면, 열거타입에 타입만 추가하면 된다.