디자인 패턴
- 설계를 할 때 자주 발생하는 문제들을 피하기 위해 사용되는 패턴
- 과거 소프트웨어 개발 과정에서 발견된 설계의 노하우를 축적한 결과들을 재이용하기 좋은 형태로 특정 규약을 묶어서 정리한 것
왜 사용되는가?
- 여러 사람이 협업해서 개발할 때 다른 사람이 작성한 코드, 기존 코드를 이해하는 것은 어려움
- 이런 코드를 토대로 추가, 수정 등의 작업을 해야하는데 이 때 원치 않는 결과, 버그를 발생시키게 된다.
- 또한 성능의 최적화를 시키기 어렵기도 하다.
- 이러한 이유로 시간과 예산의 소모가 막심하다.
- 디자인 패턴을 활용은 일종의 인터페이스이자 규약이다.
- 이를 통해 개발에 있어 불필요한 소통을 줄이며 직관적이고 간단하게 의도한 바를 개발할 수 있다.
디자인 패턴의 종류
- gof라는 네 명의 컴퓨터 과학 연구자들이 쓴 서적에 23개의 디자인 패턴을 정리해주며 정말 다양한 디자인 패턴을 명시해주었다.
- 디자인 패턴을 다음 이미지로 크게 정리를 하며 향후 디자인 패턴에 대해 공부를 할 필요성을 느끼게 되었다.
Android Design Pattern
- 다양한 디자인 패턴들이 있으며, 안드로이드 개발을 하면서 자주 보는 디자인 패턴들을 위주로 볼 것이다.
- 크게 3종류 MVC, MVP, MVVM은 디자인 패턴의 아키텍처 패턴에 속하며 이를 보자
MVC
- Model-View-Controller의 구성으로 이루어진 아키텍쳐 형태
- Model
- 데이터, 상태, 비즈니스 로직을 다룸
- View나 Controller에 묶여 있지 않아 재사용이 가능함
- 프로젝트 내에서 쓰이는 데이터를 저장하고, 가공 처리 역할 담당
- View
- UI
- 모델의 내용들을 표현
- Controller
- Model과 View의 중간에서 데이터 변경이나 상호 작용을 관리하여 View, Model을 갱신한다.
- Model
- MVC의 이점
- 완벽히 모델과 뷰를 분리한다.
- 모델을 쉽게 단위 테스트가 가능하다.
- 단점
- Controller가 안드로이드에 깊게 종속되므로 컨트롤러 테스트에 문제 발생
- 프로젝트를 수정하거나 새로운 기능을 추가할 때
- 많은 코드가 하나의 코드에 모이고 비대해지므로 유지보수에 어려움
MVP
- MVC의 문제저점을 해결하기 위해 나온 패턴
- Controller를 분리하여 책임을 줄이고 View와 Controller가 자연스럽게 결합되도록 만든 형태
- Model
- MVC와 다를 바가 없다.
- View
- Activity/Fragment가 View의 일부분으로 간주
- Activity가 View Interface를 상속받아 이를 통해 View에 결합하는 것을 제거
- View의 모의 구현으로 단위 테스트가 가능
- Presenter
- Controller의 역할과 유사
- View와 전혀 연결되어 있지 않은 인터페이스
- 이를 통해 모듈화/유연성 문제를 해결
- 단, 그 어떤 안드로이드 api도 참조해서는 안된다.
- Model
- MVP의 이점
- MVC에 비해 코드가 깔끔해진다.
- 뷰와 프레젠터가 1:1 대응으로 구현했다면, Presenter를 쉽게 테스트 할 수 있다.
- 단점
- 프로젝트를 수정하거나 새로운 기능을 추가할 때
- 많은 코드가 프레젠터에 모이고 비대해지므로 유지보수에 어려움
- 프로젝트를 수정하거나 새로운 기능을 추가할 때
MVVM
- Data-binding을 사용하여 더 수월한 테스트 및 모듈화의 이점을 제공
- 옵져버 패턴과 매우 유사함
- Model
- MVC와 다를 바가 없다.
- View
- 가변적인 방식으로 ViewModel에 의해 노출되는 관찰 가능한 변수 및 작업에 바인딩된다.
- ViewModel
- Model을 래핑하고 View에 필요한 관찰 가능한 데이터를 준비한다.
- 뷰가 이벤트를 모델에 전달하기 위한 hook을 제공한다.
- ViewModel은 뷰와 연결되지 않는다.
- 정확히는 연결되어서는 안된다.
- Model
- MVVM의 이점
- 뷰에 대한 의존도가 없으므로 MVP처럼 가상의 뷰를 만들 필요가 없다.
- 데이터 변화를 추적하며 테스트할 수 있다.
- ViewModel과 View의 종속성이 1:N 관계임로 코드의 양을 줄일 수 있다.
- 뷰에 대한 의존도가 없으므로 MVP처럼 가상의 뷰를 만들 필요가 없다.
- 단점
- 프로젝트를 수정하거나 새로운 기능을 추가할 때
- xml, view model, binding adapter에 코드를 추가하게되며 비대해지므로 유지보수에 어려움
- 프로젝트를 수정하거나 새로운 기능을 추가할 때
- Android에서는 공식적으로 MVVM 패턴에 대해 aac를 JetPack 라이브러리로 제공하고 있다.
- 하지만, 그렇다고 꼭 MVVM만을 쓰는 것이 옳은 것만은 아니다.
- 각각의 장단점이 있으며, 현재 프로젝트가 어떤 아키텍쳐가 더 적절하고 그에 대한 장점을 최대한 끌어올 수 있는 지가 중요하다고 생각한다.