Effective Java 3/E - 8장 메서드 요약정리

8장 메서드

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

• 메서드 몸체가 실행되기 전에 매개변수를 확인하면 잘못된 값이 넘어왔을 때 즉각적이고 깔끔한 방식으로 예외를 던질 수 있다.
• 자바 7에 추가된 java.util.requireNonNull 메서드는 유연하고 사용하기도 편하니, 더 이상 null 검사를 수동으로 하지 않아도 된다.
• 메서드나 생성자를 작성할 때 그 매개변수들에 어떤 제약이 있을지 생각해야 하고 그 제약들은 문서화하고 코드 시작 부분에서 명시적으로 검사해야 한다.

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

• 클라이언트가 여러분의 불변식을 깨뜨리려 혈안이 되어 있다고 가정하고 방어적으로 프로그래밍해야 한다.
• 가변 필드를 생성자 매개변수로 받아 클래스 필드에 저장하는 경우 각각을 방어적으로 복사해야 한다.
• Date는 낡은 API이니 새로운 코드를 작성할 때는 더 이상 사용하면 안된다.
• 매개변수의 유효성 검사를 하기 전에 방어적 복사본을 만들고 이 복사본으로 유효성을 검사해야 한다.
• 매개변수가 제3자에 의해 확장될 수 있는 타입이라면 방어적 복사본을 만들 때 clone을 사용해서는 안 된다.
• 가변 필드를 반환하는 get 접근자 메서드에서는 가변 필드의 방어적 복사본을 반환하도록 해야 한다.

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

메서드 이름을 신중히 짓자

이해할 수 있고 같은 패키지에 속한 다른 이름들과 일관되게 짓는 게 최우선 목표다.

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

메서드가 너무 많으면 학습, 문서화, 테스트, 유지보수하기 어렵다.

매개변수 목록은 짧게 유지하자. 4개 이하가 좋다.

• 과하게 긴 매개변수 목록을 짧게 줄여주는 기술 세 가지
  • 여러 메서드로 쪼갠다. (직교성을 높인다)
    • 예) List 인터페이스에서 지정된 부분 범위의 부분리스트에서 인덱스를 찾는 메서드를 별도로 제공하지 않고 subList, indexOf를 제공한 것
  • 매개변수 여러 개를 묶어주는 도우미 클래스를 만든다.
    • 예) class Point { int x; int y; }
  • 객체 생성에 사용한 빌더 패턴을 메서드 호출에 응용한다.
• 매개변수 타입으로는 클래스보다는 인터페이스가 더 낫다.
• boolean보다는 원소 2개짜리 열거 타입이 낫다.

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

• 다중정의(overloading)은 어느 메서드를 호출할지가 컴파일타임에 정해진다. 재정의(override)한 메서드는 동적으로 선택되고, 다중정의한 메서드는 정적으로 선택된다.
• API 사용자가 매개변수를 넘기면서 어떤 다중정의 메서드가 호출될지를 모른다면 프로그램이 오동작하기 쉽다. 다중정의가 혼동을 일으키는 상황을 피해야 한다.
• 안전하고 보수적으로 가려면 매개변수 수가 같은 다중정의는 만들지 말자.
  • 다중정의하는 대신 메서드 일므을 다르게 지어주는 방법이 있다.
• 다중정의된 메서드들이 함수형 인터페이스를 인수로 받을 때 비록 서로 다른 함수형 인터페이스라도 인수 위치가 같으면 혼란이 생긴다. 따라서 메서드를 다중정의할 때 서로 다른 함수형 인터페이스라도 같은 위치의 인수로 받아서는 안된다.
• 프로그래밍 언어가 다중정의를 허용한다고 해서 다중정의를 꼭 활용하란 뜻은 아니다.

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

<인수가 1개 이상이어야하는 가변인수 메서드 - 잘못 구현한 예!>

static int min(int... args) {
    if (args.length == 0) {
        throw new IllegalArgumentException("인수가 1개 이상 필요합니다.");
    }
    int min = args[0];
    for (int i = 1; i < args.length; i++) {
        if (args[i] < min)
            min = args[i];
    return min;
    }
}

• 가장 심각한 문제는 인수를 0개만 넣어 호출하면 런타임에 실패한다는 점. (코드도 지저분함) args 유효성 검사를 명시적으로 해야한다.

<인수가 1개 이상이어야할 때 가변인수를 제대로 사용하는 방법>

static int min(int firstArg, int... remainingArgs) {
    int min = firstArgs;
    for (int arg : remainingArgs)
        if (arg < min)
            min = arg;
    return min;
}

성능에 민감한 경우

• 가변인수 메서드는 호출될 때마다 배열을 새로 하나 할당하고 초기화하여 성능이 민감한 경우 문제가 될 수 있다.

• 가변인수의 유연성이 필요할 때 선택할 수 있는 패턴

  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을 반환하는게 성능상 낫다는 주장도 있으나 틀린 주장이다.
  • 이 정도의 성능 차이는 신경 쓸 수준이 못 된다.
  • 빈 컬렉션과 배열을 굳이 새로 할당하지 않고도 반환할 수 있다.
• 빈 컬렉션 할당이 성능을 눈에 띄게 떨어뜨리는 방법
  • Collections.emptyList, Collections.emptySet, Collections.emptyMap
• 배열을 쓸 대도 절대 null을 반환하지 말고 길이가 0인 배열을 반환하라.

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

옵셔널의 장점

옵셔널을 반환하는 메서드는 예외를 던지는 메서드보다 유연하고 사용하기 쉬우며, null을 반환하는 메서드보다 오류 가능성이 작다.

옵셔널 사용 시 주의점

• 옵셔널을 반환하는 메서드에서는 절대 null을 반환하지 말자, 옵셔널을 도입한 취지를 완전히 무시하는 행위다.

• 반환값으로 옵셔널을 사용한다고 무조건 득이 되는 건 아니다. 컬렉션, 스트림, 배열, 옵셔널 같은 컨테이너 타입은 옵셔널로 감싸면 안된다.

옵셔널을 메서드 반환 타입으로 사용해야 하는 경우

결과가 없을 수 있으며 클라이언트가 이 상황을 특별하게 처리해야 하는 경우

• 박싱된 기본 타입을 담은 옵셔널을 반환하지 말고 int, long, double 전용 옵셔널 클래스인 OptionalInt, OptionalLong, OptionalDouble을 사용하자.

• 옵셔널을 컬렉션의 키, 값, 원소나 배열의 원소로 사용하는게 적절한 상황은 거의 없다.

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

• API를 쓸모 있게 하려면 잘 작성된 문서도 곁들여야 한다.
• API를 올바로 문서화하려면 공개된 모든 클래스, 인터페이스, 메서드, 필드 선언에 문서화 주석을 달아야 한다.
• 메서드용 문서화 주석에는 해당 메서드와 클라이언트 사이의 규약을 명료하게 기술해야 한다.
  • how가 아닌 what을 기술해야 한다.
• 자기사용 패턴은 자바 8에 추가된 @impleSpec 태그로 문서화한다.
• 열거 타입을 문서화할 때는 상수들에도 주석을 달아야 한다.
• 애너테이션 타입을 문서화할 때는 멤버들에도 모두 주석을 달아야 한다.
• 클래스 혹은 정적 메서드가 스레드 안전하든 아니든, 스레드 안전 수준을 반드시 API 설명에 포함해야 한다.