나무's 블로그

본 포스트는 온라인 강의를 통해 스터디 진행한 후 정리하는 포스트이다.

강의 초반에서 지속적으로 Composition 이란 개념을 일깨워준다.

Composition = 구성
Composition(in IT) = 객체와 데이터타입을 조합하여 어려운 객체나 데이터 타입을 만든다.

Composition을 잘 활용한다면 SOLID 원칙의 SRP(단일 책임 원칙)를 잘 지킬 수 있다고 한다.

Composition의 활용

어떤 아키텍처든지 Massive를 벗어날 수 있다 (MVC - VC, MVVM - VM 등 하나의 클래스가 너무 많은 코드를 갖게 되는 현상)

-> 다만, Composition을 잘만 활용한다면 !

상속

• 상속은 꼭 필요할 때만 사용하라
  • 부모의 메소드를 거부하기 위해서, 빈 override를 활용할 수도 있음
    • (이런 상황은 별도의 Protocol을 선언해서 구현하는 편이 낫지 않나?)

원칙

이전에 클린코드, 클린아키텍처 등의 스터디를 진행하면서 느꼈던 점이다.

"적힌 모든 챕터들의 내용은 읽다보면 당연하게 생각했지만, 나는 실제로 그것들을 모두 지키면서 개발하고 있는가?" 

-> 절대 아니었다. 그리고 강의에서는 "원칙을 100프로 지킬 필요는 없지만, 최대한 지키면서 진행해야 유연해진다."

-> (원칙들을 지키고자하는 코드와 처음부터 무시한 코드는 다를 것이다. 는 것을 느꼈다)

객체의 Composition의 예

하나의 아이폰 화면내부에 하나의 VC만 두지 않는 예이다.

A와 B의 기능/서비스를 분리하여 2개의 VC로 나누었으며 C라는 VC를 두어 A와 B를 관리한다.

-> C의 역할을 하는 VC는 흔히 NavigationViewController, TabBarViewController 등이 있다.

Composition = 블랙박스 -> 숨길 수 있는 것들은 숨기며 공유

상속 = 화이트박스 -> 거의 대부분의 많은 것들을 공유

와 같다.

이외의 내용들은 예제 프로젝트를 진행하는 것이었다.

RIBs 아키텍처 패턴
Uber에서 만든 아키텍처로 수백명에 이르는 개발자들이 기존 MVC 패턴에 한계를 느껴
VIPER 패턴을 개선시켜 Uber에 적용시킨 패턴

MVC

기존 MVC 패턴에서의 한계 및 개선

• 모듈/소스코드들의 의존성이 깊어 빌드시, 빌드 시간이 길다
  • 빌드 시간은 개발자에게 필요한 가장 큰 자원이다.
  • 모듈화를 통해 각각의 모듈/서비스 단위를 각각 개발하여 재활용이 가능하다.
• 모듈/서비스가 증가함으로서 테스트하기 어려워졌다.
• Massive ViewController

VIPER

• View
• Interactor : 비즈니스 로직을 담당, 서버 API 혹은 DB를 통해 받은 Data를 받아 Entity로 생성
• Presenter : View에서 유저 액션을 받고, Interactor에 Data를 요청하여 View 갱신을 요청
• Entity : Interactor에 의해 만들어진다
• Router : 화면 전환 담당

장점

• Interactor는 단순히 데이터의 호출을 통해 Entity를 담당
  • Entity의 변화는 Rx와 같은 Observer 패턴을 이용하여 Presenter에게 전달(?)
• Presenter는 비즈니스 로직을 갖고 Presentation 로직을 포함
• Presenter와 Interactor는 UNIT Test가 가능하다

단점(VIPER 패턴을 그대로 사용하지 않고 RIBs로 개선한 이유)

• 전체 App 상태가 View에 의해 구동되는 View Driven App Logic으로서 비즈니스 로직만 갖고 싶은 노드를 생성하기 어려움
  • View만을 담당하는 노드 / 비즈니스로직만을 담당하는 노드로 상호 관계로 인해서 떼어내기 힘듬

RIBs

특징

RIBs = Router, Interactor, Builder 의 약자이며, 하나의 RIB(Riblet)에는 필수적으로 들어가는 것을 의미한다.

Riblet ~= 노드

구성요소

• Router
  • 자식 RIB을 attach, detach하여 RIBs 논리적 트리 구조를 형성한다.
• Interactor
  • 비즈니스 로직을 담당
  • Router로 Routing Call, RIB의 attach와 detach를 요청
  • Presenter로 Data Model을 전달한다
• Builder
  • RIB의 모든 구성요소를 생성하고 DI를 정의한다.
    • DI : 자신과 자식 RIB들에게 전달해야 할 Dependency를 정의
  • 이름 그대로 Router, Interactor, View, Component를 모두 생성한다.
• Component
  • 부모 RIB Builder가 Component(Protocol)를 통해 자식 RIB Builder로 의존성을 주입한다.
  • 따라서 의존성을 전달받은 자식 RIB은 Component를 사용한다고 보면 됨
  • DI
• View
  • UI를 생성하고 구현
  • UI Event를 preseneter로 전달하거나, Delegate 패턴을 사용한다.
  • 또한 ViewModel을 Observing 함으로써 UI가 업데이트된다.
• Presenter
  • VIPER패턴과 비슷하게 Interactor와 View 사이에서 통신을 담당한다
  • 비즈니스 모델을 ViewModel로 변환을 담당
  • Presenter가 생략되는 경우
    • Data -> ViewModel 변환을 View 혹은 Interactor가 담당

궁금점

Q: Presenter와 View는 왜 필수 요소가 아닌가?

A

• 기존 VIPER 패턴의 경우 모든 노드에 Presenter와 View가 포함되었다
  • 이것이 바로 VIPER를 개선시킨 원인이었다 -> View Driven App
• 화면이 필요없는 서비스/기능가 존재한다
  • Viewless RIB의 필요성을 느꼈다
  • 따라서 Presenter와 View를 구현하지 않은 RIB은 View를 갖지 않는 RIB이 된다