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

[kante-j]

메서드 이름을 신중히 짓자

• 이해할 수 있어야 함
• 같은 패키지에 속한 다른 이름들과 일관되게 지어야 함
• 개발자 커뮤니티에서 널리 받아들여지는 이름을 사용할 것
• 긴 이름은 피하기
• 자바 라이브러리 API 가이드 참조

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

• 메서드가 많은 클래스는 익히고, 사용하고, 문서화하고, 테스트하고, 유지보수하기 어렵다.

• 클래스나 인터페이스는 자신의 각 기능을 완벽히 수행하는 메서드로 제공해야 함

• 확신이 서지 않으면 만들지 말자.

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

4개 이하가 좋다.

4개가 넘어가면 기억하기 어렵기 때문.

• 매개변수는 적은게 좋음.

• 같은 타입의 매개변수 여러개가 연달아 나오면 최악

  • 매개변수 순서를 기억하기 어려움
  • 순서를 바꿔 입력해도 컴파일/실행이 됨. 의도와 다를 뿐

매개 변수 목록 줄이기

1. 여러 메서드로 쪼갠다.

   • 쪼개진 메서드 각각은 원래 매개변수 목록의 부분집합을 받음
   • 직교성(orthogonality)을 높여 메서드 수를 줄여주는 효과도 있음
     • java.util.List 인터페이스
     • 리스트에서 주어진 원소의 인덱스

2. 매개 변수 여러 개를 묶어주는 도우미 클래스를 만드는 것이다.

   • static member class로 만듬

   • 카드게임 예시

     • 메서드를 호출할 때 카드의 숫자와 무늬를 항상 같은 순서로 전달
     • 이 둘을 묶는 클래스를 만들어 하나의 매개변수로 주고받기.

   • // 기존 메서드
     public void method(int a, String b, String c, double d) {
     // do something
     }
     
     // Helper 클래스 생성
     class Helper {
     int a;
     String b;
     String c;
     double d;
     }
     
     public void someMethod(Helper helper) {
      // do something
     }

3. 1,2 두 기법을 혼합한 것으로 객체 생성에 사용한 빌더 패턴을 메서드 호출에 응용

   • 매개변수가 많을 때, 그 중 일부는 생략해도 괜찮을 때 사용
   • 1. 모든 매개변수를 하나로 추상화한 객체 정의
     2. 클라이언트에서 이 객체의 Setter 메서드 호출 (매개변수 하나 혹은 서로 연관된 몇 개만)
     3. 필요한 값 설정
     4. execute 메서드를 호출해 앞서 설정한 매개변수 유효성 검사
     5. 설정 완료된 객체 넘김

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

• 메서드에 HashMap을 넘길 일은 전혀 없음
  • 대신 Map 사용.
  • HashMap 뿐 아니라 TreeMap, ConcurrentHashMap, TreeMap의 부분맵 등 어떤 구현체도 가능
  • 아직 존재하지 않는 Map도 가능
• 클래스를 사용하면, 특정 구현체만 사용하도록 제한하는 꼴
• 입력 데이터가 다른 형태로 존재하면, 특정 구현체의 객체로 옮겨 담아야 함.

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

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

• 선택지 추가도 쉬워짐.

• 화씨와 섭씨를 원소로 정의

  public enum TemperatureScale{
    FAHRENHEIT,
    CELSIUS
  }

  • 온도계 클래스 정적 팩터리 메서드가 온도계 인스턴스 생성

  • Thermometer.newInstance(true) 보다 Thermometer.newInstance(TemperatureScale.CELSIUS) 가 보기 쉬움.

  • 추후 캘빈온도도 지원해야하면, 열거타입에만 추가.

  • 온도 단위에 대한 의존성을 개별 열거 타입 상수의 메서드 안으로 넣을 수도 있음.

[delta-f-kakaoent]

메서드 이름을 신중히 짓자

• 표준 명명 규칙을 따르자
  • 패키지 이름은 해당 패키지를 설명하는 8자 이하의 짧은 단어로 한다.(utilities보다는 utils)
  • 여러 단어로 구성된 이름이라면 각 단어의 첫 글자만 따서 써도 된다.(Abstract Window Toolkit -> awt)
  • 클래스와 인터페이스의 이름은 각 단어의 첫 글자만 딴 약어나 max, min처럼 널리 통용되는 줄임말을 제외하고는 단어를 줄여 쓰지 않도록 한다.
  • 약자의 경우 첫 글자만 대문자로 하는 편이 낫다(HttpUrl vs HTTPURL)
  • 타입 매개변수 이름의 경우 T(임의의 타입), E(컬렉션 원소의 타입), K, V(맵의 키와 밸류), X(예외), R(반환 타입)
  • 임의의 타입이 여러 개인 경우 T, U, V 혹은 T1, T2, T3를 사용
  • 객체를 생성할 수 있는 클래스는 단수 명사나 명사구(Thread, PriorityQueue, ChessPiece)
  • 객체를 생성할 수 없는 클래스는 복수형 명사(Collectors, Collections)

직교성(orthogonality)

• 직교성이라는 이야기가 프로그래밍 언어 설계에도 나오는데 어렵다(Orthogonality
• 결합도와 응집성이라는 개념과도 밀접한 연관이 있는 듯...