수학과의 개발자 도전기

요약

1. 스트림에서는 부작용 없는 함수(순수 함수)를 사용하고, 스트림뿐 아니라 스트림 관련 객체에 전해지는 모든 함수 객체가 부작용이 없어야 한다.
2. 스트림을 올바르게 사용하려면 수집기를 잘 알아두자.
   1. 가장 중요한 수집기 팩터리 : toList, toSet, toMap, groupingBy, joining

스트림 패러다임

스트림은 함수형 프로그래밍에 기초한 패러다임이므로, 계산을 일련의 변환으로 재구성하는 부분이 가장 중요하다. 각 변환 단계는 가능한 한 이전 단계의 결과를 받아 처리하는 순수함수여야 한다.

순수 함수

순수 함수란 오직 입력만이 결과에 영향을 주는 함수를 의미한다.

1. 다른 가변 상태를 참조하지 않는다
2. 함수 스스로도 다른 상태를 변경하지 않는다

잘못된 스트림 코드

Map<String, Long> freq = new HashMap<>();
try(Stream<String> words = new Scanner(new File("pathname")).tokens()) {
    words.forEach(word -> {
    freq.merge(word.toLowerCase(), 1L, Long::sum);
	});
}

• 위 코드는 종단연산인 forEach에서 모든 작업이 일어나는데, 이 때 외부 상태인 freq을 수정하는 람다를 실행하면서 문제가 발생한다.
• 이는 스트림 API의 이점을 활용하지 못한 뿐 아니라, 가독성도 안 좋고, 유지보수에도 좋지 않은 코드이다.

수집기(collector)

축소 전략을 캡슐화한 블랙박스 객체이다. 수집기가 생성하는 객체는 일반적으로 컬렉션이다. 수집기를 사용하면 스트림의 원소를 손쉽게 컬렉션으로 모을 수 있다.

→ 스트림 원소들을 하나로 취합하는 객체

• 수집기 종류
  • toList()
    • 리스트 반환
  • toSet()
    • 집합 반환
  • toCollection(collectionFactory)
    • 지정한 컬렉션 타입 반환
• 예시
  • freq 에서 가장 흔한 단어 10개를 뽑아내는 파이프라인

  List<String> topTen = freq.keySet().stream()
  	.sorted(comparing(freq::get).reversed()) // 내림차순 정렬
  	.limit(10) // 상위 10개
  	.collect(toList()); // 리스트 반환
  

  • comparing(freq::get).reversed()
    • comparing() : 추출된 키들을 비교하는 함수
    • freq::get : freq의 각 key에 해당하는 value 반환
    • reversed() : comparing을 역순으로 정렬
    • collect(toList()) : 리스트 반환

toList(), toSet(), toCollection 외에 더 많은 Collectors 메서드들을 알아보자.

toMap()

toMap()에도 3가지 종류가 있다.

1. toMap(keyMapper, valueMapper)

스트림 원소를 키에 매핑하는 함수와 값에 매핑하는 함수를 인수로 받는다. 이 toMap 형태는 스트림의 각 원소가 고유한 키에 매핑되어 있을 때 적합하다.

• 예시
  • toMap 수집기를 사용해 열거형의 모든 요소를 문자열로 변환하고, 변환된 문자열을 키로 사용해 해당 열거형의 값을 맵으로 만든다.
  • {enum : enum 값}

private static final Map<String, Operation> stringToEnum = 
	Stream.of(values()).collect(
			toMap(Object::toString, e -> e));

2. 파라미터 3개인 toMap()

이 toMap()은 어떤 키와 그 키에 연관된 원소들 중 하나를 골라 연관 짓는 맵을 만들 때 유용하다. 추가로 인수가 3개인 toMap은 충돌이 나면 마지막 값을 취하는 수집기를 만들 때도 유용하다. (혹시나 있을 키 충돌을 해결해줄 수 있다)

• 예시1
  • 다양한 아티스트의 앨범들을 담은 스트림에서 음악가와 그 음악가의 베스트 앨범(판매량이 가장 많은)을 연관 지을 때

  Map<Artist, Album> topHits = albums.collect(
  	toMap(Album::artists, a->a, maxBy(comparing(Album::sales))));
  

  → 앨범 스트림을 맵으로 바꾸는데, 이 맵은 각 음악가와 그 음악가의 베스트 앨범을 짝지은 것이다.
• 예시2 - 마지막에 쓴 값을 취하는 수집기
• toMap(keyMapper, valueMapper, (oldVal, newVal) -> newVal);

3. 네번째 인수로 맵 팩터리를 받는 toMap()

세번째 인수는 2번 toMap()과 동일하나, 네번째 인수로는 EnumMap이나 TreeMap처럼 원하는 특정 맵 구현체를 직접 지정할 수 있다.

toMap(keyMapper, valueMapper, (oldVal, newVal) -> newVal, 특정 맵 구현체 지정);

groupingBy

groupingBy 메서드는 입력으로 분류 함수를 받고, 출력으로는 원소들을 카테고리별로 모아 놓은 맵을 담은 수집기를 반환한다.

1. 분류 함수 하나를 인수로 받는 groupingBy

{카테고리 : [카테고리에 속하는 원소들]} 형태의 맵을 반환한다.

• 예시 - 애너그램 만드는 코드
  • 알파벳화한 단어를 알파벳화 결과가 같은 단어들의 리스트로 매핑하는 맵 생성
  • {알파벳 조합 : [단어1, 단어2,,,]}

  words.collect(groupingBy(word -> alphabetize(word)))
  

2. 리스트 이외의 맵을 생성하는 groupingBy

groupingBy가 반환하는 수집기가 리스트 외의 값을 갖는 맵을 생성하게 하려면, 분류 함수와 함께 다운스트림 수집기도 명시해야 한다.

• groupingBy(분류 함수, 다운 스트림)
  • 다운 스트림
    • toSet() : 집합을 갖는 맵 생성
    • toCollection : 지정한 컬렉션을 값으로 갖는 맵을 생성
    • counting() : {카테고리 : 카테고리 원소 개수} 처럼 각 카테고리(키)를 해당 카테고리에 속하는 원소 개수를 매핑한 맵을 얻을 수 있다.

joining

원소들을 특정 조건 하에 연결하는 함수이다. 이 메서드는 문자열 등의 CharSequence 인스턴스의 스트림에만 적용할 수 있다.

1. 매개변수가 없는 joining()

단순히 원소들을 연결하는 수집기를 반환한다. (문자들 하나로 붙임)

2. 매개변수 하나인 joining(,)

CharSequence 타입의 구분문자를 매개변수로 받는다. 구분 문자를 연결 부위에 삽입한다. 예시로 구분문자로 쉼표(,)를 입력하면 CSV 형태의 문자열을 만들어 준다.

3. 매개변수 3개인 joining

이 joining은 구분문자에 더해 접두문자(prefix)와 접미문자(suffix)도 받는다. 예를 들어 접두, 구분, 접미 문자를 각각 ‘[’, ‘,’ , ‘]’로 지정하여 얻은 수집기는 [came,saw,conquered]처럼 마치 컬렉션을 출력한 듯한 문자열을 생성한다.

요약

람다를 사용하면 좋을 때와 좋지 않을 때를 구별해 잘 사용한다면 효율적으로 구현할 수 있다. 그럼 언제가 람다를 사용하기 좋고, 안 좋을까?

람다를 사용해야할 때

람다는 코드가 깔끔해지고, 어떤 동작을 하는지가 명확하게 드러나기에 익명 클래스보다 사용이 권장된다.

람다를 사용하면 안될 때

• 람다 코드가 길어지는 경우
• 추상 클래스의 인스턴스를 만들어야하는 상황
• 추상 메서드가 여러 개인 인터페이스 인스턴스를 만드는 상황
• this를 사용해 자신을 참조해야하는 상황

함수 객체

함수 객체는 예전에는 자바에서 함수 타입을 표현할 때, 추상 메서드를 하나만 담은 인터페이스의 인스턴스를 의미한다.

익명 클래스로 함수 객체 구현

Collections.sort(words, new Comparator<String>() {
    public int compare(String s1, String s2) {
	    return Integer.compare(s1.length(), s2.length());
	}
});

• Comparator 인터페이스가 정렬을 담당하는 추상 전략을 의미
• 문자열을 정렬하는 구체적인 전략을 익명 클래스로 구현
• 하지만 코드가 너무 길어서 자바에는 적합한 방식이 아니었다

람다식

람다식은 짧게는 람다로 불리며, 함수형 인터페이스(추상 메서드 하나짜리 인터페이스)의 인스턴스를 의미한다.

// case1
Collections.sort(words, (s1, s2) -> Integer.compare(s1.length(), s2.length()));

// case2
Collections.sort(words, comparingInt(String::length));

// case3
words.sort(comparingInt(String::length));

• 코드가 간단해짐
• 어떤 동작을 하는지가 명확하게 드러남

타입 추론

위 람다 코드를 보면 람다의 반환값 타입이 명시되어 있지 않다. 이는 컴파일러가 문맥 타입을 추론해줬기 때문이다. 대부분의 경우 컴파일러가 타입 추론을 할 수 있지만, 안되는 경우에는 프로그래머가 직접 명시해야한다. 하지만 타입 추론은 복잡하기 때문에 타입을 명시해 명확하게 처리해야 할 때(컴파일러가 “타입을 알 수 없다”는 오류를 낼 때) 빼고는 람다의 모든 매개변수 타입은 생략하는 것을 권장한다.

추가로 컴파일러가 타입 추론을 용이하게 할 수 있도록 제네릭 사용을 권장한다.

람다 예시 - 열거 타입

람다를 이용하면 열거 타입의 인스턴스 필드를 이용하는 방식으로 상수별로 다르게 동작하는 코드를 쉽게 구현할 수 있다.

• 이전 버전 - 상수별 클래스 몸체

public enum Operation {
    PLUS {
       public double apply(double x, double y) { return x + y; }
    }
    MINUS {
     ....
    }
    
    private final String symbol;
    private final DoubleBinaryOperator op;

    Operation(String symbol, DoubleBinaryOperator op) {
        this.symbol = symbol;
        this.op = op;
    }
    
    @Override
    public String toString() { return symbol; }
    
    public double apply(double x, double y) {
        return op.applyAsDouble(x, y);
    }
}

• 람다 적용

public enum Operation {
    PLUS ("+", (x, y) -> x + y),
    MINUS ("-", (x, y) -> x - y);
    
    private final String symbol;
    private final DoubleBinaryOperator op;

    Operation(String symbol, DoubleBinaryOperator op) {
        this.symbol = symbol;
        this.op = op;
    }
    
    @Override
    public String toString() { return symbol; }
    
    public double apply(double x, double y) {
        return op.applyAsDouble(x, y);
    }
}

• 열거 타입 상수의 동작을 람다로 구현해 생성자에 넘기고
• 생성자는 해당 람다를 인스턴스 필드로 저장한다
• apply 메서드에서 필드에 저장된 람다를 호출하기만 하면 된다

→ 원래 버전보다 코드가 간결해지고, 깔끔해진다.

열거 타입에서 람다 장점

• 원래 버전보다 코드가 간결해지고, 깔끔해진다

열거 타입에서 람다 단점

• 람다는 이름이 없고, 문서화도 못한다
  • 코드 자체로 동작이 명확히 설명되지 않거나 코드가 길어지면 람다를 사용하면 안된다
• 열거 타입 생성자 안의 람다는 열거 타입의 인스턴스 멤버에 접근할 수 없다
  • 인스턴스는 런타임에 만들어지기 때문

→ 상수별 동작을 단 몇 줄로 구현하기 어렵거나, 인스턴스 필드나 메서드를 사용해야만 하는 상황이라면 상수별 클래스 몸체를 사용해야한다.

람다 vs 익명 클래스

람다는 익명 클래스보다 적은 코드로 깔끔하고, 명확하게 코드를 작성할 수 있게 해주지만 다음과 같은 경우에는 람다보단 익명 클래스를 사용하는 것이 더 나을 수 있다.

1. 추상 클래스의 인스턴스를 만들 때
2. 추상 메서드가 여러 개인 인터페이스의 인스턴스를 만들 때
3. 람다에서 this는 바깥 인스턴스를 가리키지만, 익명 클래스의 this는 익명 클래스 인스턴스 자신을 가리킨다

주의🚫 람다와 익명 클래스 인스턴스를 직렬화하는 일은 되도록이면 하지 말아야 한다. JVM 별로 직렬화 방식이 다르기 때문이다.

요약

새로 추가하는 메서드 없이 타입 정의가 목적이라면 마커 인터페이스를 선택하고,

인터페이스/클래스 외의 프로그램 요소(모듈, 패키지, 필드, 지역 변수)에 마킹을 하거나 애너테이션을 많이 사용하는 프레임워크를 사용할 때는 마커 애너테이션을 사용하자.

마커 인터페이스란

마커 인터페이스는 아무 메서드도 담고 있지 않고, 단지 자신을 구현하는 클래스가 특정 속성을 가짐을 표시해 주는 인터페이스를 의미한다.

예시로 Serializable 인터페이스가 있다. Serializable은 자신을 구현한 클래스의 인스턴스는 ObjectOutputStream을 통해 직렬화 할 수 있다고 알려주는 인터페이스이다.

마커 인터페이스 vs. 마커 애너테이션

마커 인터페이스 > 마커 애너테이션

1. 마커 인터페이스는 타입을 구분할 수 있다
   1. 컴파일 타임에 오류를 잡아낼 수 있다
   2. 반면 마커 애너테이션은 런타임에 오류를 잡아낼 수 있다
2. 마커 인터페이스는 적용 대상을 더 정밀하게 지정할 수 있다
   1. 마커 애너테이션은 적용 대상을 @Target(Element.TYPE)으로 지정할 수 있지만, 세밀하게 하지는 못한다
   2. 반면 마커 인터페이스는 클래스가 해당 인터페이스를 구현하면 되기 때문에 원하는 곳에 적용할 수 있다

마커 인터페이스 < 마커 애너테이션

1. 마커 애너테이션은 애너테이션의 시스템 지원을 받을 수 있다
   1. 애너테이션을 적극 활용하는 프레임워크에서는 마커 애너테이션을 쓰는 쪽이 일관성을 지키는 데 더 유리하다

정리

마커 애너테이션을 사용해야 할 때

1. 인터페이스나 클라스가 아닌 프로그램 요소(모듈, 패키지, 필드, 지역 변수)에 마킹을 해야할 때
2. 애너테이션을 많이 사용하는 프레임워크를 사용할 때

마커 인터페이스를 사용해야 할 때

1. 마킹이 된 객체를 매개변수로 받는 메서드 작성이 필요할 때
   1. 매개변수 타입으로 마커 인터페이스를 설정하면 컴파일타임에 오류가 발생하기 때문

요약

애노테이션 사용하자! 그리고 자바가 제공하는 애노테이션은 잘 알아두자.

명명패턴

이름 짓기에 패턴을 만드는 방법을 의미한다. 예시로 Junit 3까지는 테스트 메서드 이름을 testA() 처럼 test로 시작했어야 했다.

단점

1. 오타가 나면 안된다
2. 실수로 메서드 이름을 tsetSafetyOverride로 지어도 Junit 3은 이 메서드를 테스트 메서드로 인식 못하고 넘어간다. 하지만 개발자는 테스트가 성공해서 넘어간 것으로 오해할 수 있어 문제 발생의 가능성이 존재한다.
3. 올바른 프로그램 요소(메서드)에서만 사용되리라 보증할 방법이 없다
4. 메서드가 아닌 클래스 이름을 TestSafety로 설정한다 가정하면, 클래스 이름이 test로 시작하지만 메서드가 아닌 클래스에 설정된 이름이기 때문에 이또한 Junit 3가 인지하지 못한다. 하지만 개발자는 테스트에 사용하는 클래스 목적으로 TestSafety라는 이름을 설정했기에, 문제가 발생할 가능성이 또한 존재한다.
5. 프로그램 요소를 매개변수로 전달할 마땅한 방법이 없다
6. 특정 예외를 던져야 성공하는 테스트인 경우, 예외를 넘겨줘야 하는데 명명패턴에서는 넘길 수 없다. 또한 명명패턴에서는 예외의 이름을 테스트 메서드 이름에 덧붙이는 방법도 있지만, 이는 보기도 나쁘고 깨지기도 쉽다.

→ 위 모든 문제를 애너테이션이 해결할 수 있고 Junit 4부터 애너테이션을 사용할 수 있다.

마커 애너테이션

마커 애너테이션은 아무 매개변수 없이 단순히 대상에 마킹하는 목적으로 사용하는 애너테이션이다.

@Test

/**
 * 테스트 메서드임을 선언하는 에너테이션이다.
 * 1) 매개변수 없는 2)정적 메서드 전용이다.
 */
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface Test {
}

• @Test를 설정하는 코드이고, @Test를 마커 애너테이션이라고 한다.
• 메타 애너테이션 : 애너테이션 선언에 있는 애너테이션을 의미
  • @Retention(RetentionPolicy.RUNTIME) : @Test가 런타임에도 유지되어야 함
  • @Target(ElementType.METHOD) : @Test가 반드시 메서드 선언에서만 사용되어야 함
• 매개변수 없는 정적 메서드 전용이다.
  • 인스턴스 메서드 or 매개변수가 있는 메서드에서는 사용 못한다
• 장점
  • 규칙 어길 시 컴파일 오류가 발생해 안정성 보장

마커 애너테이션 예시

public class Sample {

    @Test // Test 도구가 체크하는 메서드 & 성공 케이스
    public static void m1() {
    }

    @Test // Test 도구가 체크하는 메서드 & 실패 케이스
    public static void m2() {
        throw new RuntimeException("실패");
    }

    @Test // Test 도구가 체크하는 메서드 & 잘못 사용한 케이스(정적 메서드가 아님)
    public void m3() {
    }

    // Test 도구가 체크하지 않는 메서드
    public static void m4() {
    }
}

• @Test
  • m1, m2, m3 메서드는 @Test 애너테이션이 설정되어 있어 Test 도구가 체크할 수 있는 메서드이다
  • 이 중에서 성공 케이스와 실패 케이스로 나뉘는데, 실패 케이스는 예외를 throw 한다
  • m4()처럼 정적 메서드 임에도 @Test 애너테이션이 설정되어 있지 않다면, Test 도구가 체크하지 않는다
• 정적 메서드
  • @Test 애너테이션을 설정하더라도, 설정된 메서드가 static(정적)이 아니면 잘못 사용한 예시다

@Test

이 애너테이션은 클래스에 직접적인 영향은 주지 않고, 플러스 알파로 해당 애너테이션에 관심 있는 도구에게 추가 정보를 제공한다.

• 마커 애너테이션을 처리하는 프로그램

public class RunTests {

    public static void main(String[] args) throws ClassNotFoundException {
        int tests = 0; // 실행된 테스트 개수
        int passed = 0; // 실행된 것 중 통과한 테스트 개수

        Class<?> testClass = Class.forName(args[0]); // 명령줄로부터 완전 정규화된 클래스 불러옴
        for (Method method : testClass.getDeclaredMethods()) {
            if (method.isAnnotationPresent(Test.class)) { // @Test 선언한 메서드 차례로 호추
                tests++;
                try {
                    method.invoke(null);
                    passed++;
                } catch (InvocationTargetException wrappedException) {
                    Throwable cause = wrappedException.getCause();
                    System.out.println(method + " 실패 : " + cause);
                } catch (Exception e) {
                    System.out.println("잘못 사용한 @Test : " + method);
                }
            }
        }
        System.out.printf("성공 : %d, 실패 : %d%n", passed, tests - passed);
    }
}

• InvocationTargetException
  • 테스트 예외를 InvocationTargetException으로 감쌈
  • 그래서 테스트 예외를 알아내기 위해 wrappedException.getCause() 호출
  • 이 예외가 발생하면 @Test 애너테이션을 잘못 사용한 것을 의미
    • 정적 메서드가 아닌 인스턴스 메서드, 매개변수가 있는 메서드, 호출할 수 없는 메서드 등

매개변수 하나를 받는 애너테이션

특정 예외를 던져야만 성공하는 테스트를 지원하기 위해 예외를 매개변수로 받는 애너테이션 @ExceptionTest를 만들어야 한다.

•  @ExceptionTest

/**
 * 명시한 예외를 던져야만 성공하는 테스트 메서드용 애너테이션
 */
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface ExceptionTest {
    Class<? extends Throwable> value();
}

• 애너테이션 매개변수 타입 : Class<? extends Throwable>(한정적 타입 토큰)
  • Throwable을 상속한 하위 타입 모두 해당됨을 의미한다
  • 모든 예외와 오류 타입을 수용한다

예시

public class Sample2 {
    
    // 성공 케이스
    @ExceptionTest(ArithmeticException.class)
    public static void m1() {
        int i = 1;
        i /= i;
    }
    
    // 실패 케이스 - @ExceptionTest 에 설정한 Arithmetic 예외가 아닌 다른 예외 발생
    @ExceptionTest(ArithmeticException.class)
    public static void m2() {
        int[] a = new int[0];
        int i = a[1]; // IndexOutOfBoundException
    }
    
    // 예외가 발생하지 않는 케이스
    @ExceptionTest(ArithmeticException.class)
    public static void m3() { }
}

활용

• 코드

public class RunTests2 {

    public static void main(String[] args) throws ClassNotFoundException {
        int tests = 0; 
        int passed = 0; 
        Class<?> testClass = Class.forName(args[0]); 
        for (Method method : testClass.getDeclaredMethods()) {
            if (method.isAnnotationPresent(ExceptionTest.class)) { // @Test 선언한 메서드 차례로 호추
                tests++;
                try {
                    method.invoke(null);
                    System.out.printf("테스트 %s 실패 : 예외를 던지지 않음%n", method);
                } catch (InvocationTargetException wrappedException) {
                    Throwable exceptionCause = wrappedException.getCause();
                    Class<? extends Throwable> exceptionType = 
                            method.getAnnotation(ExceptionTest.class).value();
                    if (exceptionType.isInstance(exceptionCause)) { // 기대한 예외 == 발생한 예외
                        passed++;
                    } else { // 기대한 예외 != 발생한 예외
                        System.out.printf("테스트 %s 실패 : 기대한 예외 %s, 발생한 예외 %s%n", method, exceptionType.getName(), exceptionCause);
                    }
                    
                    System.out.println(method + " 실패 : " + exceptionCause);
                } catch (Exception e) {
                    System.out.println("잘못 사용한 @Exceptiontest : " + method);
                }
            }
        }
        System.out.printf("성공 : %d, 실패 : %d%n", passed, tests - passed);
    }
}

• @Test 애너테이션 실행 코드와 다른 부분
  • 애너테이션의 매개변수 값을 추출해 테스트 메서드가 올바른 예외를 던지는지 확인하는데 애너테이션을 사용한다

여러 개의 예외를 받는 애너테이션

• @MultipleExceptionTest

/**
 * 배열 매개변수를 받는 애너테이션 타입
 */
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface MultipleExceptionTest {
    Class<? extends Throwable>[] value();
}

활용

• 코드

public class RunTests3 {

    // 매개변수로 예외 배열 넘김
    @MultipleExceptionTest({IndexOutOfBoundsException.class, 
                            NullPointerException.class})
    public static void doubleBad() {
        List<String> list = new ArrayList<>();
        list.addAll(5, null);
    }
    
    public static void main(String[] args) throws ClassNotFoundException {
        int tests = 0;
        int passed = 0;
        Class<?> testClass = Class.forName(args[0]);
        for (Method method : testClass.getDeclaredMethods()) {
            if (method.isAnnotationPresent(MultipleExceptionTest.class)) { // @Test 선언한 메서드 차례로 호추
                tests++;
                try {
                    method.invoke(null);
                    System.out.printf("테스트 %s 실패 : 예외를 던지지 않음%n", method);
                } catch (InvocationTargetException wrappedException) {
                    Throwable exceptionCause = wrappedException.getCause();
                    int oldPassed = passed;
                    Class<? extends Throwable>[] exceptionTypes =
                            method.getAnnotation(MultipleExceptionTest.class).value();
                    for (Class<? extends Throwable> exceptionType : exceptionTypes) {
                        if (exceptionType.isInstance(exceptionCause)) {
                            passed++;
                            break;
                        }
                    }
                    if (passed == oldPassed) {
                        System.out.printf("테스트 %s 실패 : %s %n", method, exceptionCause);
                    }
                    System.out.println(method + " 실패 : " + exceptionCause);
                } catch (Exception e) {
                    System.out.println("잘못 사용한 @Test : " + method);
                }
            }
        }
        System.out.printf("성공 : %d, 실패 : %d%n", passed, tests - passed);
    }
}

• 여러 개의 값을 받는 애너테이션
  • 배열 매개변수
  • @Repeatable 메타 애너테이션
    • 장점 : 가독성 향상
    • 단점
      • 애너테이션 선언/처리 코드양 증가
      • 처리가 복잡해서 오류 발생 가능성 증가