[안드로이드] 디자인 패턴(MVC, MVP, MVVM)

김민규·2021년 9월 16일
10

안드로이드

목록 보기
2/4
post-thumbnail
post-custom-banner

여러 채용 사이트에서 채용공고를 보다보면

MVP/MVVM/Clean Architecture 등 아키텍쳐 설계 혹은 적용 경험이 있으신 분

자격요건에 위 문구가 적혀있는 것을 본 적이 있을 것이다. 이게 대체 뭐길래 중요하다는 걸까?

하지만 절대 의문을 가져서는 안된다. 실무에서 중요하다고 하는건 다 이유가 있는법이고,
몰라서 좋을게 없다는 뜻도 된다.(사실 실무경험이 없어서 더욱 그렇게 생각한다..OTL)

그리하여 오늘 알아볼 것은 디자인 패턴이 무엇이며, 모바일 어플리케이션 개발에 자주 사용되는 디자인 패턴은 무엇인가?에 대한 내용이다.


디자인 패턴

1) 소프트웨어 공학

디자인 패턴을 공부하기 전에, 우선 소프트웨어 공학이라는 것을 알아야한다.
컴퓨터공학부 학생이라면 소프트웨어 공학과 관련된 수업을 들어본 적이 있을 것이다.

혹시 있을지 모를 비전공자들을 위해 설명하자면 소프트웨어 공학이란,
소프트웨어의 개발/운용/유지보수 등의 생명주기를 체계적이고 서술적이고 정ㄹ.... 그렇다고 한다.

그냥 간단하게 말하자면 공학을 소프트웨어에 적용함으로써 '건강한 소프트웨어'를 만들기 위한 학문이다.

2) 디자인 패턴

디자인 패턴 또한 소프트웨어 공학에서 특정 문맥에 공통적으로 발생하는 문제에 대해
재사용이 가능하게 만들어놓은 해결책이다.

개발자들이 어플리케이션/시스템을 디자인할 때 발생하는 공통된 문제들을 해결하기 위해 쓰인다.
단적으로는 '코드를 효율적으로 작성하기 위한 방법론', 궁극적으로는 건강한 소프트웨어 개발을 위한 방법론이라고 할 수 있다.

음... 설명만 들어서는 디자인 패턴이 어떻게 '체계적이고 건강한' 소프트웨어를 만드는데 도움이 되는지 도통 알 수가 없다. 이 설명을 듣던 내 건강이 나빠지는 기분이 막 들고 그런다.

3) 안드로이드 디자인 패턴

안드로이드 앱을 논리적 구성 요소들로 체계화하려는 노력은 지속되어 왔다.
가장 기초적인 MVC(Model View Controller) 패턴으로 시작하여
더 모듈화되고 테스트 가능한 패턴으로 발전해 왔다.

대표적으로 MVP(Model View Presenter), MVVM(Model View ViewModel)이 MVC를 대체하기 위해 가장 많이 쓰이는 방법론이다. 물론 둘 중에 어느게 더 낫다는 정답은 없다.

건너건너 들은 얘기지만 열정적인 개발자들을 모아 디자인패턴에 대한 토론을 시작하면,
방금 먹은 점심이 다 소화되고 어느덧 저녁시간이 되는 경우도 심심치 않다고 한다.
그만큼 각 디자인패턴의 특장점이 확실하고, 상황에 따른 방법론의 선택이 중요하다는 뜻이기도 하다.



그럼 이제 본격적으로 안드로이드 개발 시에 많이 사용하는 패턴들에 대해 알아보자.


1) MVC

  • View
    (1) 사용자에게 보여지는 UI를 나타낸다.
    (2) Model로부터 data를 받아 사용자에게 보여준다.

  • Model
    (1) 어플리케이션에서 사용되는 data와 그 data를 처리한다.
    (2) View에 의존적이지 않기 때문에 재사용이 가능하다.

  • Controller
    (1) 사용자의 입력(Action)을 받고 처리한다.
    (2) 주로 Activity나 Fragment로 표현된다.
    (3) 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에 집중되면 성능이 저하되고 유지보수가 어려워진다.


2) MVP

  • View
    (1) 기본적인 것들은 MVC와 동일하나, Activity/Fragment가 View에 포함된다.
    (2) View를 관리하는 Interface를 추가하여 Presenter를 독립적으로 만들어준다.

  • Model
    (1) 어플리케이션에서 사용되는 data와 상태에 대한 business logic을 처리한다.
    (2) View에 의존적이지 않기 때문에 재사용이 가능하다.

  • Presenter
    (1) View와 Model 사이에서 data를 가공하고 전달하는 역할을 수행한다.
    (2) View가 요청한 정보를 Model로부터 받고 가공하여 View에게 전달한다.
    (3) Controller와의 차이점은 Interface라는 점이다.

  • 동작
    (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와 같이 코드가 집중되면 성능이 저하되고 유지보수가 어려워진다.


3) MVVM

  • View
    (1) 기본적인 것들은 MVC와 동일하나, Activity/Fragment가 View에 포함된다.
    (2) ViewModel을 관찰하여 UI를 갱신한다.
    (3) Data Binding을 위해 gradle과 xml을 수정해야한다
    (4) 이를 통해 View는 ViewModel에 의해 Model과 유연한 binding이 가능하게 된다.
  • Model
    (1) MVC, MVP와 동일하다.
    (2) 기존 모델에 business logic을 추가하기 위해 MVVM에 SquareParams라는 Model을 추가했다.
    (3) DB 사용이나 Retrofit을 통한 백엔드 API 호출 등을 주로 수행한다.

  • ViewModel
    (1) 기본적으로 View에 종속되지 않는다.(그래서는 안된다)
    (1) Model을 래핑하고 View에 필요한 Observable data를 준비한다.
    (2) 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에서 직접 값을 가져오는 것이 좋다.


상당히 글자가 많고 읽기 싫게 생긴 설명이네요. 하지만 어쩔 수 없습니다.
디자인패턴을 공부해보니 이렇게 구구절절 설명되어 있는 포스팅도 보고, 코드를 실행해봄으로써 풀이해주는 포스팅도 같이 보는 것이 제일 도움이 되었습니다.
개발자라고 이론에 약해도 되는것은 아니니까요.

저는 요즘 핫하다는 MVVM을 적용하며 공부하고 있습니다. MVVM을 적용한 기업들이 대다수이기도 할 뿐더러, Data Binding의 편리함이 너무 크게 다가오더라구요.

공부하면 할수록 지금껏 얼마나 무지한 개발을 해왔는지 깨닫습니다.
원래는 하루빨리 첫 직장에 취업해서 일하고 싶었는데, 이 실력이라면 민폐만 끼칠게 분명하니 차근차근 내공을 쌓는것이 우선인 것 같습니다.
1일 1포스팅을 목표로 매일 열심히 공부하고 개발하다 보면 언젠가는 그런 날이 오겠죠?! ㅠㅜ


앞으로는더 정확한 정보전달과 학습을 위해 노력하겠습니다.
부족한 포스팅 읽어주셔서 감사합니다. (_ _)

profile
키보드를 좋아합니다.
post-custom-banner

1개의 댓글

comment-user-thumbnail
2023년 7월 5일

이번에 네이버 부스트캠프 안드로이드 코스에 합격해서 안드로이드 개발에 첫 발을 디딘 지망생 입니다!
좋은 글 감사드립니다!

답글 달기