디자인 패턴(Design Pattern)
객체 지향 프로그래밍 설계 시 자주 발생하는 문제를 해결하기 위해 디자인 패턴을 사용합니다. 특히 여러 사람이 협업하는 개발 환경에서, 다른 사람이 작성한 코드나 기존 코드를 이해하고 수정하는 것은 매우 어려운 작업입니다. 코드를 변경하거나 새로은 기능을 추가할 때 의도하지 않은 결과나 버그를 발생할 수 있으며, 성능 최적화도 까다롭습니다. 이러한 문제를 방지하고 개발 시간 및 비용을 절약하기 위해 디자인 패턴을 활용합니다. 디자인 패턴은 공통 문제에 대한 검증된 해결책을 제공함으로써, 코드의 가독성과 재사용성을 높이고, 팀 내의 기술적 의사소통을 원활하게 합니다.
MVC
MVC ⇒ Model + View + Controller 를 합친 용어
구조
Model : 어플리케이션에서 사용되는 데이터와 비지니스 로직을 관리하는 부분
View : 사용자에게 보여지는 UI 부분
Controller : Model과 View 사이를 이어주는 인터페이스 역할
동작
MVC 패턴의 동작 순서
- 사용자의 Action이 Controller에 들어오게 됩니다.
- Controller는 사용자의 Action을 확인하고, Model을 업데이트합니다.
- Controller에서 업데이트된 Model을 나타내줄 View를 선택합니다.
- View는 업데이트된 Model을 이용하여 화면을 나타냅니다.
특징
Controller 는 여러개의 View 를 선택할 수 있는 1:n 구조입니다.
장점
- 서로 역할이 분리되어 각자의 역할에 집중할 수 있습니다. → 협업할 때 맡은 부분의 개발에만 집중할 수 있어 효율성증가합니다.
- 동시다발적개발 : 백엔드 개발자와 프론트엔드 개발자가 독립적으로 개발진행이 가능합니다.
- 유지보수성, 애플리케이션의 확장성, 유연성 증가
- 중복 코딩의 문제점이 사라집니다.
단점
MVC 패턴의 단점은 View와 Model 사이의 의존성이 높다는 것입니다.
복잡한 대규모 프로그램을 개발하게 되면 문제점이 발견됩니다.
→ 다수의 View와 Model이 Controller를 통해 복잡하게 연결될 수 있기 때문에 Controller가 뚱뚱해지게 됩니다.
→ 이러한 현상을 Massive-View-Controller현상이라고 합니다.
→ 수정시 테스트가힘들고, 파악이 어렵기 때문에 여러 Side-Effect를 불러오게 되는 문제점 발생합니다.
→ 그래서 MVC는 위 문제점을 보완하기 위해 다양한 패턴들을 파생시켰습니다.(MVP, MVVM, Flux, Redux 등)
MVP
MVP ⇒ Model + View + Presenter를 합친 용어
Model 과 View는 MVC 패턴과 동일하고, Controller 대신 Presenter가 존재합니다.
기존의 MVC 패턴을 보안하기 위한 패턴이며 MVC 의 Model View가 의존 관계였던걸 해결하기 위해 고안된 패턴입니다.
구조
Model : 어플리케이션에서 사용되는 데이터와 비지니스 로직을 관리하는 부분
View : 사용자에게 보여지는 UI 부분
Presenter : View에서 요청한 정보를 Model로 가공하여 View에 전달해 주는 부분
동작
MVP 패턴의 동작 순서
- 사용자의 입력이 View를 통해 들어오게 됩니다.
- View는 데이터를 Presenter에게 요청합니다.
- Presenter는 Model에게 데이터를 요청합니다.
- Model은 Presenter에서 요청받은 데이터를 응답합니다.
- Presenter는 View에게 데이터를 응답합니다.
- View는 Presenter가 응답한 데이터를 이용하여 화면을 나타냅니다.
특징
Presenter는 View와 Model의 인스턴스를 가지고 있어 둘을 연결하는 접착제 역할을 합니다.
Presenter와 View는 1:1 관계입니다.
장점
MVP 패턴의 장점은 View와 Model의 의존성이 없다는 것입니다.
MVP 패턴은 MVC 패턴의 단점이었던 View와 Model의 의존성을 해결하였습니다.
MVP 패턴은 앱을 구성하는 코드를 기능단위로 분해(모듈화)하기 때문에 협업시 유리해졌습니다.
모듈화를 했기 때문에 소스파일 관리, 테스트가 용이 해집니다. → 유지보수가 쉬워집니다.
단점
MVC 패턴의 단점인 View와 Model 사이의 의존성은 해결되었지만, View와 Presenter 사이의 의존성이 높은 가지게 되는 단점이 있습니다.
어플리케이션이 복잡해 질 수록 View와 Presenter 사이의 의존성이 강해지는 단점이 있습니다.
MVVM
MVVM ⇒ Model + View + View Model를 합친 용어
구조
Model : 어플리케이션에서 사용되는 데이터와 비지니스 로직을 관리하는 부분
View : 사용자에게 보여지는 UI 부분
View Model : View를 표현하기 위해 만든 View를 위한 Model입니다. View를 나타내 주기 위한 Model이자 View를 나타내기 위한 데이터 처리를 하는 부분
동작
MVVM 패턴의 동작 순서
- 사용자의 요청은 View를 통해 들어오게 됩니다.
- 사용자의 요청이 들어오면, View Model에 요청을 전달합니다.
- View Model은 Model에게 데이터를 요청합니다.
- Model은 View Model에게 요청받은 데이터를 응답합니다.
- View Model 은 응답 받은 데이터를 가공하여 저장합니다.
- View는 View Model과 Data Binding 을 하여 화면을 나타냅니다.
특징
MVVM 패턴은 Command 패턴과 Data Binding 두 가지 패턴을 사용하여 구현되었습니다.
Command 패턴과 Data Binding을 이용하여 View와 View Model 사이의 의존성을 없앴습니다.
View Model과 View는 1:n 관계입니다.
장점
- MVVM 패턴은 View와 Model 사이의 의존성이 없습니다.
- 늘어나는 코드 알갱이 조각과 분리 경계로 인하여, 확장성이 높은 동시에 유지보수성을 얻게 됩니다.→ 각각의 부분은 독립적이기 때뭉네 모듈화하여 개발할 수 있습니다.
- 뷰를 추상화해서 비즈니스 로직 뒤에 있는 코드가 줄어들게 합니다.
- 로직과 프레젠테이션 계층은 느슨하게 결합됩니다.
- 어설픈 UI 자동화 도구 없이 테스트가 가능합니다.
단점
- View Model의 설계가 쉽지 않습니다.
- 데이터 바인딩이 필수적으로 요구됩니다.
- 복잡해질수록 Controller처럼 ViewModel이 빠르게 비대해집니다.
- 표준화된 틀이 존재하지 않아 사람마다 이해가 다릅니다.
Data Binding : Model과 UI 요소 간의 싱크를 맞춰주는 것
참고
