[BOOK] 디자인 패턴 (Design Pattern)

개발자가 프로그래밍할 때 쓰는
React.js, Vue.js 등의 라이브러리나 프레임워크의 기본이 되는 디자인 패턴의 종류와 특징들에 대해 알아보자.

디자인 패턴

소프트웨어 개발 방법에서 사용되는 디자인 패턴은 프로그램 개발에서 자주 나타나는 과제를 해결하기 위한 방법 중 하나로,

과거의 소프트웨어 개발 과정에서 발견된 설계의 노하우를 축적하여 이름을 붙여, 이후에 재이용하기 좋은 형태로 특정의 규약을 묶어서 정리한 것이다. 
알고리즘과 같이 프로그램 코드로 바로 변환될 수 있는 형태는 아니지만, 특정한 상황에서 구조적인 문제를 해결하는 방식을 설명해 준다.

- 위키백과 - 

---

• 싱글톤 패턴 (singleton pattern)
  
  • 하나의 클래스에 오직 하나의 인스턴스만 가지는 패턴.
  • 데이터베이스 연결 모듈에 많이 사용.
  • 장점 :
    하나의 인스턴스를 만들어 놓고 해당 인스턴스를 다른 모듈들이 공유하며 사용하기 때문에 인스턴스를 생성할 때 드는 비용이 줄어든다.
  • 단점 :
    • TDD를 할 때 걸림돌이 된다.
      단위 테스트는 서로 독립적이어야 하며 테스트를 어떤 순서로든 실행할 수 있어야 하는데,
      하나의 인스턴스를 기반으로 구현하는 싱글톤 패턴은 각 테스트마다 '독립적인' 인스턴스를 만들기가 어렵다.
    • 모듈 간의 결합을 강하게 만들 수 있다
      
      • 해결 방안 : 의존성 주입을 통해 모듈 간의 결합을 조금 더 느슨하게 만들 수 있다.
        중간에 의존성 주입자가 이 부분을 가로채 메인 모듈이 '간접'적으로 의존성을 주입한다면,
        메인 모듈은 하위 모듈에 대한 의존성이 떨어지게 된다. (디커플링)
        • 의존성 주입의 장점 :
          1. 모듈들을 쉽게 교체할 수 있는 구조가 되어 테스팅하기 쉽고 마이그레이션 하기도 수월하다.
          2. 애플리케이션 의존성 방향이 일관되고, 애플리케이션을 쉽게 추론할 수 있다.
          따라서 모듈 간의 관계들이 조금 더 명확해진다.
        • 의존성 주입의 단점 : 
          클래스 수가 늘어나 복잡성이 증가될 수 있으며 런타임 페널티가 생기기도 한다.

 

---

• 팩토리 패턴 (factory pattern)
  • 객체를 사용하는 코드에서 객체 생성 부분을 떼어내 추상화한 패턴
  • 상속 관계에 있는 두 클래스에서 상위 클래스가 중요한 뼈대를 결정하고,
    하위 클래스에서 객체 생성에 관한 구체적인 내용을 결정하는 패턴
  • 하위 클래스 - 라테 레시피, 아메리카노 레시피, 우유 레시피
    상위 클래스 - 바리스타 공장에서 하위 클래스 레시피들을 토대로 우유 등을 생상하는 생산 공정
  • 장점 :
    • 상위 클래스와 하위 클래스가 분리되기 때문에 느슨한 결합을 가진다.
    • 상위 클래스에서는 인스턴스 생성 방식에 대해 전혀 알 필요가 없기 때문에 더 많은 유연성을 가진다.
    • 객체 생성 로직이 따로 떼어져 있기 때문에 코드를 리팩터링 하더라도 한 곳만 고칠 수 있게 되니 유지 보수성이 증가된다.

 

---

• 전략 패턴 (strategy pattern)
  • 또는 정책 패턴 (policy pattern)이라고도 한다.
  • 객체의 행위를 '직접' 수정하지 않고 전략이라고 부르는 '캡슐화한 알고리즘'을 컨텍스트 안에서 바꿔주면서 상호 교체가 가능하게 만드는 패턴
  • 온라인에서 결제할 때 네이버페이, 카카오페이 등 다양한 방법으로 결제하는 것.
    결제 방식의 '전략'만 바꿔서 결제하는 것.
  • passport : 전략 패턴을 활용한 라이브러리
    • Node.js에서 인증 모듈을 구현할 때 쓰는 미들웨어 라이브러리.
    • LocalStrategy : 서비스 내의 회원가입된 아이디와 비밀번호를 기반으로 인증하는 전략
    • OAuth : 페이스북, 네이버 등 다른 서비스를 기반으로 인증하는 전략

 

---

• 옵저버 패턴 (observer pattern)
  • 주체가 어떤 객체의 상태 변화를 관찰하다가 상태 변화가 있을 때마다
    메서드 등을 통해 옵저버 목록에 있는 옵저버들에게 변화를 알려주는 패턴
    • 주체 : 상태 변화를 보고 있는 관찰자
      옵저버들 : 객체의 상태 변화에 따라 전달되는 메서드 등을 기반으로 '추가 변화 사항'이 생기는 객체들
  • 트위터가 옵저버 패턴을 활용하였다.
  • 옵저버 패턴은 주로 이벤트 기반 시스템에 사용하며 MVC 패턴에도 사용된다.
  • 자바스크립트에서의 옵저버 패턴은 프록시 객체를 통해 구현할 수 있다.
    • 프록시 객체 : 어떠한 대상의 기본적인 동작의 작업을 가로챌 수 있는 객체
      • 프록시 객체를 이용한 옵저버 패턴을 이용하여 구현한 예시 :
        Vue.js 3.0에서 ref나 reactive로 정의하면 해당값이 변경되었을 때 자동으로 DOM에 있는 값이 변경된다.

 

---

• 프록시 패턴과 프록시 서버 (proxy pattern and proxy server)
  • 프록시 패턴 :
    대상 객체에 접근하기 전, 그 접근에 대한 흐름을 가로채 대상 객체 앞단의 인터페이스 역할을 하는 패턴
    • 이를 통해 객체의 속성, 변환 등을 보완하며 보안, 데이터 검증, 캐싱, 로깅에 사용한다.
    • 프록시 서버에서의 캐싱 :
      캐시 안에 정보를 담아두고, 캐시 안에 있는 정보를 요구하는 요청에 대해 다시 저 멀리 있는 원격 서버에 요청하지 않고 캐시 안에 있는 데이터를 활용하는 것.
      • 장점 : 이를 통해 불필요하게 외부와 연결하지 않기 때문에 트래픽을 줄일 수 있다.
  • 프록시 서버 :
    서버와 클라이언트 사이에서 클라이언트가 자신을 통해 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해주는 컴퓨터 시스템이나 응용 프로그램
    • 프록시 서버로 쓰는 nginx, CloudFlare
      • CloudFlare :
        • CDN : 전 세계적으로 분산된 서버가 있고 이를 통해 어떠한 시스템의 콘텐츠 전달을 빠르게 할 수 있는 서비스.
        • DDOS 공격 방어 : 의심스러운 트래픽, 특히 사용자가 접속하는 것이 아닌 시스템을 통해 오는 트래픽을 자동으로 차단해서 DDOS 공격으로부터 보호한다.
        • HTTPS 구축 : 별도의 인증서 설치 없이 좀 더 손쉽게 HTTPS를 구축할 수 있다.
    • CORS와 프런트엔드의 프록시 서버
      프런트엔드 서버를 만들어서 백엔드 서버와 통신할 때 주로 CORS 에러를 마주치는데,
      이를 해결하기 위해 프런트엔드에서 프록시 서버를 만들기도 한다.
      
      • CORS : 서버가 웹 브라우저에서 리소스를 로드할 때 다른 오리진을 통해 로드하지 못하게 하는 HTTP 헤더 기반 메커니즘.
        • 오리진 : 프로토콜과 호스트 이름, 포트의 조합

 

---

• 이터레이터 패턴 (iterator pattern)
  • 이터레이터를 사용하여 컬렉션의 요소들에 접근하는 패턴
  • 순회할 수 있는 여러 가지 자료형의 구조와는 상관없이 이터레이터라는 하나의 인터페이스로 순회가 가능하다.

 

---

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

 

---

• MVC 패턴
  • 모델(Model), 뷰(View), 컨트롤러(Controller)로 이루어진 패턴
  • 애플리케이션의 구성 요소를 세 가지 역할로 구분하여 개발 프로세스에서 각각의 구성 요소에만 집중해서 개발할 수 있다.
  • MVC 패턴을 사용한 대표적인 라이브러리로는 리액트(React.js)가 있다.
    • '가상 DOM'을 통해 실제 DOM을 조작하는 것을 추상화해서 성능을 높였다.
    • 불변성이 있다.
      state는 setState를 통해서만 수정이 가능하고,
      props를 기반으로 해서 만들어지는 컴포넌트인 pureComponent가 있다.
    • 단방향 바인딩이 적용되어 있고
    • 자유도가 높다.
  • 장점 : 재사용성과 확장성이 용이하다.
  • 단점 : 애플리케이션이 복잡해질수록 모델과 뷰의 관계가 복잡해진다.
  • 모델(Model)
    • 애플리케이션의 데이터인 데이터베이스, 상수, 변수 등을 말한다.
  • 뷰(View)
    • inputbox, checkbox, textarea 등 사용자 인터페이스 요소를 나타낸다.
      즉, 모델을 기반으로 사용자가 볼 수 있는 화면.
  • 컨트롤러(Controller)
    • 하나 이상의 모델과 하나 이상의 뷰를 잇는 다리 역할을 하며 이벤트 등 메인 로직을 담당한다.
    • 모델과 뷰의 생명주기도 관리한다.

 

---

• 모델(Model), 뷰(View), 프레젠터(Persenter)로 이루어진 패턴
• MVC 패턴으로부터 파생되었다.
• 뷰와 프레젠터는 일대일 관계이기 때문에 MVC 패턴보다 더 강한 결합을 지녔다.

 

---

• MVVM 패턴
  • MVC 패턴의 C에 해당하는 컨트롤러가 뷰모델(View Model)로 바뀐 패턴
  • MVVM 패턴을 가진 대표적인 프레임워크는 뷰(Vue.js)가 있다. 
    • 뷰모델은 뷰를 더 추상화한 계층이며,
      MVVM패턴은 MVC패턴과는 다르게 커맨드와 데이터 바인딩을 가지는 것이 특징
    • 뷰와 뷰모델 사이의 양방향 데이터 바인딩을 지원
    • UI를 별도의 코드 수정 없이 재사용할 수 있다.
    • 단위 테스팅하기 쉽다

---

읽고 나서,,,

 

MVC, FLUX 패턴 정도만 어디선가 들어봤던 기억인데...
이렇게 다양한 종류의 디자인 패턴이 있는데... 왜 알아보려 하지 않았을까?
라이브러리, 프레임워크들을 제대로 모르는 상태에서 무지성 프로그래밍 한 것 같아 반성해 본다.

내가 사용하고 있는 React.js가 MVC 패턴이라는 것도 지금 처음 알아서 민망한 마음에 조금 더 알아보려고
구글링을 마구 하는데 뭔가 이상한 점을 발견했다.

많은 블로거들과 스택오버플로우에서 React는 MVC 패턴이 아니라고 말하고 있었다.

또한 React 공홈에서조차 React는 MVC framework가 아니라고 말하고 있다.

여러 글들을 살펴보며 정리해 보면,
1. 리액트는 MVC가 아니라 V를 렌더링 하는 라이브러리이다.
2. 리액트 자체는 MVC 패턴이 아니지만, 리액트로 MVC패턴 또는 Flux/Redux 등을 사용할 수 있다.
3. MVC와 Flux의 차이점은 데이터 흐름이다. (Flux는 단방향, MVC는 양방향)
4. 간단한 리액트 앱은 VVM 또는 VC 일 수 있다.
    약간의 복잡성을 추가하면 MVVM 또는 MVC라고 부를 수 있다.

내가 여기서 생각할 수 있는 것은
리액트는 결국 MVC 패턴은 아니지만, 어떻게 구현하느냐에 따라 MVC 패턴이 될 수도 있다고 생각하면 될 것 같다...
그리고 해당 책의 지은이 큰돌님이 틀린 부분을 정정하신 것도 발견할 수 있었다.
https://www.inflearn.com/questions/679754/react%EA%B0%80-mvc-%ED%8C%A8%ED%84%B4%EC%9D%98-%EC%98%88%EC%8B%9C%EC%9D%B8-%EC%9D%B4%EC%9C%A0%EA%B0%80-%EA%B6%81%EA%B8%88%ED%95%A9%EB%8B%88%EB%8B%A4

---

출처 : 면접을 위한 CS 전공지식 노트

참고 :  https://stackoverflow.com/questions/51506440/mvvm-architectural-pattern-for-a-reactjs-application

https://legacy.reactjs.org/blog/2013/06/05/why-react.html

https://velog.io/@sssssssssy/TIL-React%EC%97%90%EC%84%9C-MVC%ED%8C%A8%ED%84%B4%EA%B3%BC-FLUX%ED%8C%A8%ED%84%B4%EC%97%90-%EB%8C%80%ED%95%B4%EC%84%9C