[디자인 패턴] Android MVP 디자인 패턴
카테고리를 Android로 할까, 디자인 패턴으로 할까 고민하다가, 그래도 주 내용이 디자인 패턴이니 해당 카테고리에 넣었다.
프로그램을 개발하는 방법에는 여러가지가 있고, 사람마다 그 방법도 각기 다르다.
하지만 어떤 것이 더 효율적인 코드일까를 고민하면서 나온 것이 디자인 패턴이다.
컴퓨터를 전공한 학부생들의 경우 한 번쯤은 이 개념과 관계된 수업을 들었을 것이다.
나 또한 마찬가지로 대학에서 처음 디자인 패턴을 접해봤으나,그것을 자기 것으로 만드는 데에는 번번히 실패해왔다.
그 이유 중의 하나가 디자인 패턴을 일종의 이론적 지식으로 인식하고 ,
예제를 거의 암기하듯이 머릿속에 우겨넣는 듯한 방식으로 진행했기 때문이 아닌가 생각한다.
시간이 조금흘러 디자인 패턴을 다시 공부하기로 마음먹었을 때, 찬찬히 뜯어보면서 한가지 깨달은 것이 있는데,
내가 코딩을 조금 더 편하게 하려고 스스로 바꿔본 구조가 알고보면 흔히 나오는 그런 디자인 패턴 중에 하나였던 것이다.
지금도 그러한 패턴은 잊어버리는 일 없이, 실무에서도 아주 잘 사용하고 있다.
이러한 경험에서도 알 수 있듯 굳이 디자인 패턴이 아니더라도, 코딩은 암기가 아니라 타자를 두들긴 횟수 만큼 성장한다는 생각이 든다.
그러한 생각에서 앞으로는 디자인 패턴을 이해하는 데에만 그치지 않고 직접 따라해보면서 그것이 왜 좋은지
음미하는 동시에 기록하는 시간을 가져볼까 한다.
내가 소개할 첫 번째 패턴은 안드로이드의 MVP 패턴이다.
안드로이드 개발을 진로로 삼고 있는 사람이라면 분명 들어보았을 것이다.
나도 졸업작품을 리팩토링하기 위해서 MVP 패턴을 적용해보려고 했으나 뭔가 감이 잘 안 잡히고 이해도 잘 되지 않았다.
이전에는 전통적으로 MVC 패턴이라고 해서 스프링에서 자주 사용되던 패턴이 있는데, 이것을 안드로이드에 맞게 가져온 것이 MVP 패턴이라고 보면 될 것 같다.
MVP 패턴은 각 모듈에게 주어진 역할의 이름에서 앞 글자씩을 따서 만들어진 이름이다.
각 역할은
- Model: 데이터의 저장과 조회
- View : 화면에 출력하는 작업
- Presenter: Model과 View와 함께 상호작용하면서, 기능적인 동작을 처리
MVP 패턴을 사용하지 않으면 하나의 Activity 내에서 뷰와 거기서 온 정보들을 처리하는 작업을 한 파일에 넣어놓은 적이 빈번했는데,
이는 하나의 클래스에 종속되는 결과를 낳아서 적지 않게 불편했던 기억이 있다.
MVP 패턴은 이러한 문제를 해소하고자 프로그램 진행에 있어 역할을 분담하여 서로를 독립적으로 처리하자는 생각에서 고안된 패턴이다.