[CS 전공지식 #1] 챕터1-1. 디자인 패턴

 

 

 

 

 

 

 

목차

1. 디자인 패턴

1.1 싱글톤 패턴

1.2. 팩토리 패턴

1.3 전략 패턴

1.4 옵저버 패턴

1.5 프록시 패턴과 프록시 서버

1.6 이터레이터 패턴

1.7 노출모듈 패턴

1.8 MVC 패턴

1.9 MVP 패턴

1.10 MVVM 패턴

 

 

 

 

챕터1. 디자인 패턴과 프로그래밍 패러다임.

• 라이브러리 & 프레임워크: 공통으로 사용될 수 있는 특정한 기능들을 모듈화한 것
  • 라이브러리: 폴더명, 파일명 등에 대한 규칙 X, 프레임워크에 비해 자유로움
  • 프레임워크: 규칙 존재, 라이브러리에 비해 좀 더 엄격

 

1. 디자인 패턴

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

 

 

1.1 싱글톤 패턴

• 싱글톤 패턴 singleton pattern
  • 하나의 클래스에 오직 하나의 인스턴스만 가지는 패턴
  • 하나의 클래스를 기반으로 여러 개의 개별적인 인스턴스 생성 가능하지만, 그렇게 하지 않고 하나의 클래스를 기반으로 단 하나의 인스턴스 생성
  • 보통 데이터베이스 연결 모듈에 많이 사용
  • (장점) 인스턴스 생성 비용 감소 / (단점) 의존성이 높아짐
• 자바스크립트의 싱글톤 패턴
  • 리터럴 {} 또는 new Object로 객체 생성 → 어떤 객체와도 동일하지 않아서 자체로 싱글톤 패턴을 구현 가능
  • 하지만 보통은 Singleton.instance 라는 하나의 인스턴스를 가지는 Singleton 클래스 구현
• 데이터베이스 연결 모듈: 데이터베이스 연결에 관한 인스턴스 생성 비용 절약 가능
• 자바, mongoose, MySQL
• 싱글톤 패턴의 단점
  • TDD Test Driven Development를 할 때 걸림돌
    • TDD를 할 때 주로 단위 테스트 진행
    • 테스트가 서로 독립적 필요
      • 싱글톤 패턴은 미리 생성된 하나의 인스턴스를 기반으로 구현하는 패턴
      • → 각 테스트마다 “독립적인” 인스턴스 생성하기 어려움
  • 의존성 주입
    • 싱글톤 패턴: 사용하기 쉽고, 실용적, 모듈 간의 결합을 강하게 만들 수 있다는 단점
    • 의존성 주입 DI Dependency Injection 을 통해 모듈 간의 결합을 더 느슨하게 만들어 해결
    • 의존성
      • = 종속성
      • A가 B에 의존성이 있다는 것 = B의 변경 사항에 대해 A 또한 변해야 된다는 것
    • 메인 모듈이 직접 다른 하위 모듈에 대한 의존성을 주기보다는 중간에 의존성 주입자가 이 부분을 가로채 메인 모듈이 간접적으로 의존성을 주입하는 방식
    • = 디커플링
    • 장점:
      • 모듈들 쉽게 교체 가능 구조, 테스팅 및 마이그레이션 용이
      • 구현 시 추상화 레이어를 넣고 이를 기반으로 구현체를 넣어 주기 때문에 애플리케이션 의존성 방향 일관, 애플리케이션 쉽게 추론 가능, 모듈 간의 관계들이 좀 더 명확
    • 단점:
      • 모듈이 더 분리, 클래스 수가 증가, 복잡성 증가, 약간의 런타임 패널티
    • 의존성 주입 원칙:
      • 상위 모듈은 하위 모듈에서 어떠한 것도 가져오지 않아야 함
      • 둘 다 추상화에 의존, 추상화는 세부 사항에 의존 x

 

 

 

1.2. 팩토리 패턴

• 팩토리 패턴 factory pattern
  • 객체를 사용하는 코드에서 객체 생성 부분을 떼어내 추상화한 패턴
  • 상속 관게에 있는 두 클래스에서 상위 클래스가 중요한 뼈대를 결정, 하위 클래스에서 객체 생성에 관한 구체적인 내용을 결정하는 패턴
  • 상위 클래스와 하위 클래스가 분리 → 느슨한 결합, 상위 클래스에서는 인스턴스 생성 방식 알 필요 X → 더 많은 유연성
  • 객체 생성 로직이 따로 떼어져 있어서 → 코드 리팩터링 시 한 곳만 고치기 가능 → 유지 보수성 증가

 

 

 

1.3 전략 패턴

• 전략 패턴 strategy pattern
  • = 정책 패턴
  • 객체의 행위를 바꾸고 싶은 경우 직접 수정하지 않고 전략이라고 부르는 캡슐화한 알고리즘을 컨텍스트 안에서 바꿔주면서 상호 교체가 가능하게 만드는 패턴
    • 컨텍스트: 상황, 맥락, 문맥을 의미, 개발자가 어떠한 작업을 완료하는 데 필요한 모든 관련 정보
  • 예시) 결제 시스템에서 카카오 카드로 결제하고 일반 카드 결제 등
• passport의 전략 패턴
  • 전략 패턴을 활용한 라이브러리
  • Node.js에서 인증 모듈을 구현할 때 쓰는 미들웨어 라이브러리
  • 여러가지 “전략’ 기반 인증 가능하게 함

 

 

 

1.4 옵저버 패턴

• 옵저버 패턴 observer pattern
  • 주체가 어떤 객체 subject의 상태 변화를 관찰하다가 상태 변화가 있을 때마다 메서드 등을 통해 옵저버 목록에 있는 옵저버들에게 변화를 알려주는 디자인 패턴
    • 주체: 객체의 상태 변화를 보고 있는 관찰자
    • 옵저버: 객체의 상태 변화에 따라 전달되는 메서드 등을 기반으로 “추가 변화 사항”이 생기는 객체들을 의미
    • 주체와 객체를 따로 두지 않고 상태가 변경되는 객체를 기반으로 구축하기도 함
  • 옵저버 패턴을 활용한 서비스 중 하나가 트위터

• 옵저버 패턴은 주로 이벤트 기반 시스템에 사용, MVC Model-View-Controller 패턴에도 사용됨
  • 주체인 모델 model에서 변경 사항이 생겨 update() 메서드로 옵저버인 뷰에 알려주고
  • 이를 기반으로 컨트롤러 Controller 등이 작동

• 자바에서의 옵저버 패턴
  • 상속 extends:
    • 자식 클래스가 부모 클래스의 메서드 등을 상속받아 사용
    • 자식 클래스에서 추가 및 확장 가능
    • 재사용성, 중복성의 최소화 가능
  • 구현 implements:
    • 부모 인터페이스를 자식 클래스에서 재정의하여 구현하는 것
    • 상속과는 달리 반드시 부모 클래스의 메서드를 재정의하여 구현해야 함
  • 상속과 구현 차이
    • 상속은 일반 클래스, abstract 클래스를 기반으로 구현
    • 구현은 인터페이스를 기반으로 구현
• 자바스크립트에서의 옵저버 패턴
  • 프록시 객체를 통해 구현 가능
  • 프록시 객체: 어떠한 대상의 기본적인 동작(속성 접근, 할당, 순서, 열거, 함수 호출 등)의 작업을 가로챌 수 있는 객체
    • 프록시 객체는 두 개의 매개변수를 가짐
    • target, handler

 

 

 

1.5 프록시 패턴과 프록시 서버

• 프록시 패턴 proxy pattern
  • 대상 객체 subject에 접근하기 전 그 접근에 대한 흐름을 가로채 대상 객체 앞단의 인터페이스 역할을 하는 디자인 패턴
  • 객체의 속성, 변환 등을 보완, 보안, 데이터 검증, 캐싱, 로깅에 사용
  • 프록시 서버로도 활용됨
• 프록시 서버 proxy server
  • 서버와 클라이언트 사이에서 클라이언트가 자신을 통해 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해주는 컴퓨터 시스템이나 응용 프로그램
  • nginx:
    • 비동기 이벤트 기반의 구조와 다수의 연결을 효과적으로 처리 가능한 웹 서버
    • Node.js 서버 앞단의 프록시 서버로 활용됨
    • 익명 사용자가 직접적으로 서버에 접근하는 것을 차단, 간접적으로 한 단계를 더 거치게 만들어서 보안 강화]
    • nginx를 프록시 서버로 둬서, 실제 포트를 숨기고 정적 자원을 gzip으로 압축하거나, 메인 서버 앞단에서의 로깅 가능

• 프록시 서버 CloudFlare
  • 전 세계적으로 분산된 서버, 어떠한 시스템의 콘텐츠 전달을 바르게 할 수 있는 CDN 서비스
  • 웹 서버 앞 단에 프록시 서버로 두어 DDOS 공격 방어나 HTTPS 구축에 사용됨
  • 의심스러운 해외 트래픽 다수 발생 → 클라우드 서비스 비용 발생
    • 이 때 CloudFlare가 의심스러운 트래픽인지 먼저 판단
    • CAPTCHA 등을 기반으로 일정 부분 막아주는 역할 수행
  • DDOS 공격 방어
    • DDOS: 짧은 기간 동안 네트워크에 많은 요청을 보내 네트워크 마비시켜 웹 사이트의 가용성을 방해하는 사이버 공격 유형
    • CloudFlare는 의심스러운 트래픽 (시스템을 통해 오는 트래픽)을 자동으로 차단, DDOS 공격으로부터 보호
  • HTTPS 구축
    • 서버에서 HTTPS 구축 시 인증서를 기반으로 구축 가능한데
    • CloudFlare을 사용하면 별도 인증서 설치 없이 더 쉽게 HTTPS 구축 가능

• CORS와 프론트엔드의 프록시 서버
  • CORS Cross-Origin Resource Sharing: 서버가 웹 브라우저에서 리소스를 로드할 때 다른 오리진을 통해 로드하지 못하게 하는 HTTP 헤더 메커니즘
  • 프론트엔드 서버 앞단에 프록시 서버를 놓아 CORS 에러 해결

 

 

 

1.6 이터레이터 패턴

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

 

 

 

1.7 노출모듈 패턴

• 즉시 실행 함수를 통해 private, public 같은 접근 제어자를 만드는 패턴
• 자바스크립트는 private, public 같은 접근 제어자가 존재하지 않고 전역 범위에서 스크립트 실행 → 노출모듈 패턴을 통해 private, public 같은 접근 제어자를 구현하기도 함

 

 

 

1.8 MVC 패턴

• 모델 Model, 뷰 View, 컨트롤러 Controller로 이루어진 디자인 패턴
• 애플리케이션의 구성 요소를 세 가지 역할로 구분하여 개발 프로세스에서 각각의 구성 요소에만 집중해서 개발 가능
• (장점) 재사용성과 확장성이 용이
• (단점) 애플리케이션이 복잡해질수록 모델과 뷰의 관게가 복잡해짐

• 모델
  • 애플리케이션의 데이터인 데이터베이스, 상수, 변수 등을 뜻함
  • 뷰에서 데이터를 생성하거나 수정하면 컨트롤러를 통해 모델을 생성하거나 갱신함
• 뷰
  • inputbox, checkbox, textarea 등 사용자 인터페이스 요소를 나타냄
  • 모델을 기반으로 사용자가 볼 수 있는 화면
  • 모델이 가지고 있는 정보를 따로 저장하지 않아야 하며 단순히 사각형 모양 등 화면에 표시하는 정보만 가지고 있어야 함
  • 변경이 일어나면 컨트롤러에 이를 전달해야 함
• 컨트롤러
  • 하나 이상의 모델과 하나 이상의 뷰를 잇는 다리 역할
  • 이벤트 등 메인 로직을 담당
  • 모델과 뷰의 생명 주기 관리
  • 모델이나 뷰의 변경 통지를 받으면 이를 해석하여 각각의 구성 요소에 해당 내용에 대해 알려줌
• MVC 패턴의 예시: 스프링 Spring
  • 자바 플랫폼을 위한 오픈소스 애플리케이션
  • Spring 의 WEB MVC: MVC 패턴을 기반으로 다양한 기능을 제공하는 웹 프레임워크

 

 

 

1.9 MVP 패턴

• MVC의 파생
• 컨트롤러 C 대신 프레젠터 Presenter로 교체된 패턴
• 뷰와 프리젝터는 일대일 관계, MVC 패턴보다 더 강한 결합을 지닌 디자인 패턴

 

 

 

1.10 MVVM 패턴

• MVC의 C 대신 뷰모델 View Model 로 바뀐 패턴
  • 뷰 모델은 뷰를 더 추상화한 계층
  • MVVM 패턴은 MVC 패턴과 다르게 커맨드와 데이터 바인딩을 가지는 것이 특징
  • UI 별도의 코드 수정 없이 재사용 가능, 단위 테스팅 하기 쉽다는 장점

• MVVM 패턴 의 예시: 뷰 Vue.js
  • 반응형이 특징인 프런트엔드 프레임워크
  • 함수를 사용하지 않고 값 대입만으로도 변수 변경됨
  • 양방향 바인딩, html 토대로 컴포넌트 구축 가능
  • 재사용 가능한 컴포넌트 기반으로 UI 구축 가능