Item51. 메서드 시그니처를 신중히 설계하라!
Intro
- 이번 아이템에선 개별 아이템으로 두기 애매한 API 설계 요령들을 다룬다.
- 이 요령들을 잘 활용하면 배우기 쉽고, 쓰기 쉬우며, 오류 가능성이 적은 API를 만들 수 있을 것이다.
메서드 이름을 신중히 짓자
- 항상 표준 명명 규칙을 따라야 한다.
- 이해할 수 있고, 같은 패키지에 속한 다른 이름들과 일관되게 짓는 게 최우선이다.
- 개발자 커뮤니티에서 널리 쓰이는 이름을 사용하라.
- 긴 이름을 피하고, 애매하면 자바 라이브러리의 API 가이드를 참조하라.
편의 메서드를 너무 많이 만들지 말자
- 모든 메서드는 각각 자신의 소임을 다해야 한다.
- 메서드가 너무 많은 클래스는 익히고, 사용하고, 문서화하고, 테스트하고, 유지보수하기 어렵다. 인터페이스도 마찬가지다.
- 클래스나 인터페이스는 자신의 각 기능을 완벽히 수행하는 메서드로 제공해야 한다.
- 아주 자주 쓰일 때만 별도의 약칭을 사용하고, 애매하면 만들지 말자.
매개변수 목록은 짧게 유지하자
- 4개 이하가 좋다. 4개를 넘어가면 모두 기억하기 어려울 것이다.
- 같은 타입의 매개변수가 여러 개 연달아 나오는 경우가 특히 해롭다.
매개변수 목록 줄이는 기술
- 여러 메서드로 쪼갠다.
- 쪼개진 메서드 각각은 원개 매개변수 목록의 부분집합을 받는다.
- 잘못하면 메서드가 너무 많아직 수 있지만, 직교성을 높여 오히려 메서드 수를 줄여주는 효과도 있다.
- 매개변수 여러 개를 묶어주는 도우미 클래스를 만든다.
- 일반적으로 이런 도우미 클래스는 정적 멤버 클래스로 둔다.
- 잇따른 매개변수 몇 개를 독립된 하나의 개념으로 볼 수 있을 때 추천하는 기법이다.
- 예를 들어 카드게임을 클래스로 만든다고 할 때, 메서드 호출 시 카드의 숫자, 무늬를 항상 같은 순서로 받을 것이다.
- 따라서 이 둘을 묶는 도우미 클래스를 하나 만들어 매개변수로 주고 받으면 API는 물론 클래스 내부 구현도 깔끔해질 것이다.
- 객체 생성에 사용한 빌더 패턴을 메서드 호출에 응용한다.
- 매개변수가 많을 때, 특히 그중 일부를 생략해도 괜찮을 때 도움이 된다.
- 모든 매개변수를 하나로 추상화한 객체를 정의하고, 클라이언트에서 setter를 호출해 필요한 값을 설정한다.
- 세터 메서드는 매개변수 하나 혹은 필요한 몇 개만 설정하면 된다. 이후 execute 메서드를 호출해 앞서 설정한 매개변수의 유효성을 검사하고, 설정이 완료된 객체를 넘겨 원하는 계산을 수행한다.
매개변수의 타입으로는 클래스보다 인터페이스가 더 낫다
- 매개변수로 적합한 인터페이스가 있다면 (이를 구현한 클래스가 아닌) 그 인터페이스를 직접 사용하자.
- 예를 들어, 메서드에 HashMap을 넘길 일은 전혀 없다. 대신 Map을 사용하면 된다.
- 클래스를 사용하면 클라이언트에게 특정 구현체만 사용하게 제한하는 꼴이 된다.
boolean보다는 원소 2개짜리 열거 타입이 낫다
매개변수명의 의미가 중요한 경우를 제외하고는, 열거 타입을 사용하면 코드를 읽고 쓰는 데에 있어 이점을 얻는다.
나중에 선택지를 추가하기에도 용이하다.
예를 들어, 화씨 온도와 섭씨 온도를 원소로 사용한다고 하자.
1
public enum TemperatureScale { FAHRENHEIT, CELSIUS }
boolean 사용 시
1
Thermometer.newInstance(true);
enum 사용 시
1
Thermometer.newInstance(TemperatureScale.CELSIUS);
enum을 사용한 경우, 하는 일을 훨씬 명확히 파악할 수 있다. boolean의 경우, 코드만 보고는 화씨를 사용하는지 섭씨를 사용하는지 모른다.
나중에 캘빈 온도를 지원한다고 가정하자.
- 별다른 구성 없이 열거 타입에 KELVIN 정도만 추가하면 된다.
Comments powered by Disqus.