[Android]Design Pattern

🌟 Design Pattern이란?

소프트웨어 디자인에서 공통적으로 발생하는 문제에 대해 재사용 가능한 해결책을 말한다. 상황에 맞게 사용될 수 있는 문제들을 해결하는데에 쓰이는 템플릿을 의미한다. 프로그래머가 어플리케이션이나 시스템을 디자인할 때 공통된 문제들을 해결하는데에 쓰이는 형식화 된 가장 좋은 패턴이다. 단적으로는 '코드를 효율적으로 작성하기 위한 방법론', 궁극적으로는 건강한 소프트웨어 개발을 위한 방법론이라고 할 수 있다.
​

🌟 안드로이드의 디자인 패턴

Android에서 유명한 architecture에는 MVC, MVP, MVVM가 존재한다.

🔹MVC (Model View Controller)

MVC 패턴은 Model, View, Controller로 구성되어 있다.

• Model(모델): 어플리케이션의 데이터를 저장하는 역할을 담당한다. <데이터 + 상태 + 비즈니스 로직>을 다룬다.
  SQLite, File, content provider가 이 영역에 속한다. View에 의존적이지 않기 때문에 재사용이 가능하다.

• View(뷰): 화면 구성을 담당하는 영역이다. View 클래스를 상속하는 클래스를 사용해서 구성할 수 있다.
  Model로부터 data를 받아 사용자에게 보여준다.

• Controller(컨트롤러): View와 Model을 서로 연결하고 제어하는 영역이다.
  activity, service, broadcast receiver, fragment가 포함된다.
  사용자의 입력(Action)을 받고 처리한다. Model의 data 변화에 따라 View를 선택한다.

• 동작
  (1) 사용자의 Action이 Controller에 들어온다.
  (2) Controller는 사용자의 Action을 확인하고, Model을 업데이트한다.
  (3) Controller는 Model을 나타내줄 View를 선택한다.
  (4) View는 Model을 이용하여 화면을 나타낸다.

• 특징
  (1) Controller는 여러 개의 View를 선택할 수 있는 1:N 구조이다.
  (2) Controller는 View를 선택할 뿐 직접 업데이트하지 않는다.(View는 Controller를 모른다)
  (3) View와 Model을 완벽하게 분리하고, Model 테스트가 용이하다.

• 단점
  (1) Controller가 Android API에 종속되어 테스트가 어렵다
  (2) View를 변경하면 Controller도 변경해야 한다.
  (3) 많은 코드들이 Controller에 집중되면 성능이 저하되고 유지보수가 어려워진다.
  (4) 라이브와 데이터 변경이 빈번한 application 일수록 치명적일 수 있다.

​

🔹MVP (Model View Presenter)

MVP 패턴은 안드로이드에서 가장 많이 사용하는 것으로 알려진 패턴으로, Model, View, Presenter로 구성되어 있다.

• Model(모델): 데이터와 관련된 처리를 담당한다. MVC의 Model과 동일하다.

• View(뷰): 이벤트가 발생하면 Presenter로 알린 후 반환받은 것에 따라 UI를 갱신한다.

• Presenter(프레젠터): MVC의 Controller의 역할이지만 View에 전혀 연결되어 있지 않은 인터페이스이다.
  View에서 전달받은 이벤트를 처리하여 다시 View로 반환한다.
  Model에 데이터 요청이 필요한 이벤트가 들어오는 경우 Model에 요청한 후 받은 데이터를 View에 전달한다.

• 동작
  (1) 사용자의 Action이 View를 통해 들어온다.
  (2) View는 data를 Presenter에게 요청한다.
  (3) Presenter는 Model에게 data를 요청한다.
  (4) Model은 Presenter에게 요청받은 data를 반환한다.
  (5) Presenter는 View에게 data를 반환한다.

• 특징
  (1) Presenter는 View와 Model의 인스턴스를 가지고 있어 둘을 연결하는 역할을 한다.
  (2) Presenter와 View는 1:1 관계이다.
  (3) 단순 Interface이기 때문에 테스트가 용이하고 모듈화/유연성 문제가 해결되었다.

• 단점
  (1) View와 Presenter 간의 의존성이 높다.
  (2) Android API를 참조해서는 안된다.(권장)
  (3) Controller와 같이 코드가 집중되면 성능이 저하되고 유지보수가 어려워진다.

​

🔹MVVM (Model View ViewModel)

MVVM 패턴은 Model, View, ViewModel로 구성되어 있다.

• Model(모델): 데이터와 관련된 처리를 담당한다. 데이터가 변경되면 ViewModel을 거쳐서 View로 전달된다.
  안드로이드에서는 LiveData나 RxJava 등을 통해 구현할 수 있다.

• View(뷰): 화면에 표현되는 레이아웃을 관리한다.
  View는 Model은 알지 못하기 때문에 ViewModel을 옵저빙하고, 상태 변화가 전달되면 화면을 갱신해야 한다.
  Data Binding을 위해 gradle과 xml을 수정해야한다. View는 ViewModel에 의해 Model과 유연한 binding이 가능하게 된다.
  

• ViewModel(뷰모델): View에 연결할 데이터와 명령으로 구성되어 있으며 변경 알림을 통해 View에게 상태 변화를 전달한다. ViewModel은 Model은 알지만 View는 알지 못한다. (기본적으로 View에 종속되지 않는다.)
  View가 Model에 Event를 전달할 수 있도록 Hook(BindingAdapter)을 준비한다.

• 동작
  (1) 사용자의 Action들은 View를 통해 들어오게 된다.
  (2) Command pattern으로 ViewModel에 Action을 전달한다.
  (3) ViewModel은 Model에게 data를 요청한다.
  (4) ViewModel은 응답받은 data를 가공하여 저장한다.
  (5) View는 ViewModel과 Data Binding하여 화면을 나타낸다.

• 특징
  (1) Command Pattern과 Data Binding을 사용하여 구현한다.
  (2) View와 Model 사이의 의존성이 없다.
  (3) View와 ViewModel 사이의 의존성도 없다.
  (4) 위처럼 모든 부분이 독립적이므로 모듈화가 가능하다.

• 단점
  (1) ViewModel의 설계가 어렵다.(당연한..)
  (2) View가 변수와 표현식 모두에 Binding될 수 있으므로 갈수록 presentation logic이 늘어나 XML이 방대해진다. 이것을 방지하려면 항상 ViewModel에서 직접 값을 가져오는 것이 좋다.

​

🌱 참고 자료

1. [Android] 디자인 패턴, 아키텍처 패턴
2. [안드로이드] 디자인 패턴(MVC, MVP, MVVM)
3. [Android] 디자인 패턴 (MVC, MVP, MVVM)
4. [Android] 아키텍처 패턴 - MVC, MVP, MVVM