메서드 시그니처를 신중히 설계하라 - [8장. 메서드(아이템51)]

  이번 글을 통해 API 설계 요령들을 살펴보자. 이를 활용하면 배우기 쉽고, 쓰기 쉬우며, 오류 가능성이 적은 API를 만들 수 있을 것이다.

 

📙 1. 메서드 이름을 신중히 짓자.

  메서드 이름을 신중히 짓는 것에 대해서는 너무나 많이 들어봤을 것이다. 알고 있는 것을 한번 더 상기시킨다는 생각으로 보고 넘어가자.

• 항상 표준 명명 규칙을 따라야 한다.
• 이해할 수 있고, 같은 패키지에 속한 다른 이름들과 일관되게 짓자.
• 개발자 커뮤니티에서 널리 받아들여지는 이름을 사용하자.
• 긴 이름을 피하자.
• 애매하면 자바 라이브러리의 API 가이드를 참조하자.

 

📙 2. 편의 메서드를 너무 많이 만들지 말자.

  메서드가 너무 많은 클래스는 익히고, 사용하고, 문서화하고, 테스트하고, 유지보수하기 어렵다. 인터페이스도 마찬가지다. 클래스나 인터페이스는 자신의 각 기능을 완벽히 수행하는 메서드로 제공하도록 하자. 확신이 서지 않으면 만들지 말자!

 

📙 3. 매개변수 목록은 짧게 유지하자.

  4개 이하가 좋다. 특히, 같은 타입의 매개변수 여러 개가 연달아 나오게 하지 말자. 이는 사용자가 매개변수 순서를 기억하기 어렵게 하고, 실수로 순서를 바꿔 입력해도 그대로 컴파일되기 때문이다.

  과하게 긴 매개변수 목록을 짧게 줄여주는 기술 3가지는 다음과 같다.

1. 여러 메서드로 쪼갠다.
     잘못하면 메서드가 너무 많아질 수 있지만, 직교성(orthogonality, 공통점이 없는 기능들이 잘 분리되어 있는 것)을 높여 오히려 메서드 수를 줄여주는 효과도 있다.
2. 매개변수 여러 개를 묶어주는 도우미 클래스를 만드는 것이다.
     카드 클래스에 숫자(rank)와 무늬(suit)를 뜻하는 두 매개변수가 포함되어 있는 것을 생각하면 된다.
3. 객체 생성에 사용한 빌더 패턴을 메서드 호출에 응용한다.
     클라이언트는 객체를 정의하고, 필요한 값만 설정하면 된다.

 

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

  매개변수로 적합한 인터페이스가 있다면 (이를 구현한 클래스가 아닌) 그 인터페이스를 직접 사용하자.

  예를 들어, HashMap을 넘기는 것이 아니라 Map을 사용하는 것이다. 그러면 TreeMap, ConcurrentHashMap, TreeMap의 부분맵 등 다양한 Map 구현체를 인수로 사용할 수 있다.

 

📙 5. 매개변수의 타입으로는 boolean보다는 원소 2개짜리 열거 타입이 낫다.

  열거 타입을 사용하면 코드를 읽고 쓰기가 더 쉬워진다. 그리고 선택지를 추가하기도 쉽다.

  온도계 클래스의 정적 팩터리 메서드가 인수를 통해 적합한 온도계 인스턴스를 생성한다고 해보자.

// boolean을 사용하는 경우
Thermometer.newInstance(true)

// 열거 타입을 사용하는 경우
public enum TemperatureScale { FAHRENHEIT, CELSIUS }
Thermometer.newInstance(ThmperatureScale.CELSIUS)

  열거 타입을 이용하면 훨씬 더 의미가 명확해진다. 그리고 온도 타입으로 캘빈온도(KELVIN)도 추가할 수 있다.

  물론 메서드 이름상 boolean을 받아야 의미가 더 명확할 때는 예외 상황이다.

 

해당 글은 Joshua Bloch 님의 'Effective Java 3/E'를 참고하였습니다.