[CS 전공지식 노트] 디자인 패턴

 

'면접을 위한 CS 전공지식 노트'를 읽고 개인적으로 정리한 글입니다.

 

 

 

1.1 다자인 패턴

 

들어가기에 앞서, 라이브러리와 프레임워크의 차이점을 알아보자
(결국 정의는 같음)

라이브러리 : 공통으로 사용될 수 있는 특정한 기능들을 모듈화한 것을 의미함

=> 폴더명, 파일명 등에 대한 규칙이 없고 프레임워크에 비해 자유로움

프레임워크 : 공통으로 사용될 수 있는 특정한 기능들을 모듈화한 것을 의미함

=> 폴더명, 파일명 등에 대한 규칙이 있으며 라이브러리에 비해 좀 더 엄격함

 

 

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

 

1.1.1 싱글톤 패턴

 

싱글톤 패턴(singleton pattern)은 하나의 클래스에 오직 하나의 인스턴스만 가지는 패턴임

 

=> 데이터베이스 연결 모듈에 많이 사용함

 

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

 

TDD에서의 단점

 

TDD(Test Driven Development)를 할 때 단위 테스트를 주로 하는데, 단위 테스트는 테스트가 독립적이여야 하며 테스트를 어떤 순서로든 실행할 수 있어야 하기에 싱글톤 패턴은 걸림돌이 됨

 

=> 미리 생성된 하나의 인스턴스를 기반으로 구현하는 패턴이므로 각 테스트마다 '독립적인' 인스턴스를 만들기가 어려움

 

의존성 주입을 통한 해결

 

싱글톤 패턴은 사용하기가 쉽고 굉장히 실용적이지만 모듈 간의 결합을 강하게 만들 수 있다는 단점이 있음

 

=> DI(Dependency Injection)을 통해 모듈간의 결합을 조금 더 느슨하게 만들어 해결할 수 잇음

 

DI에 대해 조금 더 깊게 들어가보자면

 

메인 모듈이 직접 다른 하위 모듈에 대한 의존성을 주기보다는 중간에 의존성 주입자(dependency Injector)가 이 부분을 가로채 메인 모듈이 간접적으로 의존성을 주입하는 방식임

 

• 이를 통해 모듈들을 쉽게 교체할 수 있는 구조가 되어 테스팅하기 쉽고 마이그레이션하기도 수월함
  
  => 구현할 때 추상화 레이어를 넣고 이를 기반으로 구현체를 넣어 주기 때문에 애플리케이션 의존성 방향이 일관되고 쉽게 추론할 수 있으며 모듈 간의 관계들이 조금 더 명확해짐
  
  
• 하지만, 모듈들이 더욱더 분리되므로 클래스 수가 늘어나 복잡성이 증가될 수 있으며 약간의 런타임 패널티가 생기기도함

 

의존성 주입의 원칙은 상위 모듈은 하위 모듈에서 어떠한 것도 가져오지 않아야 하는 것임

=> 둘다 추상화에 의존해야 하며, 이 때 추상화는 세부 사항에 의존하지 않아야함!

 

1.1.2 팩토리 패턴

 

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

 

• 상위, 하위 클래스가 분리되어 느슨한 결합
  
  
• 상위 클래스에서 인스턴스 생성 방식에 대해 알 필요가 없기에 더 많은 유연성
  
  
• 객체 생성 로직이 떼어져 있기에 코드 리팩토링시에 한 곳만 고칠 수 있어 유지보수성 증가

😋 추가 내용

JAVA에서 많이 사용하는 enum은 유일한 인스턴스를 보장해주고 불변성을 갖기에 여러 thread가 동시에 읽어도 안전하게(동기화 할 필요 X)되어 있음

=> thread safe하기 때문에 싱글톤 패턴을 만들 때 도움이됨!

 

1.1.3 전략 패턴

 

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

 

프로그래밍에서의 컨텍스트는 상황, 맥락, 문맥을 의미하며 개발자가 어떠한 작업을 완료하는 데 필요한 모든 관련 정보를 말하는거임!

 

 

예를 들면 Node.js에서 인증 모듈을 구현할 때 쓰는 passport 미들웨어 라이브러리는 여러 가지 전략을 기반으로 인증할 수 있게 해줌

 

=> 서비스 내 회원가입된 ID/PW를 기반으로 인증하는 LocalStrategy 전략과 네이버, 카카오 등 다른 서비스를 기반으로 인증하는 OAuth 전략 등을 지원

 

1.1.4 옵저버 패턴

 

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

 

크게 2가지로 나눠 생각해볼 수 있는데

 

1. 객체와 주체가 분리되어 있는 옵저버 패턴

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

 

2. 객체와 주체가 합쳐진 옵저버 패턴

주제와 객체를 따로 두지 않고 상태가 변경되는 객체를 기반으로 구축하기도함

 

---

 

이런 옵저버 패턴은 주로 이벤트 기반 시스템에 사용하며 MVC(Model-View-Controller) 패턴에도 사용됨

=> 주체라고 볼 수 있는 모델(model)에서 변경 사항이 생겨 update() 메서드로 옵저버인 View에 알려주고 이를 기반으로 Controller 등이 작동

 

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

 

프록시 패턴(proxy pattern)은 대상 객체(subject)에 접근하기 전 그 접근에 대한 흐름을 가로채 해당 접근을 필터링하거나 수정하는 등의 역할을 하는 계층이 있는 디자인 패턴임

 

=> 객체의 속성, 변환 등을 보완하며 보안, 데이터 검증, 캐싱, 로깅에 사용함

프록시 객체로도 쓰이고, 프록시 서버로도 활용됨

 

프록시 서버는 서버와 클라이언트 사이에서 클라이언트가 자신을 통해 네트워크 서비스에 간접적으로 접속할 수 있게 해주는 컴퓨터 시스템이나 응용 프로그램을 가리킴

 

=> 대표적으로 nginx를 생각해보면됨

 

(nginx를 프록시 서버로 둬서 실제 포트를 숨길 수 있고 정적 자원을 gzip 압축하거나, 메인 서버 앞단에서의 로깅을 할 수 도 있음)

 

CloudFlare

CloudFlare는 전 세계적으로 분산된 서버가 있고 이를 통해 어떠한 시스템의 콘텐츠 전달을 빠르게 할 수 있는 CDN 서비스임

=> CloudFlare는 웹 서버 앞단에서 프록시 서버로 두어 DDOS 공격 방어나 HTTPS 구축에 쓰임

DDOS 공격 방어

DDOS는 짧은 기간 동안 네트워크에 많은 요청을 보내 네트워크를 마비시켜 웹 사이트의 가용성을 방해하는 사이버 공격 유형임

 

=> CloudFlare는 의심스러운 트래픽, 특히 사용자가 접속하는 것이 아닌 시스템을 통해 오는 트래픽을 자동으로 차단해서 DDOS 공격으로부터 보호함

 

HTTPS 구축

 

서버에서 HTTPS를 구축할 때 인증서를 기반으로 구축할 수도 있음

=> CloudFlare를 사용하면 별도의 인증서 설치 없이 좀 더 손쉽게 HTTPS 구축 가능

 

CORS와 프런트엔드의 프록시 서버

 

CORS(Cross-Origin-Resource Sharing)는 서버가 웹 브라우저에서 리소스를 로드할 때 다른 Origin을 통해 로드하지 못하게 하는 HTTP 헤더 기반 메커니즘임

 

=> 이를 해결하기 위해 프런트엔드에서 프록시 서버를 만들기도함

 

Origin이란 프로토콜과 호스트 이름, 포트의 조합을 말함

=> https://jghan.com:12010/test 라는 주소에서 Origin은 https://jghan.com:12010 임!

 

1.1.6 이터레이터 패턴

 

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

 

=> 순회할 수 있는 여러 자료형의 구조와는 상관없이 이터레이터라는 하나의 인터페이스로 순회가 가능

(JS를 예로들어 서로 다른 자료 구조인 set, map 임에도 같은 for a of b 라는 이터레이터 프로토콜을 통해 순회하는 것을 확인할 수 있음)

 

이터레이터 프로토콜 : 이터러블한 객체들을 순회할 때 쓰이는 규칙

이터러블한 객체 : 반복 가능한 객체로 배열을 일반화한 객체 

 

1.1.7 노출모듈 패턴

 

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

 

=> JS는 private, public 같은 접근 제어자가 존재하지 않고 전역 범위에서 스크립트가 실행되므로 노출모듈 패턴을 통해 접근 제어자를 구현하기도함

 

즉시 실행 함수는 함수를 정의하자마자 바로 호출하는 함수로 초기화 코드, 라이브러리 내 전역 변수들의 충돌 방지 등에 사용됨

 

1.1.8 MVC 패턴

 

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

 

=> 애플리케이션의 구성 요소를 세 가지 역할로 구분하여 개발 프로세스에서 각각의 구성 요소에만 집중해서 개발할 수 있음

 

(재사용성과 확장성이 용이하다는 장점이 있고, 애플리케이션이 복잡해질수록 모델과 뷰의 관계가 복잡해진다는 단점이 있음)

 

모델

모델(model)은 애플리케이션의 데이터인 데이터베이스, 상수, 변수 등을 뜻함

 

=> 뷰에서 데이터를 생성하거나 수정하면 컨트롤러를 통해 모델을 생성하거나 갱신함

 

뷰

뷰(view)는 inputbox, checkbox, textarea 등 사용자 인터페이스 요소를 나타냄

 

=> 모델을 기반으로 사용자가 볼 수 있는 화면을 듯함

 

(모델이 가지고 있는 정보를 따로 저장하지 않아야함 또한, 변경이 일어나면 컨트롤러에 이를 전달해야함)

 

컨트롤러

컨트롤러(controller)는 하나 이상의 모델과 하나 이상의 뷰를 잇는 다리 역할을 하며 이벤트 등 메인 로직을 담당함

 

=> 모델과 뷰의 생명주기도 관리하며, 모델이나 뷰의 변경 통지를 받으면 이를 해석하여 각각의 구성 요소에 해당 내용에 대해 알려줌

 

MVC 패턴의 대표적인 예시로 Spring이 있는데 Spring의 WEB MVC는 웹 서비스를 구축하는 데 편리한 기능들을 많이 제공함

=> @RequestParam, @RequestHeader, @PathVariable 등 여러 에너테이션을 기반으로 사용자의 요청 값들을 쉽게 분석할 수 있으며 사용자의 어떠한 요청이 유효한 요청인지를 쉽게 거를 수 있음 

(이외에도 재사용 가능한 코드, 테스트, 쉽게 리디렉션할 수 있게 하는 등의 장점이 있음)

 

1.1.9 MVP 패턴

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

 

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

 

1.1.10 MVVM 패턴

 

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

 

=> 여기서 뷰모델은 뷰를 더 추상화한 계층이며, MVVM 패턴은 MVC 패턴과는 다르게 커맨드와 데이터 바인딩을 가지는 것이 특징

 

커맨드 : 여러 가지 요소에 대한 처리를 하나의 액션으로 처리할 수 있게 하는 기법 

데이터 바인딩 : 화면에 보이는 데이터와 웹 브라우저의 메모리 데이터를 일치시키는 기법으로, 뷰모델을 변경하면 뷰가 변경됨

 

뷰와 뷰모델 사이의 양방향 데이터 바인딩을 지원하며 UI를 별도의 코드 수정 없이 재사용할 수 있고 단위 테스팅하기 쉽다는 장점이 있음