[디자인 패턴] MVC, MVVM, Singleton 등 디자인 패턴에 대해

 

디자인 패턴이란 프로그램을 설계할 때 발생했던 문제점들을 객체 간의 상호 관계 등을 이용하여 해결할 수 있도록 하나의 ‘규약’ 형태로 만들어 놓은 것을 의미한다.

 

- Singleton(싱글톤)

- Factory Method(팩토리 패턴)

- Strategy(전략 패턴)

- Observer

- MVC

- MVP

- MVVM

 

등의 패턴이 있다.

---

싱글톤 패턴

 

싱글톤 패턴(singleton pattern)은 하나의 클래스에 오직 하나의 인스턴스만 가지는 패턴이다. 하나의 클래스를 기반으로 여러 개의 개별적인 인스턴스를 만들 수 있지만, 그렇게 하지 않고 하나의 클래스를 기반으로 단 하나의 인스턴스를 만들어 이를 기반으로 로직을 만드는 데 쓰이며,보통 데이터베이스 연결 모듈에 많이 사용한다.

 

하나의 인스턴스를 만들어 놓고 해당 인스턴스를 다른 모듈들이 공유하며 사용하기 때문에 인스턴스를 생성할 때 드는 비용이 줄어드는 장점이 있다. 하지만 의존성이 높아진다는 단점이 있다.

class Singleton {
    constructor() {
        if (!Singleton.instance) {
            Singleton.instance = this
        }
        return Singleton.instance
    }
    getInstance() {
        return this.instance
    }
}
const a = new Singleton()
const b = new Singleton() 
console.log(a === b) // true

---

팩토리 패턴

 

팩토리 패턴(factory pattern)은 객체를 사용하는 코드에서 객체 생성 부분을 떼어내 추상화한 패턴이자 상속 관계에 있는 두 클래스에서 상위 클래스가 중요한 뼈대를 결정하고, 하위 클래스에서 객체 생성에 관한 구체적인 내용을 결정하는 패턴이다.

상위 클래스와 하위 클래스가 분리되기 때문에 느슨한 결합을 가지며 상위 클래스에서는 인스턴스 생성 방식에 대해 전혀 알 필요가 없기 때문에 더 많은 유연성을 갖게된다. 그리고 객체 생성 로직이 따로 떼어져 있기 때문에 코드를 리팩터링하더라도 한 곳만 고칠 수 있게 되니 유지 보수성이 증가한다.

예를 들어 라떼 레시피와 아메리카노 레시피, 우유 레시피라는 구체적인 내용이 들어 있는 하위 클래스가 컨베이어 벨트를 통해 전달되고, 상위 클래스인 바리스타 공장에서 이 레시피들을 토대로 우유 등을 생산하는 생산 공정을 생각하면 된다.

 

const num = new Object(42)
const str = new Object('abc')
num.constructor.name; // Number
str.constructor.name; // String

숫자를 전달하거나 문자열을 전달함에 따라 다른 타입의 객체를 생성하는 것을 볼 수 있다. 즉, 전달받은 값에 따라 다른 객체를 생성하며 인스턴스의 타입 등을 정한다.

 

See the Pen Factory 패턴 by Facite (@facitea) on CodePen.

---

전략 패턴(strategy pattern)은 정책 패턴(policy pattern)이라고도 하며, 객체의 행위를 바꾸고 싶은 경우 ‘직접’ 수정하지 않고 전략이라고 부르는 ‘캡슐화한 알고리즘’을 컨텍스트 안에서 바꿔주면서 상호 교체가 가능하게 만드는 패턴이다.

전략 패턴을 사용하면, 객체의 행동을 변경하고자 할 때, 객체 자체를 수정하는 대신 행동을 구성하는 알고리즘을 바꾸어, 객체의 행동을 변경할 수 있다. 이러한 방식으로, 객체들 간의 결합도를 낮추고, 유연성과 확장성을 높일 수 있다.

 

예를 들어, 온라인 쇼핑몰에서는 다양한 결제 수단을 제공하며, 각 결제 수단마다 다른 결제 방식을 갖는다. 따라서, 사용자가 선택한 결제 수단에 따라 결제 방식을 실행해야 한다.

이 때, 전략 패턴을 사용하면, 결제 수단 선택 기능과 결제 기능을 분리하여 구현할 수 있다. 결제 수단 선택 기능은 결제 수단을 선택하는 인터페이스로 정의하고, 구체적인 결제 수단 클래스들은 이 인터페이스를 구현한다. 또한, 결제 기능은 선택한 결제 수단에 따라 다른 결제 방식을 구현하는 인터페이스로 정의하고, 구체적인 결제 방식 클래스들은 이 인터페이스를 구현한다.

이렇게 구현하면, 사용자가 선택한 결제 수단에 따라 결제 수단 선택 기능을 사용하여 적절한 결제 수단 객체를 선택하고, 결제 기능을 사용하여 선택한 결제 수단 객체의 결제 방식을 실행할 수 있다. 이 때, 결제 수단 선택 기능과 결제 기능은 서로 분리되어 있기 때문에, 새로운 결제 수단을 추가하거나 기존 결제 수단의 결제 방식을 변경해도, 쇼핑몰 객체를 수정할 필요 없이, 새로운 결제 수단 클래스와 결제 방식 클래스를 추가하거나 변경하여 사용할 수 있다.

즉, 전략 패턴을 사용하면, 유연성과 확장성이 높은 코드를 작성할 수 있으며, 객체 간의 결합도를 낮춰 유지보수를 용이하게 할 수 있다.

---

옵저버 패턴

 

옵저버 패턴(observer pattern)은 주체가 어떤 객체(subject)의 상태 변화를 관찰하다가 상태 변화가 있을 때마다 메서드 등을 통해 옵저버 목록에 있는 옵저버들에게 변화를 알려주는 디자인 패턴이다.

 

여기서 주체란 객체의 상태 변화를 보고 있는 관찰자이며, 옵저버들이란 이 객체의 상태 변화에 따라 전달되는 메서드 등을 기반으로 ‘추가 변화 사항’이 생기는 객체들을 의미한다.

 

또한, 옵저버 패턴은 주로 이벤트 기반 시스템에 사용하며 MVC(Model-View-Controller) 패턴에도 사용된다.
예를 들어, 주체라고 볼 수 있는 모델(model)에서 변경 사항이 생겨 update() 메서드로 옵저버인 뷰에 알려주고 이를 기반으로 컨트롤러(controller) 등이 작동한다.

Vue.js 3.0에서 ref나 reactive로 정의하면 해당 값이 변경되었을 때 자동으로 DOM에 있는 값이 변경되는데, 이 또한 옵저버 패턴을 이용하여 구현한 것이다.

---

MVC패턴

 

MVC 패턴은 모델(Model), 뷰(View), 컨트롤러(Controller)로 이루어진 디자인 패턴이다.

 

애플리케이션의 구성 요소를 세 가지 역할로 구분하여 개발 프로세스에서 각각의 구성 요소에만 집중해서 개발할 수 있다. 재사용성과 확장성이 용이하다는 장점이 있고, 애플리케이션이 복잡해질수록 모델과 뷰의 관계가 복잡해지는 단점이 있다.

모델(model)은 애플리케이션의 데이터인 데이터베이스, 상수, 변수 등을 뜻한다.
예를 들어 사각형 모양의 박스 안에 글자가 들어 있다면 그 사각형 모양의 박스 위치 정보, 글자 내용, 글자 위치, 글자 포맷(utf-8 등)에 관한 정보를 모두 가지고 있어야 한다. 뷰에서 데이터를 생성하거나 수정하면 컨트롤러를 통해 모델을 생성하거나 갱신한다.

 

뷰(view)는 inputbox, checkbox, textarea 등 사용자 인터페이스 요소를 나타낸다. 즉, 모델을 기반으로 사용자가 볼 수 있는 화면을 뜻한다. 모델이 가지고 있는 정보를 따로 저장하지 않아야 하며 단순히 사각형 모양 등 화면에 표시하는 정보만 가지고 있어야 한다.
또한, 변경이 일어나면 컨트롤러에 이를 전달해야 한다.

컨트롤러(controller)는 하나 이상의 모델과 하나 이상의 뷰를 잇는 다리 역할을 하며 이벤트 등 메인 로직을 담당한다. 또한, 모델과 뷰의 생명주기도 관리하며, 모델이나 뷰의 변경 통지를 받으면 이를 해석하여 각각의 구성 요소에 해당 내용에 대해 알려준다.

 

See the Pen Observer 패턴 by Facite (@facitea) on CodePen.

---

MVP 패턴

 

MVP 패턴은 MVC 패턴으로부터 파생되었으며 MVC에서 C에 해당하는 컨트롤러가 프레젠터(presenter)로 교체된 패턴이다.

뷰와 프레젠터는 일대일 관계이기 때문에 MVC 패턴보다 더 강한 결합을 지닌 디자인 패턴이라고 볼 수 있다.

프레젠터는 뷰와 모델 사이에서 중개자 역할을 수행하며, 뷰에서 발생하는 이벤트를 처리하여 모델에게 데이터를 요청하고, 모델이 반환한 데이터를 다시 뷰에게 전달한다.

 

이로 인해, MVP 패턴은 테스트 용이성과 유지보수성이 높아지는 장점이 있다. 하지만, 구조가 복잡해질 수 있다는 단점도 있다.

See the Pen MVP 패턴 by Facite (@facitea) on CodePen.

---

MVVM 패턴

 

MVVM 패턴은 MVC의 C에 해당하는 컨트롤러가 뷰모델(view model)로 바뀐 패턴이다.

 

여기서 뷰모델은 뷰를 더 추상화한 계층이며, MVVM 패턴은 MVC 패턴과는 다르게 커맨드와 데이터 바인딩을 가지는 것이 특징이다. 뷰와 뷰모델 사이의 양방향 데이터 바인딩을 지원하며 UI를 별도의 코드 수정 없이 재사용할 수 있고 단위 테스팅하기 쉽다는 장점이 있다.

 

MVVM 패턴을 가진 대표적인 프레임워크로는 뷰(Vue.js)가 있다. Vue.js는 반응형(reactivity)이 특징인 프런트엔드 프레임워크이다. 예를 들어 watch와 computed 등으로 쉽게 반응형적인 값들을 구축할 수 있다.

함수를 사용하지 않고 값 대입만으로도 변수가 변경되며 양방향 바인딩, html을 토대로 컴포넌트를 구축할 수 있다는 점이 특징이다. 재사용 가능한 컴포넌트 기반으로 UI를 구축할 수 있으며 BMW, 구글, 루이비통 등에서 사용한다.

 

See the Pen MVVM 패턴 by Facite (@facitea) on CodePen.

---

MVC 패턴과 MVVM 패턴 차이

 

MVC 패턴에서는 모델(Model), 뷰(View), 컨트롤러(Controller)로 구성된다.

 

• 모델은 데이터 처리를 담당하고,
• 뷰는 UI를 표시하며,
• 컨트롤러는 모델과 뷰를 중개하여 이들 간의 통신을 관리한다.

사용자가 뷰를 조작하면,

• 컨트롤러가 이벤트를 수신하고,
• 모델에게 필요한 데이터를 요청하고,
• 모델은 요청받은 데이터를 처리하여 컨트롤러에게 반환한다.
• 컨트롤러는 다시 뷰에게 반환받은 데이터를 전달하여 UI를 업데이트한다.

 

반면, MVVM 패턴에서는 모델(Model), 뷰(View), 뷰모델(ViewModel)로 구성된다.

• 뷰모델은 뷰에서 필요한 데이터와 명령을 처리하고, 모델과 뷰를 연결하는 역할을 한다.
• 뷰(View)는 사용자 인터페이스를 담당하고,
• 뷰모델(ViewModel)은 뷰에서 발생한 이벤트를 처리하여 모델(Model)에게 데이터를 요청하고,
• 모델은 처리된 데이터를 뷰모델에게 반환한다.
• 뷰모델은 반환받은 데이터를 가공하여 뷰(View)에게 전달하여 UI를 업데이트한다.
  
  

---

쉽게 생각해서 코드를 역할별로 나누어 놓고

 

인터페이스, 데이터, 로직 파트로 분류 후

화살표로 코드의 흐름을 이어가다 보면

 

내가 만든 코드가 어느 디자인 패턴에 맞는지 가늠해볼 수 있다.

---

결론, 디자인 패턴에 맞게, 유지보수가 용이하게, 코드를 작성하기 위해서는

코드를 작성하기 이전에 역할에 따른 분류부터 해보자.

 

그래야 코드를 작성하면서도 유지보수를 자연스럽게 고려하게 된다.

 

데이터의 흐름을 고려하여 역할에 따라 코드를 나누어 작성하면

자연스레 유지보수가 용이한 코드가 된다.

 

팀 단위의 개발에서는 더더욱 이런 코드가 빛을 발하게 될 것이다.