1.1 디자인 패턴

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

싱글톤 패턴

• singleton pattern
• 하나의 클래스의 오직 하나의 인스턴스
• 데이터베이스 연결 모듈에 많이 사용
• 하나의 인스턴스를 만들어 놓고 다른 모듈들이 공유하며 사용
  ➡ 인스턴스 생성 비용 ↓ but 의존성 높아짐
• 단점
  • tdd할 때 단위 테스트에서 테스트가 서로 독립적이어야 하는데 싱글톤은 각 테스트마다 독립적인 인스턴스 만들기 어렵

의존성 주입

• 싱글톤 패턴 단점 : 모듈 간의 결합을 강하게 만들 수 있음 -> 의존성 주입으로 해결. 메인 모듈이 직접 다른 하위 모듈에 대한 의존성을 주기보단, 의존성 주입자가 이 부분을 가로채 메인 모듈이 간접적으로 의존성을 주입하는 방식
  

의존성 주입 장점

• 모듈들을 쉽게 교체할 수 있는 구조가 되어 테스팅하기 쉽고 마이그레이션 하기 수월
• 구현할 때 추상화 레이어를 넣고 이를 기반으로 구현체를 넣어 주기 때문에 애플리케이션 의존성 방향이 일관되고, 애플리케이션 쉽게 추론하고, 모듈 간 관계들 더 명확해짐

의존성 주입 단점

• 모듈들이 더욱더 분리돼 클래스 수가 늘어나 복잡성이 증가될 수 있음
• 약간의 런타임 페널티가 생기기도 함

의존성 주입 원칙

• 상위 모듈은 하위 모듈에서 어떠한 것도 가져오지 않아야 함
• 둘 다 추상화에 의존해야 하며, 이때 추상화는 세부 사항에 의존하지 말아야 함

팩토리 패턴

• factory pattern
• 객체를 사용하는 코드에서 객체 생성 부분을 떼내 추상화한 패턴이라 상속 관계에 있는 두 클래스에서 상위 클래스가 중요 뼈대를 결정하고 하위 클래스에서 객체 생성에 관한 구체적인 내용을 결정
• 상위 클래스와 하위 클래스가 분리되기 때문에 느슨한 결합을 가짐
• 상위 클래스에서는 인스턴스 생성 방식 알 필요 x -> 유연성↑
• 객체 생성 로직이 따로 떼어짐 -> 코드 리팩터링 해도 한 곳만 고치면 됨. 유지 보수성 증가

전략 패턴

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

옵저버 패턴

• observer pattern
• 주체가 어떤 객체의 상태 변화를 관찰하다 변화가 있을 때마다 메서드 등을 통해 옵저버 목록에 있는 옵저버들에게 변화를 알려줌
• 주체 : 객체의 상태 변화를 보고 있는 관찰자
• 옵저버 : 이 객체의 상태 변화에 따라 전달되는 메서드 등을 기반으로 '추가 변화 사항'이 생기는 객체들
  
• 그림처럼 주체과 객체를 따로 두지 않고 상태가 변경되는 객체를 기반으로 구축되기도 함
• 예시) 트위터
• 주로 이벤트 기반 시스템에 사용
• MVC 패턴에도 사용

프록시 패턴과 프록시 서버

프록시 패턴

• proxy pattern
• 대상 객체에 접근하기 전 그 접근에 대한 흐름을 가로채 대상 객체 앞단의 인터페이스 역할을 하는 디자인 패턴
  
• 이를 통해 객체 속성, 변환 등을 보완하며 보안, 데이터 검증, 캐싱, 로깅에 사용
• 프록시 객체로 쓰이기도 하지만 프록시 서버로도 활용

프록시 서버

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

이터레이터 패턴

• iterator pattern
• 이터레이터를 사용해 컬렉션의 요소들에 접근하는 디자인 패턴
• 이를 통해 순회할 수 있는 여러 자료형의 구조와 상관 없이 이터레이터라는 하나의 인터페이스로 순회 가능
  
• 이터레이터라는 똑같은 배로, 동그라미로 이뤄진 컬렉션이든 마름모로 이뤄진 컬렉션이든 순회할 수 있는 것을 보여주는 그림

노출모듈 패턴

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

MVC 패턴

• model, view, controller
  
• 애플리케이션의 구성 요소를 세 역할로 구분
  • 개발 프로세스에서 각각 구성 요소에 집중해서 개발 가능
  • 재사용성과 확장성 용이
  • 애플리케이션이 복잡할수록 모델과 뷰 관계 복잡해진다는 단점이..

모델

• 애플리케이션의 데이터인 데이터베이스, 상수, 변수 등
• 예) 사각형 모양 박스 안에 글자가 들어 있다면, 그 박스의 위치, 글자 내용, 글자 위치, 글자 포맷 등 관련 정보를 모두 가지고 있어야 함
• 뷰에서 데이터를 생성하거나 수정하면 컨트롤러를 통해 모델을 생성하거나 갱신

뷰

• inputbox, checkbox, textarea 등 사용자 인터페이스 요소
• 즉, 모델을 기반으로 사용자가 볼 수 있는 화면
• 모델이 가지고 있는 정보를 따로 저장 x.
• 단순히 사각형 모양 등 화면에 표시하는 정보만 가져야함
• 변경이 일어나면 컨트롤러에 전달해야함

컨트롤러

• 하나 이상의 모델과 하나 이상의 뷰를 잇는 다리 역할
• 이벤트 등 메인 로직 담당
• 모델과 뷰의 생명주기도 관리
• 모델이나 뷰의 변경 통지 받으면 이를 해석하여 각각 구성요소에 해당 내용에 대해 알려줌
• ex) spring

MVP 패턴

• MVC 패턴으로부터 파생. conroller가 프레젠터(presenter)로 교체.
  
• 뷰와 프레젠터를 일대일 관계. -> MVC 보다 더 강한 결합 지님

MVVM 패턴

• MVC의 c가 뷰모델(view model)로 바뀐 패턴
  
• 뷰 모델 : 뷰를 더 추상화한 계층
• MVVM 패턴은 MVC와 다르게 커맨드와 데이터 바인딩을 가지는 것이 특징
• 뷰와 뷰 모델 사이의 양방향 데이터 바인딩을 지원해 UI를 별도 코드 수정 없이 재사용 가능
• 단위 테스팅 하기 쉬움
• ex) 뷰(Vue.js)

Reference

주홍철 작가님의 '면접을 위한 CS 전공지식 노트'를 기반으로 작성되었습니다.