[Android] Design Pattern(디자인 패턴)이란?

● 디자인 패턴(Design Pattern)의 개념

디자인 패턴은 소프트웨어 공학에서 특정 Context에 공통적으로 발생하는 문제에 대해 재사용이 가능하도록 만들어 놓은 해결책이다. 이것은 개발자들이 개발을 하다보면 생기는 '자주', '반복적으로', '공통적으로' 해결해야할 문제가 있을 때 이를 해결하기 위해 쓰인다. 즉, 코드를 효율적으로 작성하기 위한 방법론, 건강한 소프트웨어 개발을 위한 방법론이라고 할 수 있다.

 

● 디자인 패턴을 이해하고 사용해야하는 이유

코딩을 할 때에는 많은 사람들이 이해할 수 있도록 짜는 것이 좋다. 왜냐하면 어떤 프로젝트를 진행한다고 했을 때에 자신만이 이해할 수 있는 코드로 작성한다면 유지 및 보수에 어려움이 생길 수도 있기 때문이다. 따라서 코딩을 하는 데에 있어서 디자인 패턴을 이해하고 적절하게 사용한다면 많은 사람들이 쉽게 읽을 수 있고, 이해할 수 있는 설득력 있는 코드가 될 것이다.

 

● Android Design Pattern(안드로이드 디자인 패턴)

안드로이드 앱을 논리적으로 체계화 시키기 위해서 MVC 패턴으로 시작하여 MVP, MVVM 패턴과 같이 더 모듈화 되고 테스트 가능한 패턴으로 발전해왔다.

 

● 디자인 패턴(Design Pattern)의 종류

MVC(Model View Controller)

MVP(Model View Presenter)

MVVM(Model View ViewModel)

	MVC	MVP	MVVM
View	1. 사용자에게 보여지는 UI를 나타낸다. 2. Model로부터 Data를 받아 사용자에게 보여준다.	1. 기본적인 것들은 MVC와 동일하나, Activity/Fragment가 View에 포함된다. 2. View를 관리하는 Interface를 추가하여 Presenter를 독립적으로 만들어준다.	1. 기본적인 것들은 MVC와 동일하나, Activity/Fragment가 View에 포함된다. 2. ViewModel을 관찰하여 UI를 갱신한다. 3. Data Binding을 위해 gradle과 xml을 수정해야한다. 4. 이를 통해서 View는 ViewModel에 의해 Model과 유연한 Binding이 가능해진다.
Model	1. 앱에서 사용되는 Data와 그 Data를 처리한다. 2. View에 의존적이지 않아서 재사용이 가능하다.	1. 앱에서 사용되는 Data와 상태에 대한 Business Logic을 처리한다. 2. View에 의존적이지 않아서 재사용이 가능하다.	1. MVC, MVP와 동일하다. 2. 기존 모델에 Business Logic을 추가하기 위해 MVVM에 SquareParams라는 Model을 추가했다. 3. DB 사용이나 Retrofit을 통한 백엔드 API 호출 등을 주로 수행한다.
	Controller	Presenter	ViewModel
	1. 사용자의 입력(Action)을 받고 처리한다. 2. 주로 Activity나 Fragment로 표현된다. 3. Model의 data 변화에 따라 View를 선택한다.	1. View와 Model 사이에서 data를 가공하고 전달하는 역할을 수행한다. 2. View가 요청한 정보를 Model로부터 받고 가공하여 View에게 전달한다. 3. Controller와의 차이점은 Interface라는 점이다.	1. 기본적으로 View에 종속되지 않는다.(그래서는 안된다) 2. Model을 래핑하고 View에 필요한 Observable data를 준비한다. 3. View가 Model에 Event를 전달할 수 있도록 Hook(BindingAdapter)을 준비한다.
동작	1. 사용자의 Action이 Controller에 들어온다. 2. Controller는 사용자의 Action을 확인하고, Model을 업데이트한다. 3. Controller는 Model을 나타내줄 View를 선택한다. 4. View는 Model을 이용하여 화면을 나타낸다.	1. 사용자의 Action이 View를 통해 들어온다. 2. View는 data를 Presenter에게 요청한다. 3. Presenter는 Model에게 data를 요청한다. 4. Model은 Presenter에게 요청받은 data를 반환한다. 5. Presenter는 View에게 data를 반환한다.	1. 사용자의 Action들은 View를 통해 들어오게 된다. 2. Command pattern으로 ViewModel에 Action을 전달한다. 3. ViewModel은 Model에게 data를 요청한다. 4. ViewModel은 응답받은 data를 가공하여 저장한다. 5. View는 ViewModel과 Data Binding하여 화면을 나타낸다.
특징	1. Controller는 여러 개의 View를 선택할 수 있는 1:N 구조이다. 2. Controller는 View를 선택할 뿐 직접 업데이트하지 않는다.(View는 Controller를 모른다) 3. View와 Model을 완벽하게 분리하고, Model 테스트가 용이하다.	1. Presenter는 View와 Model의 인스턴스를 가지고 있어 둘을 연결하는 역할을 한다. 2. Presenter와 View는 1:1 관계이다. 3. 단순 Interface이기 때문에 테스트가 용이하고 모듈화/유연성 문제가 해결되었다.	1. Command Pattern과 Data Binding을 사용하여 구현한다. 2. View와 Model 사이의 의존성이 없다. 3. View와 ViewModel 사이의 의존성도 없다. 4. 위처럼 모든 부분이 독립적이므로 모듈화가 가능하다.
단점	1. Controller가 Android API에 종속되어 테스트가 어렵다 2. View를 변경하면 Controller도 변경해야 한다. 3. 많은 코드들이 Controller에 집중되면 성능이 저하되고 유지보수가 어려워진다.	1. View와 Presenter 간의 의존성이 높다. 2. Android API를 참조해서는 안된다.(권장) 3. Controller와 같이 코드가 집중되면 성능이 저하되고 유지보수가 어려워진다.	1. ViewModel의 설계가 어렵다.(당연한..) 2. View가 변수와 표현식 모두에 Binding될 수 있으므로 갈수록 presentation logic이 늘어나 XML이 방대해진다. 이것을 방지하려면 항상 ViewModel에서 직접 값을 가져오는 것이 좋다.

 

● 참고) 디자인 패턴(Design Pattern)과 아키텍처 패턴(Architectural Pattern)

위와 같은 디자인 패턴들을 찾아볼 때 위 개념들을 아키텍처 패턴이라고도 하는 것을 찾아볼 수 있다. 아키텍처 패턴은 디자인 패턴과 유사하지만 범위가 더 넓다.

쉽게 생각해서 소프트웨어 공학에서 발생하는 문제를 해결한다는 점에서 디자인 패턴과 비슷하지만, 특정 문제를 해결하기 위한 디자인 패턴과는 다르게 전체적인 소프트웨어에서 발생하는 문제들을 해결한다는 점에서 차이점이 있다.