EunHee-Jeong/TIL

Programming Architecture History in iOS

Closed this issue · 0 comments

EunHee-Jeong commented

탄생 과정

  • 1950년대, 어셈블리어 ⇒ 순차적 프로그래밍 (단순한 명령어들의 나열)
  • 1970년대, C・Pascal ⇒ 절차적 프로그래밍 (if, for 함수)
  • 1980년대, C++・Java ⇒ 객체지향 프로그래밍 (클래스, 객체)

OOP는 현재까지도 이어져 내려오고 있으며, 시간이 흐르며 발전하는 과정 속에서 자연스레 유지 보수와 협업에 용이한 코드들의 구조와 노하우가 축적되었음.

  • 즉 데이터가 쌓이게 된 것 !
  • 이를 패턴화 한 것을 디자인 패턴이라고 한다.

이벤트 기반 프로그래밍을 위한 디자인 패턴

  • WEB, App → User Interface를 통해 이벤트를 받아와 처리함 (= 프로그래밍 함)
    • UI를 위해 고안된 디자인 패턴(프로그래밍 아키텍처)들 ⇒ MVC, Apple’s MVC (Cocoa-MVC), MVP, MVVM, VIPER, ... (시간 순임)

간략한 정리 ...

1. MVC

image

  • 뷰와 모델이 직접적으로 맞닿아 있음 !

2. Cocoa-MVC

  • Apple → Apple’s OS, IDE (Xcode) 구축 → User Interface Design Pattern에 대한 고려 ...

  • MVC... → 적합하지 않다.

    • 이유

      1. View는 App에서 모양과 느낌을 나타내는데, 일관성 있는 App의 느낌을 사용자에게 전달하기 위해서는 이 뷰들의 재사용성이 높아야 할 것이다.

      2. Model은 도메인 관련 데이터를 캡슐화 (ex - 네트워크 통신할 때 쓰는 구조체) 하는데,

        같은 형태의 데이터를 다른 곳에 또 쓰는 경우가 많다! → 모델도 재사용성이 높아야 한다.

  • 뷰와 모델의 재사용성이 높아야 한다면, 의존되지 않고 떨어져 있어야 할 것이다.

⇒ Apple’s MVC (Cocoa-MVC) 등장

image

  • 뷰와 모델이 분리되어 있는 것을 확인할 수 있다.
  • 하지만 다시 생각해보면 iOS 개발에서는 Cotroller가 그냥 컨트롤러가 아니라 “View"Controller 라고 되어 있었던 것을 확인할 수 있다. 즉 컨트롤러에서 View의 요소들 (= UI 요소들)을 건드릴 수 있다.
    • Controller의 몸집이 커지게 된다... Massive View Controller가 될 수 있다.

3. MVP

image

  • Controller의 역할을 덜어주고자 고안되었다.
  • ViewController도 View로 취급하고, 이를 대신할 중계자 역할을 Presenter가 맡는다.
    • 뷰컨에서는 꼭 거기서 처리해줘야 하는 작업 (뷰 생명주기, 화면 전환, call-back 처리 등...) 만 하게 한다.
  • Presenter는 View를 weak로 소유하고, 안의 요소들에 직접 접근하여 업데이트 하는데, 이렇게 되면 View를 업데이트하는 소스 코드들이 Presenter에 대부분 속하게 되어 View가 하는 역할이 애매해질 수 있다... (없어도 무방해질 수 있다는 소리)
  • 또한 Presenter와 View가 서로 소유한다는 것은 → 의존성이 크다는 소리인데, 그렇다면 MVC의 문제를 정말 해결했는지 다시 생각해보게 된다.

4. MVVM

image

  • 중계자가 Presenter에서 ViewModel로 바뀌었다.
  • View를 업데이트 하는 코드는 View에 들어가고, 이를 데이터 바인딩 으로 가져와 ViewModel에 연결한다.
    • 즉, 뷰 로직과 비즈니스 로직을 분리시켰다 ... !
    • Presenter ⇒ Model이라는 퍼즐 조각을 View라는 판에 맞춤
    • ViewModel ⇒ 퍼즐 조각을 View로 넘겨주기만 하고, 맞추는 것은 직접 하게 한다.
      • 이렇게 되면 테스트 코드를 작성할 때 UITest와 UnitTest로 분리할 수 있어 효율적이라고 한다. (아직 잘 모름 ...)
    • 또한 그동안 프로토콜과 함수들로 연결해줬던 것들을 → bind 로 처리하여 View와 Model 사이의 의존성과 코드의 양을 줄일 수 있다.
    • 하지만 디버깅이 어렵고, 성능 부하가 존재하는 비동기 프로그래밍의 특성과 / 규모가 커질 수록 ViewModel이 비대해지는 경향은 여전히 존재한다고 한다. (= 아직 애매한 듯)

추가적인 생각

저번에 VIPER를 공부하면서(알아보면서 ㅋㅋ) 너무 명확하게 세분화를 해놔서 오히려 코드 짤 때 불편할 것 같다는 생각을 했는데,

MVVM을 알아보며 디자인 패턴의 특성 상 명확한 가이드 라인이 없고, 어디에 넣을 지 애매한 것들이 많기 때문에 VIPER에서 아예 전부 모듈화 해버리려고 시도한 이유를 살짝 이해할 수 있었다 ...