디자인 패턴(2/3)

이 포스팅은 '면접을 위한 CS 전공지식 노트'를 읽고 제 나름대로 정리를 해본 것입니다. 사족도 붙여 가며 정리하였는데, 만약 문제가 된다면 포스팅 내리겠습니다.

4. 옵저버 패턴

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

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

• 이벤트 기반 시스템에 사용하며 MVC(Model-View-Controller) 패턴에도 사용됨 // TODO: 이벤트 기반 시스템 찾아보기

• JS에서 옵저버 패턴은 프록시 객체를 통해 구현할 수도 있음

  • 프록시 객체? 어떠한 대상의 기본적인 동작(속성 접근, 할당, 순회, 열거, 함수 호출 등)의 작업을 가로챌 수 있는 객체

    • target(프록시할 대상)과 handler(target 동작을 가로채고 어떠한 동작을 할 것인가 설정된 함수)를 매개변수로 받음

  • 프록시 객체를 이용한 옵저버 패턴

     function createReactiveObject(target, callback) {
     	const proxy = new Proxy(target, {
        	set(obj, prop, value) {
            	if(value !== obj[prop]) {
                	const prev = obj[prop]
                    obj[prop] = value
                    callback(`${prop}가 [${prev}] >> [${value}]로 변경되었습니다.`)
                }
                return true
            }
        })
        return proxy
     }
     
     const a = {
     	"June" : "Developer"
     }
     const b = createReactiveObject(a, console.log)
     b.June = "Developer"
     b.June = "Front Developer"
     // June가 [Developer] >> [Front Developer] 로 변경되었습니다.
     

  • Vue.js 3.0의 옵저버 패턴

    • ref나 reactive로 정의하면 해당 값이 변경되었을 때 자동으로 DOM에 있는 값이 변경됨 // TODO: 구체적인 동작 원리 찾아보면 재밌을 듯

5. 프록시 패턴과 프록시 서버

• 프록시 패턴
  • 대상 객체에 접근하기 전 그 접근에 대한 흐름을 가로채 대상 객체 앞단의 인터페이스 역할을 하는 디자인 패턴
  • 객체의 속성, 변환 등을 보완하며 보안, 데이터 검증, 캐싱, 로깅에 사용함
• 프록시 서버
  • 서버와 클라이언트 사이에서 클라이언트가 자신을 통해 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해주는 컴퓨터 시스템이나 응용 프로그램
  • nginx 등을 통해 할 수 있음. 이렇게 했을 때 실제 포트를 숨길 수 있고 정적 자원을 gzip 압축하거나 메인 서버 앞단에서의 로깅을 할 수도 있음. 버퍼 오버플로우 취약점을 예방할 수도 있음. CloudFlare를 사용할 수도 있다고 함.
  • 버퍼 오버플로우: 버퍼는 보통 데이터가 저장되는 메모리 공간으로, 메모리 공간을 벗어나는 경우를 뜻함. 사용되지 않아야 할 영역에 데이터가 덮어씌워져 주소, 값을 바꾸는 공격이 발생하기도 함.
  • CORS와 프런트엔드의 프록시 서버
    • CORS(Cross-Origin Resource Sharing)는 서버가 웹 브라우저에서 리소스를 로드할 때 다른 오리진을 통해 로드하지 못 하게 하는 HTTP 헤더 기반 메커니즘
    • 프론트 서버가 백엔드 서버와 통신할 때 CORS 에러가 발생하기도 하는데, 프론트에서 프록시 서버를 만들기도 함 => 정확히 이런 이유로 nuxt에서 proxy를 사용해본 적 있음. nuxt.config.js에서 설정만 해주면 되는 거라 간편했던 기억이 있음!
    • 참고: 127.0.0.1은 루프백 IP로 본인 PC 서버의 IP임. 기본이니 안 쪽팔리려면 알아두자 ^_^;;

6. 이터레이터 패턴

• 이터레이터를 사용하여 컬렉션의 요소들에 접근하는 디자인 패턴

• 이터레이터라는 하나의 인터페이스로 순회가 가능

  const mp = new Map()
  mp.set('a', 1)
  mp.set('b', 2)
  mp.set('c', 3)
  const st = new Set()
  st.add(1)
  st.add(2)
  st.add(3)
  for(let a of mp) console.log(a)
  for(let b of st) console.log(b)
  
  // 아래와 같은 결과가 나옴
  ['a', 1]
  ['b', 2]
  ['c', 3]
  1,
  2,
  3
  

=> 이것도 하나의 패턴이었구나... js에서 자연스럽게 사용하고 있어서 몰랐다.

7. 노출모듈 패턴

• 즉시 실행 함수를 통해 private, public 같은 접근 제어자를 만드는 패턴

• 해당 패턴을 기반으로 만든 JS 모듈 방식으로는 CJS(commonJS) 모듈 방식이 있음

• 참고

  • public
    • 클래스에 정의된 함수에 접근 가능하며 자식 클래스와 외부 클래스에서 접근 가능한 범위
  • protected
    • 클래스에 정의된 함수에서 접근 가능하며 자식 클래스에서 접근 가능하지만 외부 클래스에서 접근 불가능한 범위
  • private
    • 클래스에 정의된 함수에서 접근 가능하며 자식 클래스와 외부 클래스에서 접근 불가능한 범위
  • 즉시 실행 함수
    • 함수를 정의하자마자 바로 호출하는 함수. 초기화 코드, 라이브러리 내 전역 변수의 충돌 방지 등에 사용

  => 디자인 패턴을 공부하면서 느낀 건데, js에서는 나름대로 충실히 객체 지향을 하려고 노력하는 것 같다. 객체 지향의 대표 격인 java에 있는 기능을 구현하려고 노력한 흔적이 많이 보인다. 👀 (반박시 님의 말이 맞습니다...)