EEYatHo 앱 깎는 이야기

Clean Architecture 개요 여느 다른 아키텍처 패턴들 처럼, 앱을 구성하는 여러 구성요소, 모듈들을 ( UI, ViewModel, Entity, Repository, DB 등 ) 바운더리치고 나눈 것. 바운더리의 기준 자주 변경되는 모듈이, 거의 변경되지 않는 모듈을 의존하도록 하자! + 테스트 용이성.. 등등? 변하지 않는 것을 안쪽으로, 자주 변하는 것을 바깥쪽으로 그림 의존성을 바깥쪽에서 안쪽으로 주입 (바깥쪽이 변경되어도, 안쪽이 변경될 필요 없게. ) ex1. ) DataSource가 API를 써서 데이터를 받든, 로컬 DB의 데이터를 가져오든.. 안쪽의 Repository는 변경되지 않도록. ex2. ) 반대로, 제일 안쪽의 Entity가 변경되었다면, DataSource의 Res..

ReactorKit 에서 테스트 대상 3가지로 나눠서 확인할 수 있다 View -> Reactor 유저의 인터렉션이 일어났을 때, Reactor 에게 기대되는 Action 을 넘기는지 Reactor -> View Reactor 에서 도달한 State 값에 따라 View 의 property 들이 기대한대로 설정되는지 Reactor Processing ( Action - mutation -> State ) 특정 State에서 특정 Action이 들어왔을 때 State 가 기대한대로 변경되는지 Stub ReactorKit 은 용이한 Test 를 위해, Reactor 에 Stub 이라는 기능을 제공한다. 아래처럼 Reactor 에서 Stub 기능을 사용할 것인지 설정할 수 있다. let reactor = MyR..

ReactorKit 공식 Git 링크 View 와 Reactor 을 가지고 화면을 만든다. View = UIView, UIViewController, UITableViewCell 등 Reactor = ViewModel. 비지니스 로직. ReactorKit 은 Flux 와 Reactive Programming 의 조합 부분적으로 도입이 가능하고, 라이브러리인 만큼, 공식 설명이 잘 되어있다. ReactorKit 의 디자인 목표 Testability : 뷰(View)와 비지니스 로직(Reactor)을 분리. Reactor는 View 에 대한 종속성이 없음. Small Start : RIBs 처럼 앱 전체가 하나의 아키텍쳐를 따를 필요 없음. 특정 화면에만 ReactorKit을 사용할 수 있음 Less Typ..

RIBs 정의 기존 디자인패턴들이, 비지니스 로직만 있는 ( 뷰가 없는 ) 모듈의 구현이 어려웠고, 이 점을 보완하여 Uber에서 VIPER를 개조한 것이 RIBs 이다. 화면로직이나, 비지니스로직을 RIB 이라는 모듈로 작성한다. RIB에게 UI요소(View, Presenter)는 옵셔널이다. ( 비지니스 로직만을 가진 모듈이 가능하다는 뜻 ) RIB들을 부모자식 관계로 이어서 논리적인 트리구조로 앱을 작성한다. -> 앱의 상태가 뷰가 아닌, 현재 activate된 RIB이 무엇인가에 따라 결정됨. 기존 MV*, VIPER같은 디자인패턴들이 SW설계시 참고할 수 있는 아키텍처라면, RIBs는 프레임워크다. Cocoa Pod이나 Carthage를 이용해서 설치하고, import 하는 형태다. RIB 구성..

View, Interactor, Presenter, Entity, Router 로 이루어져있다. Router를 통해, 화면전환을 처음으로 고려한 디자인 패턴이며, 각 요소가 하는 일, 특징은 다음과 같다. View UI요소들. VIewController 포함. 유저입력 수신. Presenter에 전달. Presenter에게 ViewModel 수신하며 update. Presenter을 소유함. Presenter View에게 유저 입력을 전달받음. Interactor에게 데이터 관련 요청 ( 데이터 만들어, 변경해, 나한테 줘. 등 ). Interactor에게 전달받은 데이터를 ViewModel로 가공하여 View에게 넘겨줌. Router에게 네비게이션 요청. Interactor을 소유함. Router에게 ..

MVVM을 제대로 이해하기 위해서는, MVVM이 나오는 이유와 배경을 알아야한다고 생각한다. MVVM은 디자인 패턴이다. 디자인 패턴은 어쩌다 나온 것인지를 알기 위해서는, 프로그래밍 패러다임의 변환을 살짝 핥아봐야한다. 1950년대, 어셈블리어와 함께, 순차적 프로그래밍이 나타났으며, ( 단순한 명령어들의 나열 ) 1970년대, C와 Pascal을 필두로, 절차적(절차지향) 프로그래밍이 나타났고, ( if, for, 함수의 등장 ) 1980년대 C++과 1990년대 Java를 통해, 객체지향 프로그래밍이 나타났다. ( 클래스, 객체의 등장 ) 객체지향 프로그래밍은 40년이라는 오랜 세월 동안, 현재까지도 이어져 내려오고 있으며, 수 많은 선조 프로그래머들의 노력 덕분에 유지보수와 협업에 용이한 "코드들..