안드로이드 아키텍처와 클린 아키텍처를 공부하는 첫 걸음으로 MVVM에 대해 알아보겠습니다. 아직 많이 부족한 부분이 많지만 천천히 알아가보겠습니다 🔥
📌 디자인 패턴이란?
디자인 패턴은 조상님들의 경험이 담긴 문제 해결 방법입니다.
사람들은 수 많은 경험을 바탕으로 특정 상황에서 발생하는 문제 패턴을 발견하고 해결 방안을 기록으로 남겼습니다. 이를 디자인 패턴 이라고 부릅니다.
📕 디자인 패턴의 장점
재사용성 : 반복적인 문제에 대한 해결책을 제공해 유사한 상황에서 코드를 더 쉽게 작성할 수 있습니다.
가독성 : 코드를 일정한 구조로 정리하고 명확하게 작성하여 코드를 이해하고 유지보수하기 쉽게 만듭니다.
유지보수성 : 코드를 쉽게 모듈화 할 수 있으며, 변경이 필요한 경우 해당 모듈만 수정하여 유지보수가 쉬워집니다.
확장성 : 새로운 기능을 추가하거나 변경할 때 디자인 패턴을 활용하여 기존 코드를 변경하지 않고도 새로운 기능을 확장할 수 있습니다.
🎉 예시
Singleton 패턴 : 객체의 인스턴스가 오직 1개만 생성 🤔 조상님들은 여러 클래스에서 동일한 기능을 하는 함수로 인한 코드의 중복을 없애고 싶지 않았을까?
이렇게 구현하고 클래스를 세번 생성하게 되면 불필요한 메모리 릭이 발생합니다.
그래서 나온게 싱글톤! Kotlin에선 Object 키워드를 사용해 구현할 수 있습니다.😎 사용 예시
📌소프트웨어 아키텍쳐
소프트웨어 아키텍처는 소프트웨어 시스템의 구조와 구성 요소들이 어떻게 조직되고 상호작용하는지를 설계하는 것을 말합니다.
💡 아키텍처는 시스템의 큰 그림을 그리는 역할을 합니다.
예를 들어, 우리가 사용하는 스마트폰 앱은 화면을 보여주고 사용자의 입력을 받아 처리한 뒤 필요한 데이터를 서버로부터 가져오는 역할을 합니다.
이때 화면을 보여주거나 사용자의 입력을 받는 부분, 입력받은 데이터를 처리하는 부분, 데이터를 가져오는 부분 등 각각의 역할이 있고, 이들이 어떻게 조합되어 동작하는지를 아키텍처로 설계합니다.
📌 MVVM
👨💻 MVVM의 등장 배경
📖 MVC
Model - View - Controller 로 구성된 아키텍처
MVC 는 안드로이드에서 강한 의존성(Tight Coupling)으로 인한 문제가 발생합니다.
💡 Coupling : 서로 상호작용하는 시스템들간의 의존성
어느 한 곳을 변경할 경우 같이 변경해야 하는 경우가 많아진다.
View를 수정할 경우 Controller를 같이 수정해야 하는 경우가 생긴다.
Controller를 수정할 경우 Model을 같이 수정해야하는 경우가 생긴다.
이러한 문제를 해결하기 위해 느슨한 결합(Loose Coupling)을 지향하는 아키텍처가 등장
📖 MVVM
MVVM 은 Model - ViewModel - Model 의 약자입니다. 위의 소프트웨어 아키텍처에 대입하면 조금더 이해가 쉬울 것 같습니다.
💡 화면을 보여주는 부분 : View 입력받은 데이터를 처리하는 부분 : ViewModel 데이터를 가져오는 부분 : Model
1️⃣ Model
Model은 데이터와 비즈니스 로직을 담당하는 부분입니다. 데이터베이스, 외부 API 등과 같은 데이터 소스와 상호작용
Model은 독립적으로 존재하며, View나 ViewModel에 대한 의존성이 없습니다.
2️⃣ View
View는 사용자에게 정보를 시각적으로 표현하는 부분입니다.
주로 UI(사용자 인터페이스) 요소들로 이루어져 있으며, 사용자의 입력을 받고 결과를 표시하는 역할을 합니다.
사용자와 직접 상호작용하며, ViewModel과의 의존성이 있습니다.
데이터를 직접 처리하지 않고 ViewModel을 통해 필요한 데이터를 요청하거나 업데이트합니다.
3️⃣ViewModel
ViewModel은 View와 Model 사이의 매개체 역할을 합니다.
View에서 발생하는 사용자 입력을 처리하고, 필요한 데이터를 Model로부터 가져와 View에 제공합니다.
또한, View에 표시될 데이터를 가공하고 필요한 형식으로 변환하는 역할도 수행합니다.
4️⃣ 정리
MVVM 아키텍처의 핵심은 View와 비즈니스 로직을 완전히 분리합니다.
ViewModel은 View와 독립적으로 개발하고 테스트할 수 있으며, View는 단순히 데이터를 표시하고 사용자 입력을 전달하는 역할에 집중할 수 있습니다.
이를 통해 코드의 재사용성과 유지 보수성을 향상시킬 수 있습니다.
5️⃣ 클린 아키텍처 관점에서의 MVVM
단일 책임 원칙(Single Responsibility Principle, SRP)
Model, View, ViewModel은 각자 분리된 역할(책임)을 가집니다.
이를 통해 각 구성 요소는 자신의 책임에만 집중할 수 있으며 높은 응집성과 낮은 결합도( high cohesion loose coupling)를 가질 수 있습니다.
개방 폐쇄 원칙 (Open-Closed Principle, OCP)
ViewModel은 인터페이스를 통해 View와 소통하며, View는 ViewModel의 인터페이스를 통해 데이터를 전달받습니다.
이를 통해 새로운 기능의 추가나 변경이 발생해도 기존의 코드를 수정하지 않고도 확장할 수 있습니다.
즉, 기존의 코드를 개방하지 않고 새로운 기능을 추가할 수 있는 유연한 아키텍처를 제공합니다.
여기서 인터페이스는 예를 들어, 버튼의 클릭 이벤트를 ViewModel로 전달하기 위해 View에서는 ClickEventListener, View와 ViewModel 사이의 인터페이스로는 데이터 바인딩을 위한 Observable 인터페이스를 말하는 것 같습니다.
리스코프 치환 원칙 (Liskov Substitution Principle, LSP)
ViewModel은 View와 Model 사이의 중재자 역할을 수행하므로, View와 Model 사이에서 자유롭게 교체할 수 있습니다.
이를 통해 새로운 View나 Model을 추가하거나 기존의 View나 Model을 변경해도 시스템의 일관성을 유지할 수 있습니다.
인터페이스 분리 원칙 (Interface Segregation Principle, ISP)
View는 ViewModel의 인터페이스를 통해 필요한 데이터와 명령을 전달받으며, ViewModel은 View의 인터페이스를 통해 데이터를 업데이트합니다.
이를 통해 각 구성 요소는 자신이 필요로 하는 인터페이스에만 의존하게 되어, 인터페이스의 명확성과 응집성을 높일 수 있습니다.
의존성 역전 원칙 (Dependency Inversion Principle, DIP)
View는 ViewModel에 의존하고, ViewModel은 Model에 의존합니다.
이를 통해 고수준 모듈(ViewModel)이 저수준 모듈(Model)에 의존하도록 구조를 조정하여, 시스템의 유연성과 확장성을 높일 수 있습니다.MVVM 은 Model - ViewModel - Model 의 약자입니다. 위의 소프트웨어 아키텍처에 대입하면 조금더 이해가 쉬울 것 같습니다.</aside>
Model은 데이터와 비즈니스 로직을 담당하는 부분입니다. 데이터베이스, 외부 API 등과 같은 데이터 소스와 상호작용
