<aside> 💡 이 페이지는 RIB에 대한 배경, 내용등 이론적인 부분이 정리되어 있고, 모든 내용은 RIBs 공식 페이지에서 발췌,참고,번역해서 본인의 생각을 조금 덧붙여서 작성되었습니다.

</aside>

RIBs?

정의

R(router) I(interacter) B(builder)

공식 GitHub에서 정의 한 바에 따르면 Cross-Platform architecture Framework이라고 정의 하고 있다. 이 말은 ios이건 android이건 모두 적용할 수 있는 architecture라는건데 여기서 여타의 design pattern인 MVP, MVVM, VIPER등에 과는 조금 다르게 Framework이라는 말을 사용하고 있다.

이는 여타의 design pattern과는 다르게 RIB라는 Framework를 이용해서 이것이 정의하는 design pattern을 생산해낼 수 있다는 의미를 내포하고 있다.

요약

조금 풀어서 설명하자면, MVP의 경우 그냥 model이나 view, presenter를 내가 직접 파일을 만들어서 이해한 방향 대로 한땀한땀 구현하면 그만이나, 이때 발생할수 있는 boilerplate code의 양이 무지막지 하다는것 정도는 다들 알고 있을것이다. RIB는 개념적으로는 여타의 design pattern과 같으나 이런 boilerplate code를 자동으로 generate해주는 무언가를 제공해준다. Framework을 단순하게 해석하면 건물의 "뼈대","골조" 이런걸로 해석될 수 있는데 이런 전체 구조의 기본이 되는 "뼈대"를 generate해서 개발자의 부담을 덜어주기 때문에 Framework이라고 (본인들이) 지징하는것으로 보인다.

Why?

RIBs의 장점은?

사실 RIBs 또한 여타의 design pattern과 최종 목적은 같다. 예를 들어, unit test를 용이하게 해준다거나, component로 잘 분리시킬수 있도록 구조가 되어 있어서 유지보수에 쉽다거나, 새로운 인력이 유입되어도 코드에 적응하는데 시간이 짧은것 등 기존 design pattern의 장점은 대부분 갖추고 있다.

RIBs 공식 사이트에 있는 장점을 요약하자면,

• Cross-Platform
  • iOS 와 Android 모두 적용가능하기 때문에 platform과 관계없이 review가 가능.
• Testability and Isolation
  • 독립적인 component 형태이기 때문에 테스트 용의.
  • 각각의 RIB들은 독립된 형태 및 responsibility 가짐.
• Productivity
  • 생산성 향상을 위한 Tool(code 를 generate, memory leak detection, static analysis, runtime integration)의 존재.
• Open-Closed Principle
  • 독립된 RIB는 다른 RIB에 영향을 주지 않고 개발이 가능하기 때문에 다수의 개발자들이 하나의 codebase를 공유/개발 하기에 용의.
  • 이는 유지/보수 및 신규 개발자의 유입도 용의함.
• Business Logic에 의한 구조
  • 기존 UI가 중점이던 코드 구조에서 벗어나 Business Logic에 의한 구조.
• Explicit Contracts
  • class의 Dependencies가 명확하지 않은 경우 compile time에 검출.

대부분 여타의 design pattern에서 강조하는 내용과 차이가 없으나 tool의 제공에 의해서 여타의 design pattern보다는 쉽게(?) 개발/오류검출/디버깅/유지 보수가 가능하다고 한다.