1.1 디자인 패턴

'면접을 위한 CS 전공지식 노트' 책을 보며 공부한 내용입니다.

 

• 싱글톤 패턴
  
  • 하나의 클래스에 오직 하나의 인스턴스만 가진다.
  • 보통 DB 연결 모듈에 많이 사용한다.
  • 장점
    • 생산 비용 감소
  • 단점
    • 의존성 증가
    • TDD(Test Driven Development)를 할 때 방해된다. : TDD를 할 때는 단위 테스트를 주로 하는데, 단위 테스트는 각각이 독립적이어야 하며, 테스트를 독립적으로 실행할 수 있어야 한다. 하지만, 싱글톤은 미리 생성해둔 하나의 인스턴스로 구현하는 것이라서, 각 테스트마다 독립적이기 힘들다.
      • 의존성 주입으로 모듈 간의 결합을 조금 더 느슨하게 만들 수 있다.
        • 메인 모듈이 직접 하위 모듈에 의존성을 주는 것이 아닌, 의존성 주입자가 메인 모듈에 간접적으로 의존성을 주입함으로써, 메인 모듈은 하위 모듈에 대한 의존성이 줄어든다.
        • 장점: 모듈 교체가 쉽고, 모듈 간의 관계가 명확해진다.
        • 단점: 모듈이 더욱더 분리되어 클래스 수가 많아져 복잡해진다. 
        • 의존성 주입 원칙
          • 상위 모듈은 하위 모듈에서 어떠한 것도 가져오면 안된다. 또한, 둘 다 추상화에 의존해야 하고, 추상화는 세부 사항에 의존하지 말아야 한다. 
• 팩토리 패턴
  
  • 객체를 사용하는 코드에서 객체 생성 부분을 떼어내 추상화한 패턴
  • 상속 관계에 있는 두 클래스에서 상위 클래스가 중요한 뼈대를 결정하고, 하위 클래스는 객체 생성에 관한 구체적인 내용을 결정한다. 
    • 상위 클래스에서는 인스턴스 생성에 대해 알 필요가 없어 유연성이 증가한다.
    • 객체 생성 로직이 따로 떨어져서 코드를 리팩토링할 때 한곳만 수정하면 되어 유지보수성이 증가한다.
• 전략 패턴(정책 패턴)
  • 객체의 행위를 바꾸고 싶은 경우, 직접 수정하지 않고 전략이라 부르는 캡슐화한 알고리즘을 컨텍스트 안에서 바꿔주면서 상호 교체가 가능하게 만드는 패턴
  • 예시
    • 네이버 페이, 카카오 페이 등 다양한 결제 방식이 있을 때 결제 방식의 전략만 바꾸기
• 옵저버 패턴
  • 주체가 어떤 객체의 상태 변화를 관찰하다가 상태 변화가 있을 때마다 메서드 등을 통해 옵저버 목록에 있는 옵저버들에게 변화를 알리는 패턴
  • 옵저버: 객체의 상태 변화에 따라 전달되는 메서드 등을 기반으로 추가 변경 사항이 생기는 객체들이다. 객체와 주체를 따로 두지 않을 수도 있다.
  • 예시
    • 트위터에서 내가 어떤 사람을 팔로우하고, 그 사람이 글을 올리면, 그 사람의 팔로워들이 알림을 받는다.
  • 옵저버 패턴은 주로 이벤트 기반 시스템에 사용한다. MVC 패턴에서도 사용된다.
• 프록시 패턴
  • 대상 객체에 접근하기 전에, 그 접근에 대한 흐름을 가로채서 해당 접근을 필터링하거나 수정하는 등의 역할을 하는 계층이 있는 디자인 패턴 => 객체의 속성, 변환 등을 보완하며 보안, 데이터 검증, 캐싱, 로깅 등에 사용
  • 프록시 서버: 서버와 클라이언트 사이에서 클라이언트가 자신을 통해 다른 네트워크 서비스에 접근할 수 있도록 하는 컴퓨터 시스템이나 응용 프로그램 
    • 익명 사용자가 직접적으로 서버에 접근하는 것을 차단하고, 간접적으로 한 단계를 더 거치게해서 보안을 강화한다.
    • NGINX, CLOUDFLARE 등이 있다. 
• 이터레이터 패턴
  • 이터레이터를 사용해서 컬렉션의 요소들에 접근하는 디자인 패턴이다. 
  • 순회 가능한 여러가지 자료형의 구조와는 관계없이 이터레이터 하나로 순회 가능하다.
• 노출 모듈 패턴
  • 즉시 실행 함수를 통해 private, public 같은 접근 제어자를 만드는 패턴
  • JS는 private, public이 없는데, 노출 모듈 패턴을 통해 private, public을 만들 수 있다.
• MVC 패턴
  • 모델, 뷰, 컨트롤러로 이루어진 패턴
  • 애플리케이션의 구성 요소를 세가지로 구분해서 개발 프로세스에서 각각의 구성 요소에만 집중해서 개발 가능하다.
    • 재사용성 증가, 확장성 증가. 하지만 애플리케이션이 복잡해지면 모델과 뷰의 관계가 복잡해진다.
  • 모델: 애플리케이션의 데이터인 데이터베이스, 상수, 변수 등
    • 뷰에서 데이터를 생성하거나 수정하면 컨트롤러를 통해 모델을 생성하거나, 수정한다.
  • 뷰: inputbox, checkbox, textarea 등 사용자 인터페이스 요소를 나타냄
    • 모델을 기반으로 사용자가 볼 수 있는 화면.
    • 단순히 화면에 표시하는 정보만 갖고 있어야 함.
  • 컨트롤러: 하나 이상의 모델과 하나 이상의 뷰를 연결하는 다리 역할
    • 이벤트 등 메인 로직을 담당하고 모델과 뷰의 생명 주기도 관리한다.
    • 모델이나 뷰의 변경 통지를 받으면 이를 해석하여 각각의 구성 요소에 해당 내용에 대해 알려줌.
  • 예시: Spring
• MVP 패턴
  • MVC에서 C에 해당하는 컨트롤러가 프레젠터로 교체됨
  • 뷰와 프레젠터는 일대일 관계이기 때문에 MVC 패턴보다 더 강한 결합을 지닌 디자인 패턴이다.
• MVVM 패턴
  • MVC에서 C에 해당하는 컨트롤러가 뷰 모델로 교체됨
  • 뷰 모델은 뷰를 더 추상화한 계층
  • MVVM 패턴은 MVC 패턴과는 다르게 커맨드와 데이터 바인딩을 가진다.
  • 예시
    • Vue.js 
      • 반응형이 특징으로. 값 대입만으로 변수가 변경된다. 

 

 

 

 

• 상속 (extends): 자식 클래스가 부모 클래스 받기. 클래스, abstract 클래스를 상속
• 구현 (implements): 인터페이스를 구현. 상속과 달리 인터페이스의 메서드를 재정의하여 구현해야함.

 

• 프록시 객체: 어떤한 대상의 기본적인 동작(속성 접근, 할당, 순회, 열거, 함수 호출, ...)의 작업을 가로챌 수 있는 객체
  • 프록시 객체는 디자인 패턴 중 하나인 프록시 패턴에 녹아들어 있다.
• CORS: Cross-Origin Resource Sharing. 서버가 웹 브라우저에서 리소스를 로드할 때 다른 오리진을 통해 로드하지 못하도록 하는 HTTP 헤더 기반 알고리즘
  • 예시
    • 프론트 엔드에서는 127.0.0.1:3000으로 테스트하고, 백엔드에서는 127.0.0.1:12010로 테스트하면 에러가 생긴다.
    • => 프록시 서버를 두어 프론트엔드 서버에서 요청되는 오리진을 127.0.0.1:12010으로 바꾸면 CORS 문제가 해결된다.