Item 51. 메서드 시그니처를 신중히 설계하라
1. 들어가기
이번 Item은 API의 설계 요령으로 이 요령들을 잘 활용한다면
배우기 쉽고, 쓰기 쉬우며, 오류 가능성이 적은 API를 만들 수 있을 것입니다.
2. API 설계 요령
-
메서드 이름을 신중히 짓자.
메서드의 이름을 지을 땐 항상 표준 명명 규칙을 따라야 합니다.
-
이해할 수 있고, 같은 패키지에 속한 다른 이름과 일관되게 지어야 한다.
-
개발자 커뮤니티에서 널리 받아들여지는 이름을 사용해야 한다.
-
긴 이름은 피해야 한다.
-
-
편의 메서드를 너무 많이 만들지 말자.
메서드가 너무 많은 클래스는 이를 구현 또는 사용하는 사람 모두 힘들게 합니다.
따라서 자주 쓰일 경우에만 별도의 약칭 메서드를 두고, 확신이 서지 않는다면 만들지 맙시다.
-
매개변수 목록은 짧게 유지하자.
매개변수가 만약 4개 이상이라면 사용자가 매개변수를 기억하기 어렵게 만듭니다.
심지어 같은 타입의 여러 매개변수가 연달아 나오는 경우는 더더욱 어렵게 만듭니다.
때문에 과하게 긴 매개변수 목록을 짧게 만드는 기술 세 가지를 소개합니다.
-
여러 메서드로 쪼갠다.
잘못하면 메서드가 너무 많아질 수 있지만,
여러 메서드를 조합하면 직교성을 높여 오히려 메서드 수를 줄여주는 효과도 있습니다.
/* 가상 클래스 */ // 부분 리스트에서 원소 인덱스 조회 메서드 int indexOfSubList(int fromIndex, int toIndex, Object o);
/* java.util.List 클래스 */ // 부분 리스트 반환 메서드 List<E> subList(int fromIndex, int toIndex); // 원소 인덱스 조회 메서드 int indexOf(Object o);
-
매개변수 여러 개를 묶어주는 도우미 클래스를 만든다.
잇따른 매개변수 몇 개를 독립된 하나의 개념으로 볼 수 있을 때 추천하는 기법으로
일반적으로 이런 도우미 클래스는 정적 멤버 클래스로 둡니다.
예시로 숫자(rank)와 무늬(suit)가 있는 카드가 있습니다.
/* Before */ public void shuffle(int rank, SUIT suit) {}
/* After */ public void shuffle(Card card) {} private static class Card { int rank; SUIT suit; }
-
빌더 패턴을 응용하여 메서드를 호출한다.
매개변수가 많을 때, 특히 그 중 일부는 생략해도 괜찮을 때 추천하는 기법으로
모든 매개변수를 하나의 추상화한 객체로 정의하고,
클라이언트에서는 이 객체의 setter를 호출해 필요한 값을 설정하게 하는 것입니다.
이때 각 setter 메서드는 매개변수 하나 혹은 서로 연관된 몇 개만 설정하게 합니다.
-
-
매개변수의 타입으로는 클래스보다는 인터페이스가 더 낫다.
만약, 매개변수 타입으로 클래스를 사용한다면 특정 구현체만 사용하도록 제한하는 것으로
혹시라도 입력 데이터가 다른 형태로 존재한다면 비싼 복사 비용을 치러야 합니다.
/* TreeMap이나 ConcurrentMap을 매개변수로 사용할 수 없음 */ public void hashMapParam(HashMap<String, String> map) {}
-
boolean보다는 원소 2개짜리 열거 타입이 낫다.
열거 타입을 이용하면 코드를 읽고 쓰기가 더 쉬워집니다.
그뿐 아니라 후에 새로운 원소를 추가해야 할 때도 편리합니다.
/* boolean을 사용한 코드 */ Thermometer.newInstance(true); /* enum을 사용한 코드 */ Thermometer.newInstance(Temperaturescale.CELSIUS);
3. 정리
이번 포스트는 5가지의 API의 설계 요령에 대해 알아보았습니다.
위의 요령을 잘 숙지해 사용자가 편리한 API를 설계해봅시다.
📕 개인 기록용 블로그입니다.
😊 오타나 잘못된 정보가 있을 경우 댓글이나 메일로 말씀해주시면 바로 수정하겠습니다! 😊
댓글남기기