Youngwon

메서드

13 min read

메서드(생성자 포함)의 매개변수, 반환값 처리와 시그니처 설계, 문서화 방법을 사용성, 견고성, 유연성에 집중해 설명합니다.

아이템 49. 매개변수가 유효한지 검사하라

  • 매서드의 매개변수는 메서드의 시작부분에서 유효성을 검사해야함
    • 메서드 실행 중간에 오류가 발견된다면 모호한 예외를 던지며 실패 할 수 있음
    • 메서드가 성공적으로 실행되나 잘못된 결과를 반환할 수 있음
    • 원자성을 어기는 결과를 생성함
  • 유효성의 조건은 반드시 문서화해야함
  • 매개변수가 잘못되면 보통의 경우 다음과 같은 예외를 던짐
    • IllegalArgumentException
    • IndexOutBoundsException
    • NullPointerException
  • 문서화시 발생할 수 있는 예외도 함께 포함해야함
  • 자바 7 부터는 java.util.Objects.requireNonNull 메서드를 지원
    • null일 경우 예외 메시지를 작성가능
this.strategy = Objects.requireNonNull(strategy, "전략");
  • 자바 9 부터는 Objects에 범위 검사 기능이 추가됨
    • checkFromIndexSize
    • checkFromToIndex
    • checkIndex
  • 공개되지 않는 패키지의 메서드들은 외부에서 호출되지 않으므로 assert를 사용해 유효성을 검증
    • 실패시 AssertionError를 던짐
    • 런타임에서는 실행을 생략하므로 성능 저하가 없음

아이템 50. 적시에 방어적 복사본을 만들라

  • 악의적이든 실수든 클래스를 외부에서 오작동하게 만들 수 있음
  • 방어적 복사본은 이를 예방하는 방법
  • 다음은 외부에서 객체 내부에 접근하는 한 가지 상황임
Date start = new Date();
Date end = new Date();
Period p = new Period(start, end);
end.setYear(78);
  • Date객체는 더이상 사용해서는 안될 낡은 API, 대신 LocalDateTime 또는 ZonedDateTime을 사용
  • 이러한 상황을 방지하기 위해 생성자에서 받은 매개변수는 복사해서 맴버로 할당해야함
    • 이와 마찬가지로 내부객체를 반환할때에는 복사된 객체를 반환해야함
  • 아이템49의 유효성은 복사본을 대상으로 검사해야함
  • 매개변수가 다른사람에 의해 조작될 수 있는 타입이라면 복사본을 생성하기 위해 clone을 사용해서는 안됨
  • 메서드든 생성자든 클라이언트가 제공한 객체의 참조를 내부의 자료구조에 보관해야할 때면 항상 그 객체가 잠재적으로 변경될 수 있는지 고려해야함
    • 예로들어 외부에서 받은 객체를 내부의 Set, Map과 같은 객체에 저장된 후, 외부에서 해당 객체가 조작되면 Set이나 Map의 불변식이 깨짐

아이템 51. 메서드 시그니처를 신중히 설계하라

API 설계 요령사항

  • 메서드 이름을 신중히 짓자
    • 항상 표준 명명 규칙(아이템68)이어야함, 클래스는 대문자로 시작하는 단어의 조합, 멤버는 첫 단어만 소문자로 시작하는 등의 규칙이 이에 해당
    • 개발자들에게 널리 받아들여지는, 즉 익숙한 이름을 사용해야함
  • 편의 메서드를 너무 많이 만들지 말자
    • 메서드가 너무 많은 클래스는 익히고, 사용하고, 문서화하고, 테스트하고, 유지보수하기 힘듬
    • 인터페이스 또한 메서드가 너무 많으면 구현하는 사람이나 사용하는 사람을 고통스럽게 만듬
    • 확신이 서지 않으면 만들지 말아야함
  • 매개변수 목록은 짧게 유지하자
    • 4개 이하가 좋음
    • 같은 타입의 매개변수들이 여러개 연달아 존재하면 특히 해로움

과하게 긴 매개변수 목록을 짧게 줄여주는 기술 세 가지

  1. 여러 메서드로 쪼갬
  • 메서드가 너무 많아질수 있지만 직교성(orthogonality)을 높혀 오히려 메서드 수를 줄여주는 효과가 있음
    • java.util.List 인터페이스가 좋은예
  1. 매개변수 여러개를 묶어주는 도우미 클래스를 만드는것
  2. 빌더 패턴(아이템2)를 사용
  • 매개변수의 타입으로는 클래스보다는 인터페이스가 더 낫다(아이템64)
  • boolean보다는 원소 2개의 열거타입이 낫다

아이템 52. 다중정의는 신중히 사용하라

public class CollectionClassifier {
  public static String classify(Set<?> s) {
    return "집합";
  }
  public static String classify(List<?> lst) {
    return "리스트";
  }
  public static String classify(Collection<?> c) {
    return "그 외";
  }
  public static void main(String[] args) {
    Collection<?>[] collections = {
      new HashSet<String>(),
      new ArrayList<BigInteger>(),
      new HashMap<String, String>().values()
    };
 
    for (Collection<?> c: collections)
      System.out.println(classify(c));
  }
}
  • “집합”, “리스트”, “그 외”를 출력할것 같지만 실제로는 “그 외”만 세번 출력됨
  • 어느 메서드를 호출할 지는 컴파일타임에 정해지기 때문
    • 런타임에는 각 객체의 타입이 달라지지만 컴파일 타임에는 모두 Collection
  • 이처럼 직관과 어긋나는 이유는 재정의한 매서드는 동적으로 선택되고, 다중정의한 메서드는 정적으로 선택되기 때문

아이템 53. 가변인수는 신중히 사용하

static int sum(int... args) {
  int sum = 0;
  for (int arg: args)
    sum += arg;
  return sum;
}
  • 심각한 문제는 인수를 0개 넣어 호출하면 컴파일 타임이 아닌 런타임에 실패한다는 점
  • 또한 가변인수 메서드는 호출될 때마다 배열을 새로 하나 할당하고 초기화함(성능적 이슈)
  • 다음은 가변인수의 유션성이 필요할 때 선택할 수 있는 패턴임
  • 예를 들어 해당 메서드의 호출의 95%가 3개 이하라면 다음과 같은 코드로 성능이슈를 최소화함
    • EnumSet의 정적 팩터리도 이 기법을 사용해 열거 타입의 집합 생성 비용을 최소화함
public void foo() {}
public void foo(int a1) {}
public void foo(int a1, int a2) {}
public void foo(int a1, int a2, int a3) {}
public void foo(int a1, int a2, int a3, int... rest) {}

아이템 54. null이 아닌, 빈 컬렉션이나 배열을 반환하라

  • 컬렉션이나 배열같은 컨테이너가 비었을 때 컨테이너 대신 null을 반환하면 클라이언트에서는 null을 처리하는 코드를 추가해야함
    • 사용하기 어렵고 오류처리 코드도 늘어남
  • null대신 빈 컬렉션이나 배열을 반환해야함
  • null이 아닌 빈컨테이너를 반환하는 것은 비용상 문제가 있다고 생각할 수 있음
    • 그러나 신경 쓸 수준이 못됨
    • 빈 불변 컬렉션을 반환해서 처리 가능, 그러나 이것은 꼭 필요한 경우만 사용
      • Collections.emptyList()
      • Collections.emptySet()
  • 배열도 null이아닌 길이가 0인 배열을 반환
public Cheese[] getCheese() {
  return cheeseInStock.toArray(new Cheese[0]);
}

아이템 55. 옵셔널 반환은 신중히 하라

  • Java8 이전에는 값 반환을 할 수 없는 상황에 대해 2가지 선택사항이 있음
  • 첫 번째, 예외 발생
    • 그러나 예외는 진짜 예외적인 상황에 사용해야함(아이템 69)
    • 예외 생성에 있어 스택 추적 전체를 캡처해야하므로 비용도 만만치 않음
  • 두 번째 null 반환
    • null을 위한 별도의 코드를 작성해야함
  • 이러한 상황에서 Java8 이후에는 Optional라는 선택지가 생김
    • Optional는 T타입을 참조하거나, 또는 아무것도 없거나를 처리

Optional 생성

  • 다음은 컬렉션에서 최대값을 구해 Optional로 반환하는 코드
  • 적절한 정적 펙터리를 사용해 Optional을 반환하면 됨
public static <E extends Comparable<E>> Optional<E> max(Collection<E> c) {
  if (c.isEmpty())
    return Optional.empty();
 
  E result = null;
  for (E e : c) {
    if (result == null || e.compareTo(result) > 0)
      result = Objects.requireNonNull(e);
  }
  return Optional.of(result);
}

Optional 소비

// null일 경우 기본값을 지정가능
String lastWordInLexicon = max(words).orElse("단어 없음...");
 
// 값이 없을 시 원하는 예외를 던질 수 있음
Toy myToy = max(toys).orElseThrow(TemperTantrumException::new);
 
// 항상 그값이 채워져 있다고 가정, 없으면 예외(NoSuchElementException)
Element lastNobleGas = max(Elements.NOBLE_GASES).get();
  • 결과가 없을 수 있으며, 클라이언트가 이상황을 특별하게 처리해야한다면 Optional를 반환
  • Optional을 컬렉션의 키,값,원소나 배열의 원소로 사용하는게 적절한 상황은 거의 없음

아이템 56. 공개된 API 요소에는 항상 문서화 주석을 작성하라

  • API는 문서가 필수
  • Javadoc은 소스의 변경에 새로운 문서를 생성해줌
  • API를 올바로 문서화하려면 공개된 모든 클래스, 인터페이스, 메서드, 필드 선언에 문서화 주석을 달아야함
    • 직렬화에 대해서는 직렬화 형태에 대해 문서화해야함
    • 기본생성자는 주석을 달 방법이 없으니 공개 클래스는 기본 생성자를 사용해서는 안됨
  • 메서드용 문서화 주석에는 해당 메서드와 클라이언트 사이의 규약을 명료하게 기술해야함
    • how가 아닌 what을 기술해야함
  • 전제조건과 사후조건뿐만 아니라 부작용도 문서화필요
    • 시스템 상태에 어떠한 변화를 가져오는것인지를 의미
  • 메서드의 contract를 완벽히 기술하려면 다음의 조건
    • 모든 매게변수에 @param
    • 반환 타입이 void가 아니라면 @return
    • 발생가능한 모든 예외에 대해 @throw

Graph View