[Rust] 파라미터 트릭

객체를 초기화하거나 주요 함수를 호출할 때, 파라미터가 한두개에 불과하다면 딱히 고민은 필요하지 않다.

근데 함수의 파라미터 개수가 3개, 4개를 넘어가거나, 그 중에서도 꼭 받지 않아도 되는 게 있다면 단순하게 함수 인자로만 넘기는 것은 썩 좋은 생각은 아니다.

예를 들면

이런 경우 말이다.

Rust는 함수 오버로딩을 지원하지 않아서 이 부분에 약간 약점이 존재하는데, trait 기반의 확장 기능을 응용하면 이 또한 어느 정도 극복이 가능하다.

함수 없이 구조체 생성

생성자 함수 호출로 인한 번잡스러움을 줄일 수 있는 유효한 방법 중 하나는 그냥, 함수로 생성하지 않고 구조체로 생성하는 것이다.

경우에 따라서는 이렇게 그냥 구조체를 바로 생성하는 것이 편리할 수도 있다.
Default trait 정의를 통해 선별적으로 생략하는 것도 꽤 간단하다.

하지만 원본 객체 자체가 상당히 무겁고, 단순 데이터 전달 타입의 범위를 벗어나는 수준이라면 사용하는 것에 한계가 있다.

함수마다 파라미터 타입 정의하기

꼭 생성자 함수가 아니더라도, 함수 자체가 받을 파라미터가 굉장히 많다면 그냥 그 함수 전용 파라미터를 묶는 구조체를 정의하는게 좋은 방법일 수 있다.

이런 식으로 new 함수에 넘길 파라미터를 구조체로 정의한다음에, 구조체를 넘겨주도록 했다.

튜플로 오버로딩 흉내내기

tuple과 trait을 응용하면 인자 갯수가 달라지는 오버로딩을 흉내낼 수 있다.

일단, 최종적인 파라미터 형태를 정의하고 그 파라미터로 변환하는 trait을 정의한다.
From, Into를 써도 무방하다.

아무튼 그걸 제너릭이나 impl Trait으로 받아서 생성하는 함수를 정의한다.

그리고 각각의 튜플 조합에 대한 trait 구현을 만들면

이런 식으로 엇비슷하게 흉내가 가능하다.

다만, 이것도 파라미터 갯수가 너무 많지 않을 때만 유효한 방법이다.

Builder 패턴

객체 생성에 전달되는 필드가 정말 많고, 검증할 필요도 있다면 보통은 빌더 패턴이 종착점이 된다.

다른 언어들에서 빌더를 구현하는 방식과 크게 다르지는 않다.

원본 타입이 있으면, 거기서 builder 생성을 먼저 해주고

빌더 내에서 값을 하나씩 받아서 상태를 저장한 뒤에, build가 호출되면 모아서 원본 객체를 완성하는 것이다.

Rust에서 이런 단순 재할당-체이닝이 반복될 수 있는 경우는 이동을 통해 전달되도록 하는 것이 여러가지 상황에 대응하기 편하다. 그래서 이 예제도 참조 없이 move self로만 구성해놨다.

그리고 검증을 좀 제대로 해야 한다면 build의 반환타입을 Option이나 Result로 처리할 수도 있을 것이다.