MVVM 사태와 OO

3 min readMar 14, 2017

페이스북에서 MVVM 과 관련 된 스레드를 읽고 글을 남긴다.

TL;DR

패턴이 뭐가 중요할까. 그냥 그 객체가 어디까지 어떤 책임을 지는지만 명확하면 되지 않을까?

페이스북 스레드를 읽으면서 드는 생각은

사람들이 생각하는 OO 의 목표가 서로 다르다

사실 나도 내가 이해한 SOLID 가 맞는 건지 모른다 (이게 다 학교 교육이 무너져서).

어쨌든 간단하게 SOLID 원칙을 리뷰하면

뒤에 principal 만 붙이면 객체지향의 5원칙 SOLID 가 된다.

사실 DIP 를 제외한 나머지는 거짓말이 아니고 진짜로 귀에 못이 박히도록 듣는 내용이기에 맞다 틀리다를 논의할 필요도 없다.

DIP 의 경우 여기에서 램프 예제가 가장 직관적이고 이해하기 쉽다.

전설적인 1 발표자 1 청중인 STAC 에서 발표한 ‘콜팝으로 OO 생각하기

MVP 모델도 위에 SOLID 와 같이 사골 중에 사골인데 정말 교과서적인 설명은

모델 —프레젠터 — 뷰 구조를 통해 모델과 뷰, 그리고 비즈니스 로직을 분리한다

이거 한 줄.

하지만 실제로 MVP 를 적용해보면 대부분

(1 뷰) — (1 프레젠터) — (n 모델 )

코드가 생겨나는 데, 초기 목적인 비즈니스 로직 분리는 어느정도 달성하지만, 1 대 1 로 강하게 view 와 presenter 를 커플링하는 코드를 작성하게 된다.

MVVM 에서 하려고 하는 일은 view 와 presenter 사이의 dependency 를 줄이기 위해 presenter 레이어를 아예 view 독립적으로 만든다.

물론 말이야 쉽지만, view 를 모르고 어떻게 view 에 정보를 표현하는지가 문제다.

여기서 DIP 가 나온다.

Presenter(e.g. view model) 에서 할 수 있는 작동은 각각의 view 들이 등록한 핸들러를 호출만 한다.
view 는 presenter 가 특정 핸들러를 호출할 때 넘겨주는 값들을 화면에 적절히 표시만 하면된다.

만약 내가 android 에서 직접 구현 한다면

이 정도가 되지 않을까?

view 는 그리는 책임 presenter 는 변화를 알리는 책임 으로 책임을 명확하게 분리하는 걸 목표로 했다 (presenter 클래스에는 view 라는 명시적인 클래스가 없다)
기존에 view — presenter 를 SOLID 원칙을 만족하면서 잘 떼어냈기에 만족스러운 느낌 :)

물론 silverlight 이나 WPF 는 위와 같이 저렴한 방법이 아닌 xml 등을 다양한 방법으로 매핑을 했다고 하는데 공부하던 때에는 열심히 고생했던 기억 밖에 없다.

(위에 슈도코드가 MVVM 이 맞을 가능성은 엄청 낮다.)

그래도 풀 문제가 명확하면 어려운 패턴이 아니더라도 SOLID 원칙과 객체 책임의 경계(?) 만 머리 속에서 까먹지 않고 잘 풀어가면 해결의 방법이 보이는 것 같다.