우선 RIBs의 구조에 대해서 알 필요가 있습니다.
RIBs의 구조로는 Router, Interactor, Builder, Presenter, View, Component를 가지고 있습니다.
이때 각 기능 단위로 RIB을 생성하며 RIB을 조합해서 하나의 앱을 만드는 것이 RIBs 구조의 핵심입니다.
Ex)
이런식으로 3개의 기능을 RIBs 패턴을 통해 구현할려고 하면
로그인 화면
- LoginRouter.swift
- LoginInteractor.swift
- LoginBuilder.swift
로그아웃 화면
- LogoutRouter.swift
- LogoutInteractor.swift
- LogoutBuilder.swift
설정 화면
- SettingRouter.swift
- SettingInteractor.swift
- SettingBuilder.swift
이렇게 최소 9개의 파일이 필요하며 만약 기능을 보여주는 View도 필요해 구현을 하게 되면 12개 + @의 파일이 더 생기게 됩니다.
이제 각 기능들이 어떤 역할을 하는지 알아봅시다.
Router
- Interactor의 요청을 받아 부모 RIB을 attaching(연결)하고 , 자식 RIB과 detaching(분리)하는 역할을 담당합니다.
- 복잡한 로직의 Interactor를 테스트할 때 자식 Interactor를 mock하거나, 그들의 존재를 신경 쓸 필요가 없게 함으로써 더 쉽게 테스트 할 수 있도록 하는 Humble Object(겸손한 객체) 역할을 한다
- 이때 mock은
(저 mock때문에 이해하는데 오랜 시간이 걸렸네요) 테스트 중에 사용할 가짜 객체를 뜻합니다. 실제 객체가 네트워크, 하드웨어 같은 외부 요소에 의존할 경우 테스트하기 힘들거나 오래 걸릴 수 있다는 단점이 있습니다. 하지만 mock을 통해 가짜 객체를 사용하면 테스트를 더 간편하게 사용할 수 있습니다.
- 부모 Interactor와 자식 Interactor간의 추상화 계층을 만들어줍니다. 이로 인해 Interactor간의 동기식 통신이 어려워지고, RIB간의 직접적인 연결을 피하고 반응형 통신 채택을 장려합니다.
Interactor
- 애플리케이션의 비즈니스 로직을 수행하는 곳입니다.
- subscriptions(구독)을 관리합니다.
- 이때 subscriptions(구독)이란 Rx(리액티브 프로그래밍)에서 이벤트 스트림에 대한 구독자를 관리한다는 말입니다. Rx는 데이터나 이벤트를 스트림 형태로 처리하는 패턴을 사용하며, 이 패턴을 사용하는 주체를 구독자라고 합니다. 구독자는 스트림에서 발생하는 데이터를 비동기적으로 사용합니다. 이때 구독을 관리한다는 말은 API관련 비즈니스 로직이 시작하면 API구독이 시작되고 사용하지 않는다고 판단되면 API구독을 해지하면서 리소스 낭비를 방지합니다.
- 상태 변화와 결정을 내립니다.
- 예를 들어 사용자가 특저 액션을 취했을 때 해당 비즈니스 로직은 Interactor에서 처리합니다. 필요시 UI상태나, 앱의 흐름을 업데이트 합니다.
Builder
- 의존성 주입 관리
- 유일하게 의존성을 관리하는 부분으로 DI가 변경이 되어도 Builder만 수정하면 되니까 나머지 모듈이 간섭을 받지 않음
- RIB에서 다른 자식 RIB을 필요로 할때 부모 RIB의 Builder가 자식 RIB의 Builder를 호출합니다.
Presenter(Optional)
- 비즈니스 모델 -> 뷰 모델
- Interactor에서 처리된 비즈니스 로직이 실행 되면 그 결과 데이터를 뷰 모델로 변환해 UI에서 사용할 수 있는 것을 말합니다
- 뷰 모델 -> 비즈니스 모델
- 사용자가 입력한 데이터를 비즈니스 모델로 변환해 Interactor에게 전달하는 역할. UI에서 받은 입력을 비즈니스 로직에 맞게 처리하는 역할을 의미합니다.
생략 가능한 상황
- Interactor, View의 변환이 단순할 때 생략 가능합니다.
생략 불가능한 상황
- 복잡한 데이터 변환이 필요한 경우
- 데이터 가공을 사용할 때
- 여러 소스와 데이터를 결합할 때
View(Controller)
- View에서 사용자의 입력을 처리합니다.
- View가 Presenter처럼 Optional형태인 이유는 비 UI를 요구하는 (예를 들어: 비즈니스 로직, 네트워크 요청)작업들이 존재하기 때문입니다.
RIBs의 장점
- 멀티 플랫폼 공유가 가능하다.
- iOS와 안드로이드 모두 RIBs로 설계할 수 있다.
- Interactor에 대한 접근이 어려워 독립적인 설계를 하게끔 유도한다
RIBs의 단점
- 기본적으로 굉장히 많은 파일을 요구하기 때문에 구현에 많은 시간이 걸린다.
- 의존성 주입을 각 RIB에 알아서 주입해야 한다.
참고 자료
Uber
Uber Document
RIBs Medium
JIN WOO Park (PFXStudio)
Zedd0202
강동희