디자인 패턴과 프로그래밍 패러다임 - 1

디자인 패턴

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

싱글톤 패턴 (Singleton Pattern)

• 하나의 클래스에 오직 하나의 인스턴스만 가지는 패턴
  • 데이터베이스 연결 모듈에 많이 사용
  • 다른 클래스 간의 데이터 공유가 쉽다.
  • 인스턴스를 생성할 때 드는 비용이 줄어듬
  • 도메인 관점에서 인스턴스가 한 개만 존재하는 것을 보증하고 싶은 경우 사용
  • 의존성이 높아짐
• 단점
  • 미리 생성된 하나의 인스턴스를 기반으로 구현하기 때문에 단위 테스트 시 각 테스트마다 독립적인 인스턴스를 만들기 어려움
  • 모듈 간의 결합을 강하게 만들 수 있다.
    -> 의존성 주입을 통해 결합을 느슨하게 만들 수 있음. 메인 모듈이 직접 하위 모듈에 의존성을 주기보다 의존성 주입자가 가로채 메인 모듈이 간접적으로 의존성을 주입 (디커플링이 된다.)
    -> 다만 의존성 주입은 클래스 수가 늘어나 복잡성이 증가하며 약간의 런타임 패널티가 생길 수 있음
    
    
    의존성 주입 원칙
    상위 모듈은 하위 모듈에서 어떤 것도 가져오지 않아야 하며, 둘 다 추상화에 의존해야하고, 추상화는 세부 사항에 의존하지 말아야 한다.
    
    

팩토리 패턴 (Factory Pattern)

• 객체를 사용하는 코드에서 객체 생성 부분을 떼어내 추상화한 패턴

• 상속 관계에 있는 두 클래스에서 상위 클래스가 중요한 뼈대를 결정하고 하위 클래스에서 객체 생성에 관한 구체적인 내용을 결정하는 패턴

• 상위 클래스와 하위 클래스가 분리되어서 느슨한 결합을 가짐

• 상위 클래스에서는 인스턴스 생성 방식에 대해 알 필요가 없어서 더 많은 유연성을 가짐

• 객체 생성 로직이 따로 뗴어져 있어서 코드를 리팩토링 하더라도 유지 보수성이 유지됨
  => 인터페이스를 하나 두고 그 부분을 가지고 하나의 큰 공장을 만들어서 공통된 부분을 사용하는 것으로 보임
  => 어떤 클래스가 자신이 생성해야 하는 객체의 클래스를 예측할 수 없을 때 혹은 생성할 객체를 기술하는 책임을 자신의 서브클래스가 지정했으면 할 때 사용한다고 함

• 심플 팩토리 패턴, 팩토리 메서드 패턴, 추상 팩토리 패턴 등이 있다.

• 서로 간의 종속성을 낮추고, 결합도를 느슨하게 하며(Loosely Coupled), 확장을 쉽게 함

전략 패턴 (Strategy Pattern)

• 객체의 행위를 바꾸고 싶은 경우 직접 수정하지 않고 캡슐화한 알고리즘 (전략) 을 컨텍스트 안에서 바꿔주면서 상호 교체가 가능하게 만드는 패턴
  • Node.js에서는 passport라는 인증 모듈을 구현할 때 쓰는 미들웨어 라이브러리가 있음.
  • 서비스 내의 회우너 가입된 아이디와 비밀번호를 기반으로 네이버, 페이스북 등 다른 서비스를 기반으로 인증하는 OAuth 전략 등을 지원

옵저버 패턴 (Observer Pattern)

• 주체가 어떤 객체의 상태 변화를 관찰하다가 상태 변화가 있을 때마다 메서드 등을 통해 옵저버 목록에 있는 옵저버들에게 변화를 알려주는 패턴
  - 어떤 사람 A가 B를 팔로워했으면 B가 새 게시글 올리면 A에게 B가 뭐 올림 이라고 말하는 거 같음
  • 주체 : 객체의 상태 변화를 보고 있는 관찰자
  • 옵저버 : 객체의 상태 변화에 따라 전달되는 메서드 등을 기반으로 추가 변화 사항이 생기는 객체들
• 주체와 객체를 따로 두지 않고 상태가 변경되는 객체를 기반으로 구축하기도 함
• 서비스 : 트위터 등
• 주로 이벤트 기반 시스템에 사용 혹은 MVC 패턴에도 사용됨
  • 모델에서 변경이 생겨 update 메서드로 뷰에 알려주고 컨트롤러 등이 작동하는 것

상속과 구현의 차이

• 상속 : 자식 클래스가 부모 클래스의 메서드 등을 상속받아 사용하며 자식 클래스에서 추가 및 확장을 할 수 있는 것
  • 재사용성, 중복성의 최소화
  • 일반 클래스 혹은 추상 클래스를 기반으로 구현
• 구현 : 부모 인터페이스를 자식 클래스에서 재정의하여 구현하는 것
  • 반드시 부모 클래스의 메서드를 재정의하여 구현해야함
  • 인터페이스를 기반으로 구현

프록시 패턴

• 대상 객체에 접근하기 전 그 접근에 대한 흐름을 가로채 대상 객체 앞단의 인터페이스 역할을 하는 디자인 패턴
  • 객체의 속성, 변환 등을 보완
  • 보안, 데이터 검증, 캐싱, 로깅 등에 사용
• 프록시 서버
  • 서버와 클라이언트 사이에서 클라이언트가 자신을 통해 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해주는 컴퓨터 시스템이나 응용 프로그램
  • nginx
    • 비동기 이벤트 기반의 구조와 다수의 연결을 효과적으로 처리 가능한 웹 서버
    • 주로 Node.js 서버 앞단의 프록시 서버로 활용
      * 익명의 사용자의 직접적인 서버로의 접근을 차단하고 간접적으로 한 단계를 더 거침으로써 보안성을 강화
  • cloudflare
    • 전 세계적으로 분산된 서버를 통해 어떠한 시스템의 콘텐츠를 빠르게 전달해주는 CDN 서비스
    • DDOS 공격 방어 (짧은 시간 동안 네트워크에 많은 요청을 보내 네트워크를 마비시키는 공격)
    • 의심스러운 트래픽, 특히 사용자 접속이 아닌 시스템을 통해 들어오는 트래픽을 자동 차단하여 DDOS 공격으로부터 보호
      • 거대한 네트워크 용령과 캐싱 전략, 방화벽 대시보드 제공
    • HTTPS 구축
      • 서버에서 HTTPS를 구축할 때 인증서를 기반으로 구축할 수 있으나, CloudFlare를 사용하면 인증서 절차 없이 구축 가능
  • CORS와 프론트엔드의 프록시 서버
    • CORS란 서버가 웹 브라우저에서 리소스를 로드 할 때 다른 오리진을 통해 로드하지 못하게 하는 HTTP 헤더 기반 매커니즘
      -> 다른 사이트에서 현재 사이트를 흉내내지 못하도록 하여 보호

이터레이터 패턴 (Iterator Pattern)

• 이터레이터를 사용하여 컬렉션의 요소들에 접근하는 디자인 패턴
  • 순회할 수 있는 여러 가지 자료형의 구조와는 상관 없이 이터레이터라는 하나의 인터페이스로 순회 가능
    -> set이든 map이든 상관 없이 다른 자료 구조더라도 똑같은 이터레이터 프로토콜을 통해 순회 가능

노출 모듈 패턴 (Revealing Module Pattern)

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

MVC 패턴 (Model, View, Controller Pattern)

• 모델, 뷰, 컨트롤러로 이루어진 디자인 패턴
  • 애플리케이션의 구성요소를 세 가지 역할로 구분하여 개발 프로세스에서 각각의 구성 요소에만 집중해서 개발할 수 있음
  • 재사용성과 확장성이 용이
  • 애플리케이션이 복잡해질수록 모델과 뷰의 관계가 복잡해짐
  • 모델 : 데이터 (데이터베이스, 상수, 변수 등)
  • 뷰 : 사용자 인터페이스 요소, 모델을 기반으로 사용자가 볼 수 있는 화면. 따로 정보를 저장하지 않아야한다.
  • 컨트롤러 : 하나 이상의 모델과 하나 이상의 뷰를 잇는 다리 역할. 이벤트 등의 메인 로직 담당. 모델과 뷰의 생명주기 관리
  • React
    • 가상 DOM을 통해 실제 DOM을 조작하는 것을 추상화하여 성능을 높인 라이브러리

MVP 패턴 (model -> presenter)

• MVC에서 View가 Presenter로 교체된 패턴
  • 뷰와 프레젠터는 일대일 관계라 MVC 패턴보다 결합이 강함

MVVM 패턴

• MVC 패턴에서 컨트롤러가 뷰모델 (View model) 로 바뀐 패턴
  • 뷰모델이란 뷰를 더 추상화한 계층이며 MVC 패턴과는 다르게 커맨드와 데이터 바인딩을 가지는 것이 특징
  • 부와 뷰모델 사이의 양방향 데이터 바인딩을 지우너
  • UI를 별도의 코드 수정없이 재사용 가능
  • 단위 테스팅이 쉬움
  • Vue.js
    • 반응형이 특징인 프론트엔드 프레임워크

출처

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