이게 그 토스 문제임.


    fun solution(assets: Array<String>): Array<String> =

        assets.mapNotNull { asset -> runCatching { asset.toAssetResult() }.getOrNull() }

            .sorted()

            .filter(Asset::isValid)

            .map(Asset::text)

            .distinct()

            .toTypedArray()



보통 이게 체이닝이고


체이닝은 보통 언어에 연동 안됨. 그냥 체이닝 자체가 일종의 개념이라서.


그럼 저 체이닝은 뭐냐? 파이프라인 순서임


근데 정렬-> 필터


이렇게하는데 이거는 그냥 기초만 알아도 필터 다음에 정렬 하라고 배움.


필터->정렬하는게 맞음


assets.mapNotNull { it.toAssetOrNull() }

    .filter { it.isValid() }

    .sorted()

    .distinctBy { it.toString() }

    .map { it.toString() }

    .toTypedArray()



그럼 이렇게 되겠지
그다음에 distinctBy를 쓰는 걸 권장하는게 맞는거고

그럼 이렇게 체이닝 순서만 알아도 편하게 순서가 잘못됐다.라고 말할 수 있는건데

애초에 체이닝 주로 쓰이는 fluent builder 같은게 나온게 그거임

단순 빌더로 처리 안되니까 체이닝으로 하나의 파이프라인을 내장한 객체 생성이고

이 경우에는 외부서 호출할 파이프라인 설계하는 관점인데

그 관점에서 순수하게 잘못됐단거임

그래서 걍 딱 봐도 바로 잘못됐다고 말한건데 뭔 서버쪽을 몰라도 알 수 있는 API 설계 문제를 서버쪽 모르는데 어떻게 풀었냐고 하면 내가 궁금하다야