1. 메서드 이름을 시중히 짓자.

• 표준 명명 규칙을 따라야 한다(아이템 68)
• 같은 패키지에 속한 다른 이름들과 일관되게 짓는다.
• 개발자들이 흔히 많이들 사용하는 이름들을 사용하자.

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

• 한 클래스에 메서드가 너무 많으면 익숙해지는데 너무 오래걸리고, 문서화, 유지보수가 힘들다.

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

• 4개 이하가 좋다. 그 이상이면 기억하기도 힘들다.
• 특히 같은 타입의 매개변수를 연속으로 받는 메서드는 위험하다.
  사용자가 매개변수 순서를 기억하기 힘들 분더러, 의도와 다르게 동작하는데 미처 파악하지 못할 확률이 있다.

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

3-1. 여러 메서드로 쪼갠다.

• 쪼개진 메서드 각각은 원래 매개변수 목록의 부분집합을 받는다.
• 예를들어 "전체 리스트가 아니라 지정된 범위의 부분 리스트에서의 인덱스를 찾는다" 고 해보자
  이 기능을 메서드로 구현하려면
  • 부분 리스트 시작
  • 부분 리스트 끝
  • 찾을 원소
    까지 해서 총 3개의 매개변수가 필요하다.
    하지만 실제 List 에서는 subList 메서드와 주어진 원소의 인덱스를 알려주는 indexOf를 따로 제공하여 두 메서드를 조합하여 원하는 목적을 이룰 수 있다.
• 즉 메서드를 쪼개면 직교성이 증가한다.

  직교성이란
  직교성이 높으면 공통점이 없는 기능들로 잘 분리되어 있다는 뜻이다.

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

• 예를 들어 카드게임을 클래스로 만든다고 했을 때
  - 숫자(rank)
  • 무늬(suit)
    이 두 매개변수를 묶는 도우미 클래스를 묶으면 깔끔하다.

3-3. 객체 생성에 사용한 빌더 패턴을 메서드 호출에 응용한다.

• 먼저 모든 매개변수를 하나로 추상화한 객체를 정의
• 클라이언트에서 이 객체의 setter 메서드를 호출해 필요한 값을 설정하게 함.
• 이때 각 세터메서드는 매개변수 하나 혹은 연결된 몇개의 매개변수만 설정하게 한다.
• 클라이언트는 필요한 값들을 다 세팅한 후 execute 함수를 호출하여 함수의 역할을 수행한다.

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

• 예를 들어 메서드에 HashMap을 넘기기보단 Map을 넘기자.
• 인터페이스 대신 구체클래스를 넘기도록 하면 특정 구현체만 사용하도록 제한하는 꼴
• 입력 데이터를 해당 구체클래스로 옮겨담아 해당 클래스를 사용하여 비용이 비쌀 수도 있다.

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

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

public enum TemperatureScale { FAHRENHEIT, SELSIUS }

• 이 때, 확실히 Thermometer.newInstance(true) 보다는 Thermometer.newInstance(TemperatureScale.CELSIUS) 가 하는 일을 훨씬 명확히 알려준다.
• 나중에 캘빈온도도 지원해얗ㄴ다면, Thermometer에 또다른 정적 메서드를 추가할 필요도 없이 열거타입에 KELVIN 만 추가하면 된다.