[Effective Java] 51.메서드 시그니처를 신중히 설계하라

API 설계 요령

• 메서드 이름을 신중히 짓자
• 편의 메서드를 너무 많이 만들지는 말자
• 매개변수 목록은 짧게 유지하자
• 매개변수의 타입으로는 클래스보다는 인터페이스가 더 낫다
• boolean 보다는 원소 2개짜리 열거 타입이 낫다

 

메서드 이름을 신중히 짓자

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

 

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

• 메서드가 너무 많은 클래스는 익히고, 사용하고, 문서화하고, 테스트하고, 유지보수하기 어려움
• 인터페이스도 메서드가 너무 많으면 구현하는 사람과 사용하는 사람이 모두 힘들음
• 클래스나 인터페이스는 자신의 기능을 완벽히 수행하는 메서드로 제공
• 확신이 서지 않으면 만들지 말자

 

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

• 4개 이하
• 같은 타입의 매개변수 여러개가 연달아 나오는 경우가 특히 해로움 → 순서를 기억하기도 어렵고 실수로 순서를 바꿔 입력해도 그대로 컴파일되어 의도와 다르게 동작함
• 긴 매개변수 목록을 짧게 줄이자
  
  1) 여러 메서드로 쪼개기
  쪼개진 메서드 각각은 원래 매개변수 목록의 부분집합을 받음 → 잘못하면 메서드가 너무 많아질 수 있지만 직교성을 높여 오히려 메서드 수를 줄일 수 있음 (공통점이 없는 기능들이 잘 분리되는 것)
  무한정 작게 나누는것보다 API 사용자의 눈높이에 맞게, 개념의 추상화 수준에 맞게 조절해야함
  
  2) 매개변수 여러개를 묶어주는 도우미 클래스 만들기
  일반적으로 정적 멤버 클래스로 만듦 [아이템 24].
  매개변수 몇개를 독립된 하나의 개념으로 볼 수 있을 때 추천
  ex) 카드 게임에서의 카드를 전달하는 경우 카드 무늬(suit)와 숫자(rank)를 매개변수로 받을 때
  

//메서드의 매개변수를 항상 순서를 지켜 전달해야함
public class CardGame {
    public boolean compareCards(int myCardRank, Suit myCardSuit, int otherCardRank, Suit otherCardSuit){
        //생략
    }
}

public class CardGame {
    public boolean compareCards(Card myCard, Card otherCard){
        //생략
    }

    //도우미 클래스 (정적 멤버 클래스)
    public static class Card{
        private final int rank;
        private final Suit suit;
        public Card(int rank, Suit suit) {
            this.rank = rank;
            this.suit = suit;
        }
    }
}

 

3) 객체 생성에 사용한 빌더 패턴 [아이템 2]을 메서드 호출에 응용
모든 매개변수를 하나로 추상화한 객체를 정의 한 후 setter 메서드로 필요한 값을 설정.

 

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

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

예를 들어 메서드에 HashMap을 넘기게 한게 아니라 Map을 사용했다면, HashMap 뿐만 아니라 TreeMap, ConcurrentHashMap 등 어떤 Map 구현체도 넘길 수 있다.

 

 

boolean보다는 원소 2개짜리 열거 타입이 낫다

열거 타입을 사용하면 코드를 읽고 쓰기가 더 쉬워짐

나중에 선택지를 추가하기도 쉽다.

또한 메서드를 열거 타입 상수 각각에 정의해둘 수 있다.