[이펙티브 자바] 8장 : 메서드

메서드의 매개변수와 반환값은 어떻게 처리하는지

메서드 시그니처는 어떻게 설계 해야 하는지

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

메서드와 생성자 대부분은 입력 매개변수 값이 특정 조건을 만족하기를 바란다.

• 예를 들어 인덱스 값은 음수로 넘어오면 안되고, 객체참조는 null이 아니여야만 한다.

또한 잘못되었을 때 발생하는 예외를 문서화하여 남겨놔야한다.

requiredNonNull과 assert를 통해 매개변수 유효성 검사를 할 수 도 있다.

유효성 검사를 통해 후에 생길 수 있는 에러를 조기에 찾을 수 있다.

• 메서드는 최대한 범용적으로 설계하라. 제약으로 인해 본래의 기능을 못해서는 안된다.

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

클라이언트가 불변식을 깨뜨리려한다고 생각하고 ‘방어적으로 프로그래밍' 해라.

불변 객체 내부에 가변 객체 멤버를 가진 경우

public Period(Date start, Date end) {
        if (start.compareTo(end) > 0)
            throw new IllegalArgumentException(
                    start + "가 " + end + "보다 늦다.");
        this.start = start;
        this.end   = end;
    }

    public Date start() {
        return start;
    }
    public Date end() {
        return end;
    }

    public String toString() {
        return start + " - " + end;
    }

내부의 가변 객체로 인해 외부에서 불변식이 무너질 수 있다. (Date())

이를 해결하기 위해서는

1. 가변 내부 객체를 불변 객체로 변화시키기 (자바 8의 불변 내부 객체 사용해서 해결 LocalDateTime)
2. 가변 내부 객체를 대신할 복사본을 만들어서 객체에서 사용하기 (외부와 객체를 공유하지 않음)

• 해결 코드

		public Period(Date start, Date end) {
        this.start = new Date(start.getTime());
        this.end   = new Date(end.getTime());

        if (this.start.compareTo(this.end) > 0)
            throw new IllegalArgumentException(
                    this.start + "가 " + this.end + "보다 늦다.");
    }

    // 코드 50-5 수정한 접근자 - 필드의 방어적 복사본을 반환한다. (305쪽)
    public Date start() {
        return new Date(start.getTime());
    }

    public Date end() {
        return new Date(end.getTime());
    }

-핵심정리-

클라이언트로부터 받는 요소, 반환 요소가 가변이라면 반드시 방어적으로 복사하자.

만약, 비용이 크거나 사용자를 신뢰한다면 방어적 복사대신 요소 수정 시 책임이 사용자에게 있음을 명시해두자.

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

API 설계 요령

1. 메서드 이름을 신중히 짓자
   1. 같은 패키지에 속한 이름과 일관되게 짓고 자바 라이브러리 가이드 참조할 것
2. 편의 메서드를 너무 많이 만들지 말자
   1. 메서드가 많으면 구현하는 사람 사용하는 사람 모두 힘들다. 확신이 없다면 만들지 말자
3. 매개변수 목록은 짧게 유지하자.
   1. 같은 타입의 매개변수가 연달아 나오는 경우 특히 해롭다 (각각의 뜻을 이해하기 어려워짐)
   • 메서드 쪼개기, 헬퍼 클래스, 빌더 패턴 사용해서 짧게 만들자
4. 매개변수 타입으로는 클래스보다 인터페이스가 낫다
   1. 훨씬 범용적으로 인자를 받아올 수 있다. 인터페이스 자식과 이후에 만들어질 객체들까지도 가능!! 만약 클래스를 사용한다면 메서드 사용을 위해 특정 클래스로의 복사 비용을 치뤄야 한다.
5. boolean보다는 원소 2개짜리 열거 타입이 낫다.
   1. 물론, 메서드 이름상 boolean 더 명확한 경우는 예외
   2. 열거 타입이 코드를 읽기 더 쉽고 나중에 선택지를 추가하기도 쉽다.온도계 클래스의 정적 팩터리 메서드가 이 열거 타입을 입력받아 적합한 온도계 인스턴스를 반환한다고 해보자.
   3. ‘Thermometer.newInstance(true)’ 보다는 ‘Thermometer.newInstance(TemperatureScale.CELSIUS)’ 가 훨씬 명확하다.
   4. public enum TemperatureScale { FAHRENHEIT, CELSIUS }

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

다중정의(오버로딩) 메서드 중 어느 메서드를 호출할지는 컴파일타임에 결정된다.

public class CollectionClassifier {
  	public static String classify(Set<?> s) {
      	return "집합";
    }
  	
  	public static String classify(Collection<?> c) {
      	return "그 외";
    }
  
  	public static void main(String[] args) {
      	Collection<?>[] collections = { new Hashset<String>(), new ArrayList<String>() };
      
      	for (Collection<?> c : collections)
          	System.out.println(classify(c)); // "그 외  그 외" 컴파일타임에 메서드 결정
    }
}

따라서 인수가 컬렉션일 때 어떤 메서드가 실행될지는 컴파일 타임에 결정되게 되고 어떤 구현체인지에 상관없이 “그 외"값이 나오게 된다.

재정의(오버라이딩)은 이와 달리 런타임에 동적으로 메서드가 선택된다.

class Wine {
  	String name() { return "와인"; }
}

class SparklingWine extends Wine {
  @Override String name() { return "스파클링와인"; }
}

public class Overriding {
  	public static void main(String[] args) {
      	List<Wine> wineList = List.of(new Wine(), new SparklingWine());
      
      	for (Wine wine : wineList) {
          	System.out.println(wine.name()); // "와인 스파클링와인" 가장 하위에서 정의한 메서드 호출
        }
    }
}

각각의 타입에 맞게 정의한 메서드가 실행되게 된다.

다중정의가 혼돈을 일으키는 상황을 피하자.

• 매개변수 수가 같은 오버로딩은 하지말자
• 가변인수를 사용하는 메서드는 아예 다중정의 하지말자
• 오버로딩 대신 메서드 이름을 다르게 지어주자

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

인수의 갯수를 당장 정할 순 없지만 하나이상 받는 것을 보장받고 싶다면 아래처럼 하라

static int min(int firstArg, int... remainingArgs) { // 하나 이상의 매개변수를 받아야 함
  	int min = firstArg;
  	for (int arg : remainingArgs)
      	if (arg < min)
          	min = arg;
    return min;
}

가변 인수를 사용하면 성능이 안좋아질 수 있다. 많이 쓰는 경우까지 오버로딩을 통해 인수 갯수를 보장해주고 적은 사용까지 보장하기 위해 가변 인수를 사용하면 특수상황도 해결 가능하다.

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

만약 컬렉션이나 배열이 비어있다면 null이 아닌 빈 객체를 반환하라.

null을 반환하면 이를 받는 쪽에서 null인지 검사하는 방어 코드가 필요하고 이를 빼먹으면 오류가 발생한다.

null을 반환하는 API는 사용하기 어렵고 오류 처리 코드도 늘어난다.

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

옵셔널은 원소를 최대 1개 가질 수 있는 불변 컬렉션이다.

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

옵셔널을 반환하는 메서드에서는 절대 null을 반환하지 말자.

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);
    }

옵셔널 정적 팩터리를 사용하여 반환.

옵셔널은 검사 예외와 취지가 비슷하다

• 반환값이 없을 수도 있음을 API사용자에게 알려준다.
• 클라이언트에게 값을 받지 못했을 때 취할 행동을 작성하도록 한다.

컬렉션, 스트림, 배열, 옵셔널 같은 컨테이너 타입은 옵셔널로 감싸지말자

• 대신 빈 컨테이너를 반환하자.

반환 타입을 Optional<T>로 해야하는 경우

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

박싱타입은 성능이 안좋아지는 Optional에 담지말고 기본타입을 사용하자.

-핵심정리-

옵셔널은 거의 반환값으로 사용하고 이외의 용도는 잘 사용하지 않는다. 성능 이슈가 있을 수 있으니 신중히 사용하자.

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

API를 올바로 문서화하려면 공개된 모든 클래스, 인터페이스, 메서드, 필드 선언에 문서화 주석을 달아야 한다.

표준 규약을 일관되게 지키자.