RIBs란?
RIBs는 우버가 만든 크로스 플랫폼 아키텍쳐 프레임워크이다. 여러 중첩된 상태(state)를 가지는 큰 규모의 모바일 앱을 설계하기 위한 프레임워크이다.
RIBs 프레임워크가 기존 아키텍쳐 패턴인 MV* 혹은 VIPER과 다른 점은 (뷰가 아닌) 비즈니스 로직이 앱을 구동한다는 점이다. 이는 앱의 계층이 뷰가 아닌 비즈니스 로직에 기반해 구성된다.
앱의 특정 지점에서 로직에 따라 A 혹은 B 화면을 보여주어야 할 때 A, B를 자식으로 가지면서 뷰가 없는 RIB을 예로 들 수 있다.
VIPER 패턴의 구성
- RIBs가 주장하는 해당 패턴의 단점은 프레젠터 중심으로 계층이 구성되어, 비즈니스 로직만을 포함하는 노드를 구성하기 어렵다는 점이다.
뷰가 없는 노드
- 그림과 같이 유저 로그인 후,
OffGame, TicTacToe화면간 전환이 필요한 흐름이 있다고 할때,
LoggedIn을 뷰가 없는 RIB으로 구성하여 로직만을 포함하는 노드를 생성할 수 있다.
RIB의 구성
Interactor
인터렉터는 비즈니스 로직을 포함한다.
- 상태 변경에 대한 결정을 내림
어떤 데이터를 저장할 위치를 결정
어떤 RIB을 자식으로 연결할지 결정 - 인터렉터에서 수행하는 모든 작업은 해당 RIB의 lifeCycle 로 제한되어야 한다. 그래서 인터렉터가 활성화된 경우에만 비즈니스 로직이 수행되도록 하는 구축되어 있고, 이는 인터렉터가 비활성화 되었지만 원치않는 비즈니스 로직이나 UI 상태 업데이트가 발생하는 것을 방지한다.
Router
화면 전환 담당 객체로 라우터는 인터렉터를 듣고 자식 RIBs를 attac/detach 한다.
- 인터렉서가 수행할, 단순하고 반복되는 라우팅 로직을 포함한다. 이 boilerplate 코드를 제외하여 인터렉터를 작게 유지하고, 핵심 로직에 더 집중할 수 있도록 한다.
- 라우터는 Humble한 상태로, 하위 인터렉터를 mock 처리하거나 신경쓸 필요 없이 복잡한 인터렉터의 로직을 쉽게 테스트할 수 있게 해준다.
→ Humble Object의 의미: 디자인 패턴으로, 테스트하기 어려운 로직을 humble객체인 라우터에 보내고 인터렉터에는 테스트하기 쉬운 로직을 유지하는 것.
Builder
빌더는 모든 RIB 구성 클래스와 각 RIB의 자식의 빌더를 인스턴스화 한다.
- 빌더에 클래스 생성 로직을 분리하고 나머지 RIB 코드는 DI구현의 세부 사항과 무관해진다.
빌더는 프로젝트에서 사용되는 DI 시스템을 알고있는 유일한 부분이다.
Component
컴포넌트는 RIB의 의존성 관리 역할을 한다. 필요한 의존성을 인스턴스화하며 빌더를 돕는다.
외부 의존성에 대한 액세스를 제공하고 소유하여 다른 RIB에서 필요한 의존성에 접근을 제공하기도 한다.
→ 부모 RIB의 컴포넌트가 자식RIB 빌더 생성시 주입되어 의존성을 제공한다.
Presenter & View (Optional)
프레젠터 & 뷰는 뷰모델 & 뷰 같은 역할로, 프레젠터는 뷰에 필요한 데이터를 가공하는데, 그 역할이 적으면 생략할 수 있다. (인터렉터가 역할 대체)
뷰 또한 RIBs의 특성 상 로직만으로 구성된 노드라면 생략될 수 있다.
State Management
앱의 상태는 RIB 계층에 현재 attach된 RIB에 의해 나타나고 관리된다. 예를 들어, 위 그림에서 LoggedIn 은 Request, Menu, OnTrip 화면 간의 전환에 대한 결정만 내린다. 다음 화면이 정해지면 그 화면이 다음 상태를 관리하게 된다.
하나의 RIB에 생성되는 코드들
예를 들어, Main이라는 RIB을 생성하면 이를 구성하는 모든 클래스들이 함께 생성된다.
MainRouter, MainInteractor, MainBuilder, MainViewController 가 해당된다. (뷰가 있는 RIB이라 가정)
이때 클래스들은 다른 클래스에 직접 의존하는 대신, 프로토콜을 사용하여 소통한다.
이런 프로토콜의 활용은 의존성 역전 법칙에 기반한 것으로 객체간 결합도를 낮추고 테스트의 용이성을 높여준다.
