디자인 패턴 + 추가

디자인 패턴

• 프로그램을 설계할 때 발생했던 문제점들을 객체 간의 상호 관계 등을 이용하여 해결할 수 있도록 하나의 규약 형태로 만들어 놓은 것
• 생성 패턴(Creational Pattern), 구조 패턴(Structural Pattern), 행동 패턴(Behavioral Pattern) 으로 구분
  

싱글톤 패턴 (Singleton Pattern)

• 하나의 클래스에 오직 하나의 인스턴스만 가지는 패턴

  • 데이터베이스 연결 모듈에 많이 사용
  • 다른 클래스 간의 데이터 공유가 쉽다.
  • 인스턴스를 생성할 때 드는 비용이 줄어듬
  • 도메인 관점에서 인스턴스가 한 개만 존재하는 것을 보증하고 싶은 경우 사용
    -> 객체가 프로그램 내부에서 단 1개만 생성됨 보장
  • 의존성이 높아짐
  • 멀티 스레드에서 이 객체를 공유하며 동시에 접근하는 경우에 발생하는 동시성 문제도 해결
    
    

• 단점

  • 미리 생성된 하나의 인스턴스를 기반으로 구현하기 때문에 단위 테스트 시 각 테스트마다 독립적인 인스턴스를 만들기 어려움
    -> TDD (테스트 주도 개발) 에서의 한계가 있음 (독립적 인스턴스 만들기 어려움)
  • 모듈 간의 결합을 강하게 만들 수 있다.
    -> 의존성 주입을 통해 결합을 느슨하게 만들 수 있음.
    -> 메인 모듈이 직접 하위 모듈에 의존성을 주기보다 의존성 주입자가 가로채 메인 모듈이 간접적으로 의존성을 주입 (디커플링이 된다.)
    -> 디커플링 : 메인 모듈이 하위 모듈에 대한 의존성이 떨어지는 것
    -> 다만 의존성 주입은 클래스 수가 늘어나 복잡성이 증가하며 약간의 런타임 패널티가 생길 수 있음

• 무슨 전략들도 있는 거 같은데... 솔직히 잘 모르겠으니 '출처' 에 있는 사이트를 참고하자

> **의존성 주입 원칙** 상위 모듈은 하위 모듈에서 어떤 것도 가져오지 않아야 하며, 둘 다 추상화에 의존해야하고, 추상화는 세부 사항에 의존하지 말아야 한다.

팩토리 패턴 (Factory Pattern)

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

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

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

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

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

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

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

• 사용 예시
  • 자바스크립트의 static, 자바의 Enum
  • 자바의 getInstance() 메소드
  • Wrapper class 안에 정의된 valueOf() 메소드

전략 패턴 (Strategy Pattern)

• 객체의 행위를 바꾸고 싶은 경우 직접 수정하지 않고 캡슐화한 알고리즘 (전략) 을 컨텍스트 안에서 바꿔주면서 상호 교체가 가능하게 만드는 패턴
  -> 즉, 알고리즘 변형이 빈번하게 일어나는 경우 사용함

  • Node.js에서는 passport라는 인증 모듈을 구현할 때 쓰는 미들웨어 라이브러리가 있음.

  • 서비스 내의 회원 가입된 아이디와 비밀번호를 기반으로 네이버, 페이스북 등 다른 서비스를 기반으로 인증하는 OAuth 전략 등을 지원

    
    
• 주의점
  • 알고리즘이 많아질수록 관리해야할 객체의 수가 늘어난다
  • 만일 어플리케이션 특성이 알고리즘이 많지 않고 자주 변경되지 않는다면, 새로운 클래스와 인터페이스를 만들어 프로그램을 복잡하게 만들 이유가 없다.
  • 개발자는 적절한 전략을 선택하기 위해 전략 간의 차이점을 파악하고 있어야 한다. (복잡도 ↑)

• 사용 예시
  • java.util.Comparator#compare()
  • javax.servlet.http.HttpServlet
  • javax.servlet.Filter#doFilter()
    -> 어떻게 사용된다는지 잘 모르겠는데 더 찾아봐야 할 듯

옵저버 패턴 (Observer Pattern)

• 주체가 어떤 객체의 상태 변화를 관찰하다가 상태 변화가 있을 때마다 메서드 등을 통해 옵저버 목록에 있는 옵저버들에게 변화를 알려주는 패턴
  - 어떤 사람 A가 B를 팔로워했으면 B가 새 게시글 올리면 A에게 B가 뭐 올림 이라고 말하는 거 같음

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

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

• 다른 디자인 패턴들과 다르게 일대다(one-to-many) 의존성을 가짐

• 주로 분산 이벤트 핸들링 시스템을 구현하는 데 사용

• Pub/Sub(발행/구독) 모델

• 서비스 : 트위터 등

• 주로 이벤트 기반 시스템에 사용 혹은 MVC 패턴에도 사용됨

  • 모델에서 변경이 생겨 update 메서드로 뷰에 알려주고 컨트롤러 등이 작동하는 것
  
  

• 흐름

  • 한개의 관찰 대상자(Subject)와 여러개의 관찰자(Observer A, B, C)로 일 대 다 관계로 구성
  • 관찰 대상 Subject의 상태가 바뀌면 변경사항을 옵저버 한태 통보 (notifyObserver)
  • 대상자로부터 통보를 받은 Observer는 값을 바꿀수도 있고, 삭제하는 등 적절히 대응 (update)
  • Observer들은 언제든 Subject의 그룹에서 추가/삭제 될 수 있음
  • Subject 그룹에 추가되면 Subject로부터 정보를 전달받게 될 것 이며, 그룹에서 삭제될 경우 더이상 Subject의 정보를 받을수 없게 됨
  
  

• 장점

  • Subject의 상태 변경을 주기적으로 조회하지 않고 자동으로 감지 가능
  • 런타임 시점에서에 발행자와 구독 알림 관계를 맺을 수 있다.
  • 상태를 변경하는 객체(Subject)와 변경을 감지하는 객체(Observer)의 관계를 느슨하게 유지

• 단점

  • 구독자는 알림 순서를 제어할수 없고, 무작위 순서로 알림을 받음
  • 다수의 옵저버 객체를 등록 이후 해지하지 않는다면 메모리 누수가 발생

상속과 구현의 차이

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

프록시 패턴

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

• 종류
  • 기본형 프록시 (Normal Proxy)
  • 가상 프록시 (Virtual Proxy)
  • 보호 프록시 (Protection Proxy)
  • 로깅 프록시 (Logging Proxy)
  • 원격 프록시 (Remote Proxy)
  • 캐싱 프록시 (Caching Proxy)
    -> 자세한 내용은 '출처' 참고...
    

이터레이터 패턴 (Iterator Pattern)

• 이터레이터를 사용하여 컬렉션의 요소들에 접근하는 디자인 패턴
  • 일련의 데이터 집합에 대하여 순차적인 접근(순회)을 지원
  • 순회할 수 있는 여러 가지 자료형의 구조와는 상관 없이 이터레이터라는 하나의 인터페이스로 순회 가능
    -> set이든 map이든 상관 없이 다른 자료 구조더라도 똑같은 이터레이터 프로토콜을 통해 순회 가능
    -> 컬렉션 객체 안에 들어있는 모든 원소들에 대한 접근 방식이 공통화 되어 있다면 어떤 종류의 컬렉션에서도 이터레이터만 뽑아내면 여러 전략으로 순회가 가능해 보다 다형적인 코드를 설계할 수 있게 됨
• 내부 구조를 노출하지 않고 순회 할 수 있음
• 집합체의 구현과 접근하는 처리 부분을 반복자 객체로 분리해 결합도를 줄일 수 있음

노출 모듈 패턴 (Revealing Module Pattern)

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

• 장점
  • 개발자에게 깔끔한 접근 방법을 제공
  • private 데이터 제공
  • 클로저를 통해 함수와 변수를 지역화
  • 명시적으로 public 메소드와 변수를 제공해 명시성을 높임
• 단점
  • private 메소드 접근할 방법이 없음
  • private 메소드에 대해 함수 확장하는데 어려움이 있음
  • private 메소드를 참조하는 public 메소드를 수정하기 어려움

=> 솔직히 무슨 패턴인지 아직 감이 안 잡힘. 약간 함수형 프로그래밍의 느낌이 나는데...

MVC 패턴 (Model, View, Controller Pattern)

• 모델, 뷰, 컨트롤러로 이루어진 디자인 패턴
  • 애플리케이션의 구성요소를 세 가지 역할로 구분하여 개발 프로세스에서 각각의 구성 요소에만 집중해서 개발할 수 있음
  • 재사용성과 확장성이 용이
  • 애플리케이션이 복잡해질수록 모델과 뷰의 관계가 복잡해짐
  • 모델 : 데이터 (데이터베이스, 상수, 변수 등)
    -> 사용자가 편집하길 원하는 모든 데이터를 가지고 있어야 함
    -> 뷰나 컨트롤러에 대해서 어떤 정보도 알지 말아야 함
    -> 변경이 일어나면, 변경 통지에 대한 처리방법을 구현해야만 함
  • 뷰 : 사용자 인터페이스 요소, 모델을 기반으로 사용자가 볼 수 있는 화면.
    -> 모델이 가지고 있는 정보를 따로 저장해서는 안됨
    -> 모델이나 컨트롤러와 같이 다른 구성요소들을 몰라야 됨
    -> 변경이 일어나면, 변경 통지에 대한 처리방법을 구현해야만 함
  • 컨트롤러 : 하나 이상의 모델과 하나 이상의 뷰를 잇는 다리 역할. 이벤트 등의 메인 로직 담당. 모델과 뷰의 생명주기 관리
    -> 모델이나 뷰에 대해서 알고 있어야 함
    -> 모델이나 뷰의 변경을 모니터링 해야 함
• 복잡한 대규모 프로그램의 경우 다수의 뷰와 모델이 컨트롤러를 통해 연결되기 때문에 컨트롤러가 불필요하게 커지는 현상이 발생
• Massive-View-Controller : 복잡한 화면을 구성하는 경우 컨트롤러가 불필요하게 커지는 현상
  => 따라서 다른 패턴들이 대안으로 만들어지게 됨 (MVP 등)
  
  
  
• 예시
  • React
    • 가상 DOM을 통해 실제 DOM을 조작하는 것을 추상화하여 성능을 높인 라이브러리
  • 구글의 AngularJS, php의 코드이그나이터
    
    

MVP 패턴 (Controller -> presenter)

• MVC에서 Controller가 Presenter로 교체된 패턴

  • 뷰와 프레젠터는 일대일 관계라 MVC 패턴보다 결합이 강함
  • MVC는 Model과 View가 서로 연결되어 있어 의존관계를 갖게 되는데 MVP는 Model과 View 분리되어 있고 오직 Presenter를 통해서 상태나 변화를 알려줄 수 있음

• presenter

  • Model과 View를 매개체라는 점에서 Controller와 유사하지만, View에 직접 연결되는 대신 인터페이스를 통해 상호작용한다는 차이가 있음

• 장점

  • MVC와는 다르게 코드가 깔끔해지고, Model과 View의 결합도를 낮추면, 새로운 기능 추가 및 변경을 할때 마다 관련된 부분만 코드를 수정하면 되기 때문에 확장성이 개선
  • UI, Data 각각 파트를 나누어서 해야할 일(역할)이 명확해지고, 쉽고 빠른 코딩이 가능

• 주의점

  • View와 Presenter의 의존관계가 강해지고 Controller 대신 Presenter가 복잡해짐

MVVM 패턴

• MVC 패턴에서 컨트롤러가 뷰모델 (View model) 로 바뀐 패턴

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

• ViewModel

  • View를 표현하기 위해 만들어진 View를 위한 Model
  • View와 ViewModel의 관계는 N:1 관계
  • View와는 Binding을 하여 연결후 View에게서 액션을 받고 또한 View를 업데이트
    -> textView에 보여줄 내용을 담당하는 함수 등, View에서 변화가 일어나는 ViewController의 역할을 담당

• 실행 과정

  1. View에 입력이 들어오면 ViewModel에게 명령

  2. ViewModel은 필요한 데이터를 Model에게 요청

  3. Model은 ViewModel에게 요청된 데이터를 응답

  4. ViewModel은 응답 받은 데이터를 가공해서 저장

  5. View는 ViewModel과의 Data Binding으로 인해 자동으로 갱신

• 장점

  • View와 Model이 서로 전혀 알지 못하기에 독립성을 유지
    -> 효율적인 유닛테스트가 가능
  • View와 ViewModel을 바인딩하기 때문에 코드 수 줄음

• 단점

  • 간단한 UI에서 오히려 ViewModel을 설계하는 어려움이 있을 수 있음
  • 데이터 바인딩이 필수적으로 요구
  • 복잡해질수록 Controller처럼 ViewModel이 빠르게 비대해짐
  • 표준화된 틀이 존재하지 않음

• 데이터 바인딩
  • Model과 UI 요소 간의 싱크를 맞춰주는 것
  • View와 로직이 분리되어 있어도 한 쪽이 바뀌면 다른 쪽도 업데이트가 이루어져 데이터의 일관성을 유지할 수 있음
    -> 솔직히 아직 잘 모르겠음...

면접 대비

Q: MVC 패턴을 설명하고 MVVM 패턴과의 차이를 설명해주세요
A: MVC 패턴은 모델, 뷰, 컨트롤러로 이루어진 디자인 패턴입니다. 앱의 구성 요소를 세 가지 역할로 분리하여 개발 프로세스에서 각각의 구성 요소에만 집중해서 개발할 수 있다는 점과 재사용성과 확장성이 용이하다는 장점이 있지만 애플리케이션이 복잡해질 수록 모델과 뷰의 관계 또한 복잡해집니다. 따라서 그러한 단점들을 극복하기 위해서 MVP나 MVVM과 같은 패턴들이 등장하였습니다. 그중에서 MVVM 패턴은 컨트롤러가 뷰모델로 바뀐 패턴으로, 뷰모델은 뷰를 더 추상화한 계층이며 커맨드와 데이터 바인딩을 가지는 것이 특징입니다. 뷰와 뷰모델 사이의 양방향 데이터 바인딩을 지원하며 UI를 별도의 코드 수정 없이 재사용 가능하며 단위 테스팅을 하기 쉽습니다.

출처

면접을 위한 CS 전공 지식 노트
디자인 패턴
싱글톤 패턴
전략 패턴
옵저버 패턴
프록시 패턴
반복자 패턴
노출모듈 패턴
MVC 패턴
MVP 패턴이란
MVP란
MVVM 패턴