[Design Pattern] RIBs란?(feat. Uber)

안녕하세요 Foma👟 입니다!

 

오늘은 Uber에서 만든 프레임워크인 RIBs에 대해서 알아보도록 하겠습니다.

 

iOS계에서 아주 고수이신 '민소네'님도 여러 디자인 패턴을 거쳐서 RIBs에 정착하게 되었다고 하고

 

또 많은 회사에서 RIBs 프레임워크를 사용하고 있더라구요.

 

그래서 어떤 점이 장점이고 또 어떻게 사용하는지에 대해서 다뤄보도록 하겠습니다!

 

바로 시작할게요~

---

RIBs란?

 

공식 깃헙에선 이렇게 소개합니다.

 

RIBs는 Uber의 모바일 크로스 플랫폼 아키텍처 프레임워크입니다. RIB이라는 이름은 이 아키텍처의 핵심 구성 요소인 Router, Interactor 및 Builder의 약어입니다. 이 프레임워크는 많은 수의 엔지니어와 중첩 상태가 있는 모바일 앱을 위해 설계되었습니다.

 

제공

 

RIBs 아키텍처는 아래 4가지 특징을 제공합니다.

 

• 공유 아키텍처 유사한 아키텍처를 가진 플랫폼 간 앱을 빌드하여 iOS 및 Android 팀이 비즈니스 로직 코드를 교차 검토할 수 있도록 합니다.
• 테스트 가능성  클래스는 단위 테스트가 쉬워야 하고 개별적으로 추론해야 합니다. 개별 RIB 클래스에는 라우팅, 비즈니스, 뷰 로직, 생성과 같은 고유한 책임이 있습니다. 또한 대부분의 RIB 논리는 자식 RIB 논리에서 분리됩니다. 따라서 RIB 클래스를 쉽게 테스트하고 독립적으로 추론할 수 있습니다.
• 개발 생산성 RIB는 코드 생성, 메모리 누수 감지, 정적 분석 및 런타임 통합과 관련된 IDE 도구와 함께 제공되며, 이 모두는 대규모 팀 또는 소규모 팀의 개발자 생산성을 향상시킵니다.
• 확장 가능한 아키텍처 이 아키텍처는 수백 개의 RIB가 있는 동일한 코드베이스 및 앱에서 작업하는 수백 명의 엔지니어로 확장되는 것으로 입증되었습니다.

 

다른 디자인 패턴과의 차이점

 

RIBs는 MVC,MVP,MVVM,VIPER와 같은 디자인 패턴이 아니라 프레임워크입니다.

 

다른 디자인 패턴과 달리 RIB은 View가 필요하지 않습니다.

 

이것은 앱 계층 구조가 뷰 트리가 아닌 비지니스 로직에 의해 구동된다는 것을 의미합니다.

 

RIB은 비즈니스 로직 범위가 뷰 계층 구조에서 어떻게 구성되는지를 분리합니다.

 

이를 통해서 앱은 레이아웃,애니메이션 및 전환을 쉽게 만드는 얕은 뷰 계층을 유지하면서

 

깊은 비지니스 로직 트리를 가질 수 있습니다.

---

구성요소

 

하지만 진짜 R.I.B로만 이뤄진 건 아닙니다.

 

아래와 같이 Router Interactor Builder 뿐만 아니라 Presenter,View,Component가 있는데요.

 

이제부터 하나 하나 자세히 알아보겠습니다.

 

출처: https://github.com/uber/RIBs/wiki

 

 

Router

 

라우터는 인터랙터를 듣고 그에 대한 반응을 자식 RIB을 연결하거나 분리를 변환합니다.

 

라우터가 존재하는 이유

 

1. 하위 인터랙터를 신경쓰지 않고 복잡한 인터랙터의 로직을 테스트할 수 있도록 합니다.

 

2. 부모 인터랙터와 자식 인터랙터의 직접 결합 대신 반응형 통신의 채택을 권장할 수 있도록 합니다.

 

3. 인터랙터에 의해 구현되는 라우팅 로직을 포함해 인터랙터를 작게 유지합니다.

 

Interactor

 

인터랙터는 비지니스 로직을 포함합니다.

 

Rx구독,상태 변경,데이터 저장 위치,자식 RIB 등을 결정합니다.

 

인터랙터가 수행하는 모든 작업은 해당 수명 주기로 제한해 비지니스 논리 또는 UI 상태에 대한 원치 않는 업데이트를 방지할 수 있습니다.

 

Builder

 

모든 RIB의 구성 클래스와 각 RIB 자식에 대한 빌더를 인스턴스화 합니다.

 

빌더를 통해서 로직을 분리하면 나머지 RIB 코드는 DI 구현 사항에 신경쓰지 않게 됩니다.

 

이렇게 되면 프로젝트의 나머지 RIB 코드를 재사용할 수 있습니다.

 

Presenter

 

모델을 뷰모델로 뷰모델을 모델로 변환하는 상태 비저장 클래스입니다.

 

프레젠터는 RIB을 만들 때 옵셔널로 만들어도 되고 만들지 않아도 됩니다.

 

만약 프레젠터가 생략되면 뷰모델 전환은 뷰 또는 인터랙의 책임이 됩니다.

 

View

 

뷰는 UI를 빌드하고 업데이트 합니다.

 

이것도 프레젠터와 같이 옵셔널로 반드시 필요한 것은 아닙니다.

 

Component

 

컴포넌트는 빌더가 RIB을구성하는 다른 단위를 인스턴스화 하도록 지원합니다.

 

RIB을 구축하는데 필요한 외부 종속성에 대한 액세스를 제공하고 제어합니다.

---

상태관리

 

RIB의 상태관리는 아래 GIF로 설명할 수 있습니다.

 

 

Step 1. 유저가 로그아웃 했을 때 온보딩 RIB이 붙여집니다.

 

Step 2. 유저가 로그인 하면 온보딩 RIB이 떼어지고 Request,Shortcuts RIB이 붙여집니다.

 

Step 3. 유저가 Shortcuts를 사용하면 Comfirmation RIB이 붙여집니다.

 

...

---

RIB 간 통신

 

인터랙터가 어떠한 비지니스 로직 결정을 내릴 때 완료와 같은 이벤트를 다른 RIB에 알리고 데이터를 보내야 합니다.

 

RIB간에 데이터를 보내는 단일 방법을 있지 않으나 하위 RIB으로 내려가면 Rx 스트림 방출로 전달합니다.

 

또는 데이터가 자식 RIB의 build() 메소드의 매개변수로 포함될 수도 있습니다.

 

 

 

리스너 인터페이스를 통해 통신이 수행됩니다.

 

이것은 부모가 자식의 Rx 스트림을 직접 구독하는 대신 부모 RIB에서 리스너 인터페이스를 구현하고 자식 RIB가 호출될 수 있도록 

 

리스너 인터페이스를 DI 그래프에 배치하여 메모리 누수를 방지하고 테스트 및 유지 관리를 수월하도록 합니다.

 

---

오늘은 이렇게 RIBs 아키텍처 프레임워크에 대해서 알아보았는데요.

 

사실 글을 작성하면서도 잘 이해가 되지 않습니다...

 

이론 자체도 이해가 안가는데... 이걸로 구현을 하려면 얼마나 더 복잡할지..

 

다음 포스팅은 튜토리얼로 돌아오겠습니다!

 

혹시라도 틀린 점이나 궁금한 점이 있으면 댓글로 알려주세요!

---

튜토리얼

 

• Interactor로 비니지스 로직 처리해보기
• Router를 이용해 화면 전환해보기
• AddMemo 구현하기