메서드 시그니처를 신중하게 설계하라
이번 아이템은 가볍게 쓰는 '여러 API 설계 요령'이다.
사용하기 쉽고 오류가능성이 적은 API를 만들고 싶다면 유의깊게 보길!
─ 메서드 이름을 신중히 짓자.
항상 표준 명명 규칙(Item68)을 따라야 한다. 이해할 수 있고, 같은 패키지 내 다른 이름들과 일관되게 짓도록 해야 한다. 긴 이름은 피하자. 개발자들에게 잘 받아들여지는 이름을 사용하자. 자바 라이브러리의 API 가이드를 참고하자.
─ 편의 메서드를 너무 많이 만들지 말자
메서드가 너무 많은 클래스, 인터페이스는 까다롭다. (사용/문서화/테스트/유지보수... 모든 면에서!)
편의 메서드를 너무 많이 두지 말고, 자신의 각 '기능'을 완벽히 수행하는 메서드로 제공해야 한다.
아주 자주 쓰일 경우에만 편의 메서드를 두자. 확신이 서지 않으면 만들지 말아야 한다.
─ 매개변수 목록은 짧게 유지!
4개 이하가 좋다. 기억하기 쉽다.
(개발할 때마다 API 문서를 달고 살면 피곤할 것임)
- 주의점: 같은 타입의 매개변수 여러개가 연달아 나올 경우는 특히 해로울 수 있다. 순서를 기억하기 어렵고, 실수로 순서를 바꿔 입력하더라도 "그대로 컴파일되고 실행된다" 그럼 의도와 다르게 동작하여 디버깅할때 미치겠쥬
[TIP: 매개변수 목록을 짧게 줄이는 팁 세가지]
ⓐ 여러 메서드로 쪼갠다.
기본 기능으로 잘 쪼개면, 오히려 전체적으로 메서드 수를 줄여줄 수도 있겠지! 그렇게 직교성이 높은 설계는 가볍고, 구현하기 쉽고, 유연하고, 강력하다! ─ 그러나 절대적인 것은 없다. 직교성이 낮아지더라도 특정 패턴이 상당히 자주 사용되거나, 최적화하여 성능을 개선할 수 있다면 그대로 직접 구현해 넣는 것이 나을 수도 있겠지!
ⓑ 도우미 클래스를 만든다.
잇따른 매개변수 몇 개를 독립된 하나의 개념으로 볼 수 있을 때 추천!
예를들면 카드게임에서는 "숫자, 무늬"가 항상 같이 전달될 것인데, 이 둘을 묶는 클래스를 두면 깔끔하겠지!
ⓒ 객체 생성에 사용한 빌더 패턴(Item2)을 매서드 호출에 응용한다.
만약 매개변수가 많은데 일부 매개변수는 없어도 될 때 도움이 된다. 클라이언트가 파라미터를 넘겨주기 전에 객체를 setter를 통해 필요한 값을 세팅해서 유효성을 검사한 상태로 넘겨주면 된다.
─ 매개변수 타입으로는 클래스보다는 인터페이스가 낫다. (Item64)
메서드에 HashMap을 넘길 일은 전혀 없다. Map을 사용하라.
Map의 어떠한 구현체도 들어갈 수 있도록!
언제든 입력 데이터는 특정 구현체가 아닌, 다른 형태가 될 수 있다는 가능성을 열어두자.
─ boolean보다는 원소 2개짜리 열거 타입이 낫다.
열거 타입을 사용하여, 코드를 읽고 쓰기 쉬워지고, 추후 선택지를 추가하기도 쉽기 때문에 사용하자는 것이다.
주의! 명확히 boolean의 의미를 사용할 때를 이야기하는 게 아니다.
'JAVA > Effective Java' 카테고리의 다른 글
[이펙티브 자바] null이 아닌, 빈 컬렉션이나 배열을 반환하라 ─ 8장:메서드:Item54 (0) | 2023.10.18 |
---|---|
[이펙티브 자바] 가변인수는 신중히 사용하라 ─ 8장:메서드:Item53 (0) | 2023.10.18 |
[이펙티브 자바] 다중정의(오버로딩)는 신중히 사용하라 ─ 8장:메서드:Item52 (1) | 2023.10.17 |
[이펙티브 자바] 적시에 방어적 복사본을 만들라 ─ 8장:메서드:Item50 (1) | 2023.10.17 |
[이펙티브 자바] 매개변수가 유효한지 확인하라 ─ 8장:메서드:Item49 (2) | 2023.10.16 |