컬렉터를 커스텀 하는 이유(김종민)
Opened this issue · 0 comments
문제가 무엇인가?
컬렉터를 커스텀 하는 이유가 무엇일가?
왜 이런 문제를 선정하였는가?
Collectors 클래스에 정적 팩토리 메소드가 많은데 왜 커스텀을 해야할지 감이 잡히지 않았다.
자신이 생각한 답변은 무엇인가?
Collector 인터페이스
Collector 인터페이스는 java.util.stream 패키지 안에 속하는 인터페이스이다.
존재하는 메소드와 역할은 아래와 같다.
- supplier : 수집 과정에서 사용할 빈 컨테이너를 생성하여 반환 (예를 들면 Map, Set, List)
- accumulator : 스트림의 각 요소를 결과 컨테이너에 추가할지 정의한다. 이 메소드는 스트림의 각 요소를 받아서 중간 결과 컨테이너에 누적하는 함수를 정의한다.
- finisher : 누적 과정이 끝난 후, 최종 결과를 변환하거나 조정하기 위한 함수를 제공, 예를 들어 누적된 결과가 컬렉션이지만 최종 결과를 문자열로 변환하고 싶은 경우에 사용한다.
- combiner : 병렬 처리를 할 때, 각각의 스레드에서 분리된 결과를 가진 컨테이너를 하나로 합치는 방법 정의, 이는 병렬 스트림에서 중요한 역할을 한다.
- characteristics : 컬렉터의 행동을 지정하는 Characteristics의 세트를 반환한다.
- UNORDERED는 스트림의 요소 순서가 결과에 영향을 미치지 않음을 나타낸다
- CONCURRENT는 동시에 여러 스레드에서 결과 컨테이너의 요소 순서가 결과에 영향을 미치지 않음을 나타낸다.
- IDENTITY_FINISH는 finisher 함수가 단순히 identity 함수임을 나타내어 finisher를 호출할 필요가 없음을 의미한다.
위 메소드들을 구현함으로써, Collector 인터페이스를 사용하여 다양한 종류의 누적자를 만들 수 있으며, 이를 통해 스트림의 요소들을 원하는 대로 처리하고 결과를 도출할 수 있다.
CollectorImpl 클래스
CollectorImpl 클래스는 Collectors 클래스 내부에 정의된 정적 클래스로, 팩토리 메소드에서 실제로 리턴되는 객체이다.
CollectorImpl 클래스는 Collector 인터페이스를 Implements 한 클래스이며
supplier, accumulator 등의 메소드를 전부 구현하고 있다.
Collectors 클래스에서는 CollectorImpl 클래스를 생성자를 통해 각 상황에 맞게 구현하여 반환하고 있는 팩토리 메소드를 가지고 있다.
Collectors 클래스에 있는 정적 팩토리 메소드의 수도 많은데 굳이 커스텀을 해야할까?
커스텀?
내가 생각한 커스텀을 하는 이유는 단순하다.
바로 Collectors에 정의된 팩토리 메소드로 해결할 수 없는 경우일 때이다.
Collectors 클래스 안에 있는 메소드는, 상황에 맞게 Collector 인터페이스를 구현한 객체를 반환하여 스트림을 다룰 수 있도록 지원한다.
만약, 개발자의 상황이 새로운 Collector가 필요한 상황이라면, Collectors에 정의된 메소드로 해결할 수 없다면, 그때 Collector 인터페이스를 커스텀해야 한다고 생각이 들었다.