[아키텍쳐] RIBs란

RIBs란 우버에서 만든 아키텍쳐입니다. 

사실 작년에 튜토리얼 1을 조금 따라해보긴했는데 .. 되게 복잡복잡했던 기억만 남아있는거 같아요 ... 

그래서 RIBs를 이루는 기본 개념에 대해 튜토리얼2까지 보았겠다 다시한번 정리 해보려고 합니다 이번에 프로젝트때 꼭 적용해보려구요 !!

 

What are RIBs For?

RIBs는 우버의 크로스 플랫폼 아키텍쳐 프레임워크입니다. RIBs는 많이 얽혀있는 state를 포함하고 있는 큰 모바일 앱을 위해 디자인 되었습니다. 

우버를 위한 이 프레임워크를 디자인 할때 아리 원칙을 준수하고자 하였습니다.

 

Encourage Cross-Platform Collaboration :

우리 앱의 복잡한 부분은 대부분 iOS와 Android에서 비슷합니다. RIBs는 Android와 iOS를 위한 비슷한 개발 패턴을 보입니다. RIBs를 사용함으로서 iOS 및 Android 플랫폼의 엔지니어는 기능에 대해 공동으로 설계된 단일 아키텍처를 공유할 수 있습니다.

 

Minimize Global States and Decisions:

Global state 변화는 예측할 수 없는 행동을 만들고 변화에 대한 전체의 영향을 알지 못하게 만듭니다. RIBs는 각 RIBs의 고립된 깊은 계층구조 내에서 state를 캡슐화하여 global state 이슈를 방지합니다.

 

Testability and Isolation:

클래스는 단위 테스트가 쉬워야 하고 격리(isolation)에 대해 추론해야 합니다. 각 RIBs 클래스는 구별된 책임을 가집니다. (i.e. routing, business logic, view logic, creation of other RIB classes) 추가로 parent RIB 로직은 child RIB 로직으로부터 분리되어 집니다. 이것은 RIB 클래스가 테스트 하기 쉽고 의존적이지 않게 만들게 하는데 용이합니다.

 

Tooling for Developer Productivity :

중요하지 않은 아키텍처 패턴을 채택하는 것은 강력한 도구 없이는 소규모 애플리케이션 이상으로 확장되지 않습니다. RIB는 코드 생성, 정적 분석 및 런타임 통합과 관련된 IDE 도구와 함께 제공되며, 이 모두는 크고 작은 팀의 개발자 생산성을 향상시킵니다.

 

Structured around Business Logic :

앱의 비지니스 로직 구조는 UI의 구조를 엄격하게 반영할 필요가 없습니다. 예를 들어, animation과 view performance를 용이하게 하기 위해 view 계층 구조는 RIB 계층 구조보다 얕을 수 있습니다. 또는 하나의 RIB은 UI 내에 다른 위치에 나타나는 세 가지 view의 모양을 제어할 수 있습니다. 

 

Explicit Contracts :

요구 사항은 컴파일 시간에 안전한 contract으로 선언되어야 합니다. 클래스 종속성과 순서 종속성이 충족되지 않으면 클래스가 컴파일되지 않아야 합니다. 여기에 순서 종속성을 나타내기 위해 ReactiveX를 사용합니다. type 안전 종속성 주입(DI) 시스템을 사용하여 클래스 종속성을 나타내고, 많은 DI 범위를 사용하여 데이터 불변성 생성을 권장합니다.

 

Parts of a RIB

예전에 VIPER 아키텍쳐에 대해 공부했다면, RIB의 클래스 분석이 친숙해 보일 것입니다. RIB는 일반적으로 다음 요소로 구성되며 모든 요소는 자체 클래스에서 구현됩니다.

Interactor

비지니스 로직을 가지고 있습니다. Rx subscription을 수행하고, state-altering decision을 만들고 데이터를 어디에 저장할지 결정하고 다른 RIBs들을 자식으로 가지고 있어야 하는지 결정합니다.

 

Interactor에 의해 수행되는 모든 operation은 lifecycle에 국한되어야 합니다. Interactor가 활성화된 경우에만 비즈니스 로직이 실행되도록 도구를 구축하고 있습니다. 이것은 Interator가 활성화되지 않았지만 subscription은 원치 않은 비지니스 로직이나 UI 상태를 업데이트 하는 것을 막습니다.

 

Router

Interactor를 listen하고 그 결과물을 자식 RIBs에 가지고 떼는(detach) 작업을 합니다. Router는 아래 3가지 이유로 존재합니다.

 

 1. router는 Humble Object처럼 행동한다. 그것은 테스트 복잡한 Interactor 로직을 child interactor를 mock하거나 다른 care를 필요하지 않게 하면서 테스트하기 쉽게 만들어준다. 

2. router는 parent interactor와 그 child interactor 사이 추상화된 계층을 만든다. 이것은 Interactors 간의 동기식 통신을 조금 더 어렵게 만들고 RIB 간의 직접 연결 대신 반응형 통신의 채택을 격려한다.

3. Interactor에 의해 구현되는 단순하고 반복적인 라우팅 로직을 포함하고 있다. 이것은 Interactor를 작게 유지하고 RIB에서 제공하는 핵심 비즈니스 로직에 더 집중하는 데 도움을 준다.

 

Builder

Builder의 책임은 모든 RIB의 구성 클래스와 각 RIB의 자식에 대한 빌더를 인스턴스화하는 것입니다.
Builder안에서 클래스의 생성 로직을 분리하는 것은 iOS에 mockability를 지원하고 나머지 RIB 코드들을 DI 구현의 세부 사항에 무관심하게 만듭니다. builder는 오직 RIB의 일부분으로 프로젝트에서 쓰이는 DI 시스템에 대해 알고 있어야 합니다.
다른 builder를 구현함으로서 다른 DI 메커니즘을 사용해 프로젝트에서 나머지 RIB 코드를 재사용 할 수 있게 됩니다.

 

Presenter

비지니스 모델을 뷰모델로 또는 뷰모델을 비지니스 모델로 변환하는 상태 없는(stateless) 클래스입니다. 뷰모델 변환 테스트를 용이하게 하는데 사용됩니다. 하지만 이런 변환은 자주 하찮은데 이것은 dedicated presenter 클래스의 생성을 보장하지 않기 때문입니다. presenter가 생략되면 뷰모델을 변환하는 것은 view 또는 interactor의 책임이 될 수 있습니다.

 

View(Controller)

view는 UI를 업데이트하고 빌드합니다. UI 컴포넌트를 인스턴스화, 레이아웃, 사용자 인터랙션 핸들링, 데이터와 animation과 함께 UI 컴포넌트 채우기 등을 포함합니다. View는 가능한 dumb하게 디자인 되어지는데, 오직 information을 보여줍니다. 일반적으로 유닛테스트 되어질 필요가 없는 코드들을 포함하지 않습니다.

 

Component

RIB의 dependencies를 관리하기 위해 사용됩니다. 빌더가 RIB를 구성하는 다른 단위를 인스턴스화하는 데 도움을 줍니다. RIB를 구축하는 데 필요한 외부 종속성에 대한 액세스를 제공할 뿐만 아니라 RIB 자체에 의해 생성된 종속성을 소유하고 다른 RIB에서 이에 대한 액세스를 제어합니다. 부모 RIB의 구성 요소는 일반적으로 부모 RIB의 종속성에 대한 자식 액세스를 제공하기 위해 자식 RIB의 빌더에 주입됩니다.