재사용 단위를 무엇으로 봐야할까? 재사용 전략?

재사용의 단위

• 컴포넌트
• View
• VC
• VC + VM
• Coordinator

의문 모듈화를 통해서 해당 단위에대한 소유권이 있는데, 누가 소유해야하는지? 또, 그렇게 해서 의존성 그래프에 문제가 생기는 건 아닌지?

Case. 컴포넌트 재사용

컴포넌트는 같지만 다른 화면

예시

• 닉네임 입력화면과 번호입력화면

Case. View 재사용

뷰는 같지만, 다른 로직을 수행하거나, 추가된 로직이 있음

예시

• Chat의 프로필화면과 Like의 프로필화면. Like 프로필화면은 좋아요/싫어요 뷰 및 기능이 추가됨

Case. VC 재사용

VC까지 같지만 VM의 Logic이 다를 때 기존 MVVM + Input/Ouput 패턴을 이용해서 VM의 재사용이 힘듦었음. 해당 VM의 Input/Output 정의를 protocol화하면 해결해 볼 수도 있을 것 같음.

Case. VC + VM 재사용 vs Coordinator 재사용에 대한 Trade off

VC + VM을 재사용 단위로 봐서 Factory로 만들어서 재사용하기 -> Coordinator는 Factory들을 이용하여 해당 피처에 맞게 조립함.

Pros

• 재사용되는 페이지에 대한 Coordinator를 만들 필요가 없어서 boiler plate코드에 대한 부담이 줄어듦
• Coordinator에 대한 depth가 줄어들기 때문에 복잡도가 줄어듦
• 네비게이션 스택 관리 편함

Cons

• ViewModel에 대한 Input/Ouput 프로토콜화가 선행되어야함
• Factory로 생성 코드 boiler plate 만들어짐

예시

LikeCoordinator
  ㄴ HomeFlow
  ㄴ ChatRoomFlow
  ㄴ ProfileFlow
  ㄴ BlockAlert
  ㄴ ReportAlert

VC + VM을 Wrapping한 Coordinator를 만들어서 Coordinator를 재사용함.

Pros

• Factory 생성 코드 필요 없음.
• 구조 변경할 일이 줄어듦.
• Coordinator 책임이 적음.

Cons

• 재사용되는 화면마다 Coordinator로 Wrapping 해줘야함, boiler palte 코드 증가
• Coordinator 뎁스로 인해서 복잡도 증가
• coordinator, buildable property 들고있어야함

예시

LikeCoordinator
  ㄴ ChatRoomCoordinator
      ㄴ HomeFlow
      ㄴ ProfileFlow
          ㄴ AlertCoordinator
             ㄴ BlockAlert
             ㄴ ReportAlert

절충

Alert같은 거만 Factory 이용해서 뎁스 줄이기