ITEM 51: 메서드 시그니처를 신중히 설계해라

# 메서드 이름을 신중히 짓자

1. 표준 명명 규칙 - ITEM 68을 따라야한다.

2. 이해할 수 있고, 같은 패키지에 속한 다른 이름과 일관되게 짓는 것이 최우선 목표이다.

3. 개발자 커뮤니티에서 널리 받아들여지는 이름을 사용하는 것이 좋다

4. 긴 이름은 피하자

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

메서드가 너무 많은 클래스는 익히고, 사용하고, 문서화하고, 테스트하고, 유지보수 하기 어렵다. 클래스나 인터페이스는 자신의 각 기능을 완벽히 수행하는 메서드로 제공해야한다. 아주 자주 사용하는 경우에만 별도의 약칭 메서드를 두고, 확신이 없으면 만들지 말자.

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

매개변수 목록은 4개 이하가 적당하다. 같은 타입의 매개변수 여러 개가 연달아 나오는 경우가 특히 좋지 않다. 매개변수 순서를 기억하기도 어려우며, 실수로 순서를 바꿔 입력해도 오류가 발생하지 않기 때문이다.

## 여러 메서드로 쪼갠다.

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

• 잘못하면 메서드가 더 많아질 수 있지만, 직교성을 높여(= 공통점이 없는 기능들을 잘 분리시켜) 오히려 메서드 수를 줄여줄 수 있다.

• java.util.List 인터페이스

## 매개변수 여러 개를 묶어주는 도우미 클래스 생성

• 주로 도우미 클래스는 정적 멤버 클래스로 생성

• 매개변수를 독립된 하나의 개념으로 볼 수 있을 때 추천

## 객체 생성에 사용한 빌더 패턴을 메서드 호출에 응용

• 매개변수가 많으면서, 그중 일부는 생략해도 괜찮을 때 도움이 된다.

• 모든 매개변수를 하나로 추상화한 객체를 정의

• 클라이언트에서 setter 메서드를 호출해 필요한 값을 설정

• execute 메서드를 호출해 앞서 설정한 매개변수들의 유효성 검사

• 설정이 완료된 객체를 넘겨 계산 수행

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

• 매개변수로 적합한 인터페이스가 있으면, 인터페이스를 직접 사용하자.

• ex) 메서드에 Map 을 사용하면, HashMap, TreeMap, ConcurrentHashMap 등 어떠한 Map 구현체도 인수로 받을 수 있다.

• 인터페이스 대신 클래스를 사용하면, 클라이언트에게 특정 구현체만 사용하도록 제한하는 것이다.

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

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

public enum TemperatureScale { FAHRENHEIT, CELSIUS }

true로 보내는 것보다 열거 타입을 사용하는 것이 훨씬 명확한 것을 볼 수 있다.

Thermometer.newInstance(true);

Thermometer.newInstance(TemperatureScale.CELSIUS);

추가로, 의존성을 개별 열거 타입 상수 메서드안에 리팩터링해서 추가할 수 있다. (ITEM 34)