이번 아이템에서는 개별 아이템으로 두기 애매한 API 설계 요령들을 모아 설명한다.
API 설계 요령
1. 메서드 이름을 신중히 짓자.
항상 표준 명명 규칙을 따라야 한다.
같은 패키지에 속한 다른 이름들과 일관디게 짓고, 개발자 커뮤니티에서 널리 받아들여지는 이름을 하자.
애매하면 자바 라이브러리의 API 가이드를 참조하라.
2. 편의 메서드를 너무 많이 만들지 말자.
메서드가 너무 많은 클래스와 인터페이스는 익히고, 사용하고, 문서화하고, 테스트하고, 유지보수하기 어렵다.
클래스나 인터페이스는 자신의 각 기능을 완벽히 수행하는 메서드로 제공해야 하며, 아주 자주 씅리 경우에만 별도의 약칭 메서드를 두자. 확신이 서지 않으면 만들지 말자!
3. 매개변수 목록은 짧게 유지하자.
매개변수 목록은 4개 이하가 좋다.
4개가 넘어가면 매개변수를 전부 기억하기가 쉽지 않다.
📌 매개변수 수를 줄여주는 기술
1) 여러 메서드로 쪼개기
쪼개진 메서드 각각은 원래 매개변수 목록의 부분집합을 받는다.
잘못하면 메서드가 너무 많아질 수 있지만, 직교성(orthogonality)을 높여 오히려 메서드 수를 줄여주는 효과도 있다.
2) 매개변수 여러 개를 묶어주는 도우미 클래스를 만들기
일반적으로 도우미 클래스는 정적 멤버 클래스로 둔다.
잇따른 매개변수 몇 개를 독립된 하나의 개념으로 볼 수 있을 때 추천하는 기법이다.
3) 메서드 호출에 빌더 패턴을 적용하기
1번과 2번 기법을 혼합한 것으로, 매개변수가 많고 그중 일부는 생략해도 괜찮을 때 도움이 된다.
모든 매개변수를 하나의 추상화한 객체를 정의하고, 클라이언트에서 이 객체의 setter 메서드를 호출해 필요한 값을 설정하게 하는 것이다. 클라이언트에서 필요한 매개변수를 다 설정한 다음, execute 메서드를 호출해 앞서 설정한 매개변수들의 유효성을 검사하고, 설정이 완료된 객체를 넘겨 원하는 계산을 수행한다.
4. 매개변수의 타입으로는 클래스보다는 인터페이스가 더 낫다.
인터페이스 대신 클래스를 사용하면 클라이언트에게 특정 구현체만 사용하도록 제한하는 것이다. 또한, 혹시라도 입력 데이터가 다른 형태로 존재한다면 명시한 특정 구현체의 객체로 옮겨 담느라 비싼 복사 비용을 치러야 한다.
5. boolean보다는 원소 2개짜리 열거 타입이 낫다.
메서드 이름상 boolean을 받아야 의미가 더 명확할 때는 예외다.
열거 타입을 사용하면 코드를 읽고 쓰기가 더 쉬워진다.
