디자인 패턴

CS 공부를 하면서 디자인 패턴에 대해서 간단하게 공부를 하게 되었다.
사실 이런 디자인 패턴이나 개발 방법론 등 이론적인 내용들은 글로는 이해가 되어도, 실제로 응용해서 사용하기는 어려울 때가 많은 것 같다.
그래서 간단하게 어떤 디자인 패턴들이 있고, 장/단점은 뭐가 있는지 정도 알면 좋을 것 같아 공부하게 되었다.

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

싱글톤 패턴(Singleton Pattern)

싱글톤 패턴은 하나의 클래스에 오직 하나의 인스턴스만 가지는 패턴이다.
하나의 클래스를 기반으로 여러 개별 인스턴스를 만들 수 있지만 하나의 클래스를 기반으로 단 하나의 인스턴스를 만들어 사용하는 방식을 싱글톤 패턴이라고 한다. 보통 데이터베이스 연결 모듈에 많이 사용한다.

const URL = "mongodb://localhost:3306/kjs";
const createConnection = (url) => ({ url: url });
class MongoDB {
  constructor(url) {
    if(!MongoDB.instance) {
      MongoDB.instance = createConnection(url)
    }
    return MongoDB.instance
  }

  connect() {
    return this.instance
  }
}

const mongoDB = new MongoDB(URL)

만약 이 코드에서 인스턴스 생성 시 생성자 조건문을 포함하고 있지 않다면 두 인스턴스는 서로 다르기 때문에 싱클톤 패턴 조건에 맞지 않게 된다.

단점

TDD 단위 테스트

TDD는 단위 테스트를 주로 하며, 단위 테스트는 서로 독립적이고, 어떤 순서로든 실행할 수 있어야 한다.
하지만 싱글톤 패턴으로 각 테스트마다 '독립적인' 인스턴스를 만들기 어렵다.

의존성 주입

모듈간의 결합을 강하게 만들 수 있다. 하지만 의존성 주입(Dependency Injection)을 통해 모듈 간의 결합을 느슨하게 만들어 해결할 수 있다.
의존성 주입은 메인 모듈이 '직접' 하위 모듈에 대한 의존성을 주입하지 않고, 중간에 '의존성 주입자'를 통해 간접적으로 의존성을 주입하게 되어 메인 모듈에 대한 의존성이 떨어지게 된다.

팩토리 패턴(Factory pattern)

팩토리 패턴은 상속 관계에 있는 두 클래스에서 상위 클래스가 중요한 뼈대를 결정하고, 하위 클래스에서 객체 생성에 관한 구체적인 내용을 결정하는 패턴이다.
상위 클래스와 하위 클래스가 분리되기 때문에 느슨한 결합을 가지며 상위 클래스의 인스턴스 생성 방식과 메서드 동작 방식에 대해서는 전혀 알 필요가 없다.

class Espresso {
  constructor() {
    this.name = "Espresso"
  }
}

class Latte {
  constructor() {
    this.name = "Latte"
  }
}

class EspressoFactory {
  static createCoffe() {
    return new Espresso()
  }
}

class LatteFactory {
  static createCoffe() {
    return new Latte()
  }
}

const factoryList = { LatteFactory, EspressoFactory }

class CoffeeFactory {
  static createCoffee(type) {
    const factory = factoryList[type]
    return factory.createCoffee()
  }
}

const coffee = CoffeeFactory.createCoffee("LatteFactory")

console.log(coffee.name) // latte

상위 클래스: CoffeeFactory
하위 클래스: LatteFactory, EspressoFactory

전략 패턴(strategy pattern)

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

예를 들어 물건을 사고 결제를 할 때 카카오페이 또는 네이버페이 등 다양한 결제 방식이 존재한다.

interface PaymentStrategy {
  pay(amount: number): void
}

class KakaoPayStrategy implements PaymentStrategy {
  private name: string;
  private cardNumber: string;
  private cvv: string;
  private dateOfExpiry: string;
  constructor(name: string, cardNumber: string, cvv: string, dateOfExpiry: string) {
    this.name = name
    this.cardNumber = cardNumber
    this.cvv = cvv
    this.dateOfExpiry = dateOfExpiry
  }

  pay(amount: number): void {
    console.log(amount + ' paid using KakaoPay')
  }
}

class NaverPayStrategy implements PaymentStrategy {
  private email: string;
  private pwd: string;
  constructor(email: string, pwd: string) {
    this.email = email
    this.pwd = pwd
  }

  pay(amount: number): void {
    console.log(amount + ' paid using NaverPay')
  }
}

class ShoppingCart {
  items: { name: string, price: number }[]
  constructor() {
    this.items = []
  }

  addItem(item: { name: string, price: number }) {
    this.items.push(item)
  }

  calculateTotal() {
    const sum = this.items.reduce((acc, cur) => {
      acc + cur.price
      return acc
    }, 0)

    return sum
  }

  pay(paymentMethod: PaymentStrategy) {
    const amount = this.calculateTotal()

    paymentMethod.pay(amount)
  }
}

const cart = new ShoppingCart()

cart.addItem({ name: 'apple', price: 1000 })
cart.addItem({ name: 'banana', price: 1500 })

cart.pay(new NaverPayStrategy('kjs@google.com', 'kjskjs'))

예시와 같이 전략만 바꿔서 결제방식을 변경할 수 있다.

옵저버 패턴(Observer Pattern)

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

• 주체: 객체의 상태 변화를 보고 있는 관찰자
• 옵저버: 객체의 상태 변화에 따라 전달되는 메서드 등을 기반으로 '추가 변화 사항'이 생기는 객체

ex) 트위터, 인스타그램
내가 어떤 사람(주체)를 '팔로우'했다면 주체가 글을 올릴때마다 알림이 '팔로워'에게 가야한다.

또한 옵저버 패턴은 주로 이벤트 기반 시스템에 사용하며 MVC 패턴에도 사용된다.

ex)
모델(model)에 변경 사항이 생기면 update() 메서드로 옵저버인 뷰에 알려주고 이를 기반으로 컨트롤러가 작동한다.

프록시 패턴(Proxy Pattern)

프록시 패턴(proxy pattern)은 대상 객체에 접근하기 전 그 접근에 대한 흐름을 가로채 대상 객체 앞단의 인터페이스 역할을 하는 디자인 패턴이다.
프록시 객체를 통해 속성, 변환 등을 보완하며, 보안, 데이터 검증, 캐시, 로깅에 사용한다.

나는 이 패턴이 node에서의 미들웨어와 같은 역할이라고 생각했다.
서버로 요청이 왔을 때 등록된 미들웨어가 요청을 가로채서 정의한 로직(유효성 체크, 인증 등)을 수행한 뒤 next()로 넘겨 다음 실제 로직을 수행할지 말지 결정할 수도 있다.

이는 우리가 알고 있는 프록시 서버로도 활용한다.

프록시 서버는 서버와 클라이언트 사이에 클라이언트가 자신을 통해 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해주는 컴퓨터 시스템 또는 응용프로그램을 가리킨다.
ex) nginx
nginx는 비동기 이벤트 기반의 구조와 다수의 연결을 효과적으로 처리 가능한 웹 서버이다.
실제 서버 앞에 nginx를 구축하면 익명 사용자의 직접적인 서버로의 접근을 차단하고 간접적으로 한 단계 더 거침으로써 보안성을 더욱 강화할 수 있다.
참고: https://dkswnkk.tistory.com/513

이터레이터 패턴(Iterator Pattern)

이터레이터 패턴(iterator pattern)은 이터레이터를 사용하여 컬렉션의 요소들에 접근하는 디자인 패턴이다.

노출모듈 패턴(Revealing Module Pattern)

노출모듈 패턴(revealing module pattern)은 즉시 실행 함수를 통해 private, public 같은 접근 제어자를 만드는 패턴을 말한다.

const pukuba = (() => {
	const a = 1
    const b = () => 2
    const public = {
    	c: 2,
      	d: () => 3
    }
    return public
})()
console.log(pukuba)
console.log(pukuba.a)
// { c: 2, d: [Function: d] }
// undefined

a와 b는 private 범위를 가지며 public의 c와 d는 public 범위를 가진다.

MVC 패턴

MVC 패턴은 모델, 뷰, 컨트롤러로 이루어진 디자인 패턴이다.
애플리케이션 구성 요소를 세 가지 역할로 구분하여 개발 프로세스에서 각각의 구성 요소에만 집중해서 개발할 수 있다.

• 장점: 재사용성과 확장성이 용이하다.
• 단점: 애플리케이션이 복잡해질수록 모델과 뷰의 관계가 복잡해진다.

모델

모델은 애플리케이션의 데이터인 데이터베이스, 상수, 변수 등을 의미한다.
뷰에서 데이터를 생성하거나 수정하면 컨트롤러를 통해 모델을 생성, 갱신한다.

뷰

뷰는 inputbox, checkbox, textarea등 사용자 인터페이스 요소를 나타낸다. 모델을 기반으로 사용자가 볼 수 있는 화면을 뜻하며 모델이 갖고 있지 않은 정보를 따로 저장하지 않아야 한다.
뷰에서 변경이 일어나면 컨트롤러에 전달하여 모델을 수정한다.

MVP 패턴

MVP 패턴은 MVC 패턴으로부터 파생되었고 MVC 패턴의 C인 컨트롤러가 프레젠터로 교체된 패턴이다.
뷰와 프레젠터는 일대일 관계로 MVC패턴보다 더 강한 결합을 지닌 디자인 패티언이다.

MVVM 패턴

MVVVM 패턴은 MVC의 C인 컨트롤러가 뷰모델로 바뀐 패턴이다. 여기서 뷰모델은 뷰를 더 추상화한 계층이며, 뷰와 뷰모델 사이의 양방향 데이터 바인딩을 지원하여 UI를 별도의 코드 수정 없이 재사용할 수 있고, 단위 테스트하기 쉽다는 장점이 있다.